DETAILED ACTION
Status of Claims
Claims 1, 5, and 13-24 have been amended.
Claims 1-24 are currently pending and have been considered by the examiner.
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 .
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 20 January 2026 has been entered.
Response to Arguments
101 Rejection:
Applicant’s arguments have been considered and have been deemed unpersuasive regarding overall patent eligibility by the examiner based upon the rationale provided in the following 101 rejection.
Prior Art Rejection:
Applicant’s arguments have been considered and are moot in view of new grounds for rejection.
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-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claim 1-12 are directed towards a method and claims 13-24 are directed towards a system. Therefore, these claims fall within the four statutory categories of invention.
Claim 1 recites the following:
A method comprising:
associating a credential provider with a credential provider instance, the credential provider instance within a client device for authenticating a user to relying parties
associating a new credential with the credential provider instance, the new credential having a public portion and a non-public portion;
transmitting over an out-of-band communication channel, a request for an identifying attestation to a plurality of trusted credential provider servers, the request including an identifier based on the new credential or the public portion of the new credential;
responsive to the request, transmitting, by a trusted credential provider server of the plurality of trusted credential provider servers, the identifying attestation associated with the new credential based on that the trusted credential provider server maintains the new credential;
receiving from a trusted credential provider server of the plurality of trusted credential provider servers the identifying attestation the trusted credential provider server attesting that the request relates to the new credential based on the trusted credential provider server maintaining the new credential;
verifying the identifying attestation and adding a corresponding attestation statement to the new credential upon verification of the identifying attestation; and
authenticating the user to a relying party based on the new credential
Regarding Step 2A Prong One, the claims recite the abstract idea of risk mitigation. Specifically, the claims recite the limitations underlined above which recite the process of mitigating risk in an economic transaction which is grouped within the Certain Methods of Organizing Human Activity grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP § 2106.04) because the claims involve the process of mitigating risk in an economic transaction. Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 53-54 (January 7, 2019)).
Regarding Step 2A Prong Two, the recited abstract idea is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP § 2106.04(d)), the additional element(s) of the claim(s) such as a “client device” or “server” merely use(s) a computer as a tool to perform an abstract idea. Specifically, the “client device” or “server” perform(s) the steps or functions underlined above. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), the claims do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition (Vanda Memo), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP § 2106.05), the additional element(s) of a “client device” or “server” amounts to no more than using a computer or processor to automate and/or implement the abstract idea. As discussed above, taking the claim elements separately, the “client device” or “server” perform(s) the steps or functions underlined above. These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite risk mitigation. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible.
Dependent claims 2-12 and 14-24 further describe the recited abstract idea. The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Specifically:
Claims 2 and 14 merely further describe the communication channel used to transfer information required to perform the recited abstract idea.
Claims 3-4, 8-9, 11-12, 15-16, 20-21, and 23-24 merely further describes information and data used to perform the recited abstract idea.
Claims 5 and 17 merely further describes the permissions of the recited additional element without integrating said element into practical application nor amounting to significantly more.
Claims 6-7, 10, 18-19, and 22 recite additional limitations which are also directed towards the recited abstract idea.
Therefore, as the dependent claims do not include additional elements that integrate the abstract idea into a practical application nor provide significantly more than the abstract idea, the dependent claims are also not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lindemann et al. (US 20200280550 A1) in view of Forte (US 20150149359 A1) in further view of Saboori et al. (US 20160080379 A1).
Regarding Claims 1 and 13, Lindemann discloses:
A method comprising:
associating a credential provider with a credential provider instance within a client device, the credential provider instance for authenticating a user to relying parties from a client device (See Lindemann: Fig. 3 – Authenticator Authorization application 390 is associated with new authentication engine 310, wherein disclosed the application is analogous to the claimed credential provider instance and the disclosed authentication engine is analogous to the credential provider; See Lindemann: Para. [0035] – “an authenticator authorization application 390, 391 may be executed on the new device 200 and old device 202, respectively, to establish the secure connection, exchange the authorization data, and verify the registrations with a secure transaction service 304 on each relying party 250. As used herein, an “old authenticator” (Aold) is an authenticator that a user has already registered with one or more relying parties. A “new authenticator” (Anew) is one which the user wishes to enable with all the relying party registrations currently being used with the old authenticator. Thus, the authentication engine 311 in the described embodiments has previously registered one or more old authentication devices 322-323 with a relying party. The goal of one embodiment is to transfer registrations from the old authentication engine 311 to the new authentication engine 310 to enable the new authenticators 320-321 with each relying party.”);
associating a new credential with the credential provider instance, the new credential having a public portion and a non-public portion (See Lindemann: Para. [0047] – “At 403, the new authenticator generates a public/private key pair for each username/AppID pair (e.g., for each unique relying party account)”);
transmitting over communication channel, a request for an identifying attestation to a plurality of trusted credential provider servers, the request including an identifier based on the new credential or the public portion of the new credential (See Lindemann: Para. [0048] – “At 404, the old authenticator receives the key pairs and an authenticator attestation ID code identifying the type of each new authenticator (e.g., an AAID). The user may then be asked to confirm the authorization operation.”; See Lindemann: Para. [0145] – “Users can register multiple authenticators to each account/relying party. If a user loses any (but the last registered) authenticator, they can simply authenticate with one of the remaining authenticators and then register a new/replacement authenticator.”);
responsive to the request, transmitting, by a trusted credential provider server of the plurality of trusted credential provider servers (See Lindemann: Para. [0049-0050] – “At 405, the old authenticator generates a signed authorization object comprising a signature over the tuple of the AAID, the public key and the AppID for each relying party … At 406, the old authenticator authenticates to each relying party and includes the signed authorization object as an extension to the authentication message”)
the identifying attestation associated with the new credential based on that the trusted credential provider server maintains the new credential (The examiner has determined that the aforementioned claim limitation constitutes a recitation of nonfunctional descriptive material. Specifically, the aforementioned limitation merely further describes functions performed by the trusted credential provider server which operates outside the scope of the claimed invention i.e. the functionality of the trusted credential provider provides no functional limitation on the claimed method step of receiving the attestation. Thus, as the limitation constitutes nonfunctional descriptive material, the limitations cannot be given patentable weight. For purposes of compact prosecution, the examiner cites the following: See Lindemann: Para. [0052] – “or example, if the AAID indicates an authenticator type which is not sufficiently reliable or accurate, then the relying party may choose to deny the new registration. Thus, each relying party may maintain an authenticator database (i.e., Metadata) containing data for all known authenticators (e.g., identified by AAID). It may then query the database in response to receiving the authorization object from the old authenticator, determine the characteristics of the new authenticator, and determine whether those characteristics are acceptable.”)
receiving from the trusted credential provider server the identifying attestation (See Lindemann: Para. [0049-0050] – “At 405, the old authenticator generates a signed authorization object comprising a signature over the tuple of the AAID, the public key and the AppID for each relying party … At 406, the old authenticator authenticates to each relying party and includes the signed authorization object as an extension to the authentication message”);
verifying the identifying attestation (See Lindemann: Para. [0058-0059] – “Interface 702 may also provide secure access to a secure storage device 720 on the client 700 which stores information related to each of the authentication devices 710-712 such as a device identification code, user identification code, user enrollment data (e.g., scanned fingerprint or other biometric data), and keys used to perform the secure authentication techniques described herein. For example, as discussed in detail below, a unique key may be stored into each of the authentication devices during registration and used when communicating to servers 730 over a network such as the Internet … Once the user has enrolled with an authentication device on the client 700, the secure transaction service 701 may register the authentication device with the secure transaction servers 732-733 over the network (e.g., using the registration techniques described herein) and subsequently authenticate with those servers using data exchanged during the registration process (e.g., encryption keys provisioned into the biometric devices)); and
using or storing the identifying attestation when validated (See Lindemann: Para. [0058-0059] – “Interface 702 may also provide secure access to a secure storage device 720 on the client 700 which stores information related to each of the authentication devices 710-712 such as a device identification code, user identification code, user enrollment data (e.g., scanned fingerprint or other biometric data), and keys used to perform the secure authentication techniques described herein. For example, as discussed in detail below, a unique key may be stored into each of the authentication devices during registration and used when communicating to servers 730 over a network such as the Internet … Once the user has enrolled with an authentication device on the client 700, the secure transaction service 701 may register the authentication device with the secure transaction servers 732-733 over the network (e.g., using the registration techniques described herein) and subsequently authenticate with those servers using data exchanged during the registration process (e.g., encryption keys provisioned into the biometric devices)).
authenticating the user to a relying party (See Lindemann: Para. [0050] – “At 406, the old authenticator authenticates to each relying party and includes the signed authorization object as an extension to the authentication message. Once this operation is successfully completed, the user may then authenticate with each relying party using the new device and/or new authenticators”)
However, Lindemann fails to explicitly disclose:
Wherein the communication channel is an out-of-band communication channel
However, in a similar field of endeavor, Forte discloses:
Wherein the communication channel is an out-of-band communication channel (See Forte: Para. [0010] – “The out-of-band device can include a component of a computing device involved in the transaction, and the processor can communicate with the out-of-band device via a second communication channel. In some embodiments, the verification request can be received via a communication channel, and the out-of-band communication device can communicate with the processor via an out-of-band communication channel.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to substitute the generic communication channel disclosed by Lindemann for the out-of-band communication channel disclosed by Forte yielding the predictable result of a more stable system by ensuring that communications can still be transmitted in the instance that primary communication channels go down.
However, the combination of Lindemann and Forte fails to explicitly disclose:
adding a corresponding attestation statement to the new credential upon verification of the identifying attestation
authenticating based on the new credential
However, in a similar field of endeavor, Saboori discloses:
adding a corresponding attestation statement to the new credential upon verification of the identifying attestation (See Saboori: para. [0003] – “the second credentials may comprise an attestation statement that is more trustworthy than the encryption key and that is generated based on a certificate retrieved from a remote security device (e.g., a certificate authority server). Accordingly, the remote access device may initially allow the computing device to access less secure content and functionality in association with the established first level of trust and then allow the computing device to access more secure content and functionality in accordance with the established second level of trust.”)
authenticating based on the new credential (See Saboori: Para. [0037] – “To further illustrate, in a first example, the remote access device 116 may be a social network server configured to initially accept the first credentials 106 to authenticate the computing device 102 and to subsequently accept the second credentials 114 to upgrade the authentication of the computing device 102 from the first level of trust 308 to a second level of trust 310. In between the acceptance of the first credentials 106 and the second credentials 114”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to modify the new credential disclosed by the combination of Lindemann and Forte to include the corresponding attestation statement as disclosed by Saboori yielding the predictable result of an increase in the security strength of the invention by leveraging an additional authentication data point.
Regarding Claims 2 and 14, the combination discloses:
wherein the out-of-band communication channel comprises a communication channel which does not rely on a credential provider restricted platform application programming interface (API) of the client device and/or which will not be blocked by the platform associated with the client device (See Forte: Para. [0010] – “The out-of-band device can include a component of a computing device involved in the transaction, and the processor can communicate with the out-of-band device via a second communication channel. In some embodiments, the verification request can be received via a communication channel, and the out-of-band communication device can communicate with the processor via an out-of-band communication channel.” – The examiner asserts that, by definition, an out-of-band communication channel constitutes a channel which exists outside a primary communication channel. As the API of the client device constitutes a primary communication channel of the claimed invention, an out-of-band channel must not rely on said API.).
Regarding Claims 3 and 15, the combination discloses:
wherein the identifier includes a cryptographic hash generated over the new credential or the public portion of the new credential (See Lindemann: Para. [0119] – “One embodiment of the described authenticator 1110 supports a new IUVRD, a one-time-UVRD, and/or a one-time Identity-Binding-Handle (OT-IBH) extension for FIDO registration. This extension includes the encrypted user verification data (or data from which the user verification data can be derived or the hashed or encrypted identity binding handle”).
Regarding Claims 4 and 16, the combination discloses:
wherein the cryptographic hash is generated over a combination of the new credential and a plurality of additional bits which are different for each request (See Lindemann: Para. [0121] – “In case of the One-Time-UVRD extension used in one embodiment, the user verification reference data included in the extension is applicable to exactly the registration operation it belongs to. In the case of the OT-IBH extension, the extension includes the nonce and potentially an additional identifier followed by the hash of the handle H concatenated with some nonce and potentially some additional Identifier ID. Stated more formally: OT-IBH=(Nonce, ID, Hash(H|Nonce|ID)).”).
Regarding Claims 5 and 17, the combination discloses:
wherein only the trusted credential provider server which maintains the new credential is capable of generating the identifying attestation based on the new credential identified by the cryptographic hash (See Lindemann: Para. [0049-0050] – “At 405, the old authenticator generates a signed authorization object comprising a signature over the tuple of the AAID, the public key and the AppID for each relying party … At 406, the old authenticator authenticates to each relying party and includes the signed authorization object as an extension to the authentication message” – Lindemann does not disclose any other entity being able to generate the identifying attestation other than the maintainer of the new credential).
Regarding Claims 6 and 18, the combination discloses:
generating the credential provider instance, if one does not already exist on the client device (See Lindemann: Para. [0035] – “an authenticator authorization application 390, 391 may be executed on the new device 200” – The initialization of an application encompasses the BRI of generating an instance).
Regarding Claims 7 and 19, the combination discloses:
wherein generating the credential provider instance comprises: authenticating the user on the trusted credential provider server (See Lindemann: Para. [0058-0059] – “Interface 702 may also provide secure access to a secure storage device 720 on the client 700 which stores information related to each of the authentication devices 710-712 such as a device identification code, user identification code, user enrollment data (e.g., scanned fingerprint or other biometric data), and keys used to perform the secure authentication techniques described herein. For example, as discussed in detail below, a unique key may be stored into each of the authentication devices during registration and used when communicating to servers 730 over a network such as the Internet … Once the user has enrolled with an authentication device on the client 700, the secure transaction service 701 may register the authentication device with the secure transaction servers 732-733 over the network (e.g., using the registration techniques described herein) and subsequently authenticate with those servers using data exchanged during the registration process (e.g., encryption keys provisioned into the biometric devices)); and
generating the credential provider instance associated with a corresponding trusted credential provider (See Lindemann: Para. [0035] – “an authenticator authorization application 390, 391 may be executed on the new device 200”).
Regarding Claims 8 and 20, the combination discloses:
wherein authenticating the user and generating the credential provider instance are performed via a platform application programming interface (API) of the client device (See Lindemann: Para. [0058] – “The authentication devices 710-712 are communicatively coupled to the client through an interface 702 (e.g., an application programming interface or API) exposed by a secure transaction service 701.”).
Regarding Claims 9 and 21, the combination discloses:
wherein the credential provider instance comprises a set of credential attributes to allow the corresponding trusted credential provider to indicate a particular credential provider server to be used for each of a plurality of relying parties (See Lindemann: Para. [0082] – “In one embodiment, an attestation module 903 uses the private key 905 to generate a signature 908 over an object which includes authenticator attributes and application data to generate a signed object 907. As illustrated, in one embodiment, the object to be signed comprises a concatenation of attested attributes of the authenticator and application data. The attested attributes used in the signed object may include, for example, (a) the Transaction Text as confirmed by the user, (b) the actual personal identification number (PIN) length as opposed to the minimal PIN length, or (c) the firmware version of the authenticator implementation.”).
Regarding Claims 10 and 22, the combination discloses:
further comprising: combining the identifying attestation and the new credential in an object, the object usable for processing by a relying party for authentication (See Lindemann: Para. [0049-0050] – “At 405, the old authenticator generates a signed authorization object comprising a signature over the tuple of the AAID, the public key and the AppID for each relying party … At 406, the old authenticator authenticates to each relying party and includes the signed authorization object as an extension to the authentication message” – Lindemann discloses a combined signed authorization object).
Regarding Claims 11 and 23, the combination discloses:
wherein information associated with the new credential is to be communicated to a corresponding relying party, the information related to potential risk associated with the new credential (The examiner has determined that the aforementioned claim limitation constitutes a recitation of nonfunctional descriptive material in the form of intended use. Specifically, the aforementioned limitation merely describes an intended use of the information without imposing any meaningful limitation to any positively recited step in the claimed method. Thus, the limitations cannot be given patentable weight. See MPEP 2114. For purposes of compact prosecution, the examiner cites the following: See Lindemann: Para. [0207] – “The authenticator will return the sync pull response, i.e., the concatenation of the server provided Nonce, the Group-ID 1502, WKEK 1503 and the hash of the internal persistent memory first signed by the attestation key and then encrypted by the CSEK 1501 (sync pull request). This function is triggered by an external module (e.g. ASM, authenticator configuration App). Once received by the cloud service 1550, it decrypts the block, verifies the attestation signature and compares the state hash with the hash received along with the latest data block. It returns the sync pull response, i.e. the latest wrapped data block encrypted by WKEK 1503. In one implementation, the cloud service 1550 increments a mismatch counter if the hash doesn't match. Very high counter values indicate increased risk.”).
Regarding Claims 12 and 24, the combination discloses:
wherein the new credential is generated by the credential provider instance or by the trusted credential provider server (See Lindemann: Para. [0049-0050] – “At 405, the old authenticator generates a signed authorization object comprising a signature over the tuple of the AAID, the public key and the AppID for each relying party … At 406, the old authenticator authenticates to each relying party and includes the signed authorization object as an extension to the authentication message”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Blanke (US 20160219043 A1) generally discloses systems and methods for establishing trust between devices using secure transmission protocols.
Lindemann (US 20170048218 A1) generally discloses systems and methods for enhancing security during registration of a device.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS K PHAN whose telephone number is (571)272-6748. The examiner can normally be reached M-F 1 pm-9 pm EST.
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, Neha Patel can be reached on 571-270-1492. 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.
/NICHOLAS K PHAN/Examiner, Art Unit 3699
/COURTNEY P JONES/Primary Examiner, Art Unit 3699