DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
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 1-17 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.
Claim 1 and 13 are rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “a first private key of the first asymmetric key” does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claim. Claims 1 and 13 recite “storing, by the passkey agent, a first private key of the first asymmetric key, in a secure area”. It is unclear whether the recited “first asymmetric key” is itself intended to be the first private key or whether the first private key is a component of a first asymmetric key pair. One of the ordinary skills in the art would ordinarily understand an asymmetric key pair to include a public key and a private key. However, the claim language does not clearly define the relationship between the recited “first private key” and “first asymmetric key.” Therefore, the scope of the limitation is unclear.
Claim 4 and 16 are rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “a symmetric key of the second key” does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claim. Claims 4 and 16 recite “delivering, by the passkey agent, a symmetric key of the second key to the passkey provider server.” The claims previously recite a first key (PIN_INFO) for encryption and a second key (PIN_ID) for verification. However, it is unclear what constitutes the recited “symmetric key of the second key”. It is unclear whether the second key itself is the symmetric key, whether a separate symmetric key is derived from the second key, or whether the recited symmetric key is some other value associated with the second key. Therefore, the scope of the limitation is unclear.
Claims depending from the rejected claims inherit the indefiniteness of their respective base claims. Accordingly, claims 2-5 depend directly or indirectly from claim 1 and inherit the indefiniteness of claim 1; and claims 14-17 depend directly or indirectly from claim 13 and inherit the indefiniteness of claim 13. Additionally, claims 4 and 16 are rejected for the separate indefiniteness of the limitation “a symmetric of the second key.”
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-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding claims 1, 6, 11, AND 13:
Applying Step 1 of the Subject Matter Eligibility Test (SMET), does the claim as a whole fall
within one of the four statutory categories of invention? Yes.
Under Step 2A of the SMET, also known at this stage as the Alice/Mayo Test, Prong One, is the claim as a whole directed to a law of nature, a natural phenomenon (product of nature) or an abstract idea? Yes.
The abstract step of (i) generating, by a passkey agent, a first asymmetric key (VERIFYDATA) for encryption and decryption, (ii) generating, by the passkey agent, a second asymmetric key (WRAPPINGDATA_RSA), (ii) generating, by the passkey agent, an encrypted private key, (iv) performing primary encryption, (v) acquiring, by the passkey agent, a signature value obtained by signing a value of data, (vi) generating, by the passkey agent, an extension signature value, and (vii)performing signature verification, amount to mathematical operations, data processing, comparing/verifying information, and reporting the result, which fall within the abstract idea grouping of mathematical concepts and mental processes.
(see MPEP 2106.04(a)(2)(C)).
It should be noted that encryption, decryption, hashing, signing, signature verification, key generation, and key comparison are mathematical and data manipulation operation performed on information. The claims merely use these operations to protect, transmit, verify, and synchronize passkey-related data.
Applying Step 2A, Prong Two, does the claim recite additional elements that integrate the
judicial exception into a practical application? No.
The claim recites the additional elements of:
a computing device;
a passkey agent;
a service application;
a secure area;
a passkey provider server;
a processor, memory, and storage;
WebAuthn extension format;
HSM / secure area storage;
PIN input information.
A claim reciting a judicial exception is not directed to the judicial exception if it also recites additional elements demonstrating that the claim as a whole integrates the exception into a practical application. One way to demonstrate such integration is when the claimed invention improves the functioning of a computer or improves another technology or technical field. However, the additional elements recited above do no such thing and do not improve the functioning of the computer, passkey system, secure area, or server technology.
The claimed invention merely uses off the shelf generic computer components and conventional security components to generate keys, store keys, encrypt data, decrypt data, sign data, verify signatures, and transmit passkey related information. The specification describes the computing device as including ordinary components such as a processor, memory, storage, bus, and network interface, and describes the secure area as Android Keystore or iOS Keychain. However, courts have indicated that gathering and analyzing information using conventional techniques and displaying the result may not be sufficient to show an improvement to technology (see TLI Communications, 823 F.3d at 612-13, 118 USPQ2d at 1747-48).
Thus, this judicial exception is not integrated into a practical application and the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception as argued above.
Applying Step 2B, do the additional elements amount to an inventive concept? No.
Simply appending well-understood, routine, conventional activities previously known to the
industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are wellunderstood, routine and conventional activities previously known to the industry, is not enough, as discussed in Alice Corp., 573 U.S. at 225, 110 USP. The additional elements are generic computer components carrying out routine computer functions, and routine cryptographic key management functions, and are therefore not enough to supply an inventive concept.
Because claims 1, 6, 11, and 13 fails Step 2B, the claim as a whole is found ineligible for being drawn to an abstract idea and therefore is non-statutory under 35 U.S.C. § 101.
Regarding claims 2-5, 7-10, 12, and 14-17:
The dependent claims do not alter the analysis applied to independent claims 1, 6, 11, and 13.
Claims 2 and 14 merely recite delivering public keys to a server.
Claims 3 and 15 merely recite generating a protective symmetric key at the server and applying PKCS
Claims 4 and 16 merely recite PIN derived encryption and verification keys.
Claims 5 and 17 merely recite generating and delivering device attestation.
Claim 7 merely recites adding a public key and signature/extension data to a request.
Claims 8 merely recites that the extension is a WebAuthn API format.
Claims 9 merely recites receiving and delivering a passkey response message and storing an encrypted private key at a server secure area.
Claims 10 merely recites decrypting using stored and PIN-derived keys to synchronize a passkey
Claim 12 merely recites verifying a signature using a stored public key.
These additional limitations either further narrow the abstract idea, specify the environment in which the abstract idea is implemented or add routine cryptographic, storage, verification, transmission, and server communication features. None of these limitations integrates the abstract idea into a practical application or adds significantly more than the abstract idea itself. Accordingly, claims 2-5, 7-10, 12, and 14-17 are also rejected under 35 U.S.C. 101.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5, 7-9, 11-15, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Islam et al (U.S. PGPub. No. US 2024/0283664 A1, hereinafter Islam) in view of Lindemann et al (U.S. PGPub. No. 2018/0191501, hereinafter Lindemann).
As to claim 1, Islam teaches:
A security management method for a passkey service, the security management method performed by a computing device, comprising: in response to receipt of an account creation request from a service application: (see Islam, [¶¶0002, 0073, 0074]: “Upon registration, the relying party may request a new WebAuthn credential from the authenticator, via the browser. A first data communication 702 represents the user computing device 108 initiating a registration process with a relying party 116 (e.g., via a web browser, desktop application, or mobile application) operating on the user computing device 108. The relying party 116 creates and sends a first RP challenge 705 (e.g., a WebAuthn assertion challenge) to the user computing device 108 to be signed by an authentication credential for the user.”);
(Islam teaches a relying party/services application sending registration request to a user computing device during webAuthn registration, which corresponds to the claimed computing device receiving an account creation request from a service application.)
generating, by a passkey agent, a first asymmetric key (VERIFYDATA) for encryption and decryption to be used in a passkey generation process: (see Islam, [¶¶0002, 0012]: “In examples, the authenticator creates a pair of keys, one secret and one public. The public key is returned to the server via the browser, and the secret key remains on the authenticator. Generate an authentication key pair including an authentication secret key and an authentication public key.”);
(An authenticator generating an asymmetric key pair for WebAuthn/passkey authentication.)
and storing a first private key of the first asymmetric key in a secure area; (see Islam, [¶¶0009, 0030]: “In examples, secret key material is stored in the cloud-based secure enclave and decryption of the secret key material is performed within the cloud-based secure enclave to provide a highly secure system where the secret key cannot be stolen if the user computing device is compromised. In further implementations, additional keys are used. In examples, the plaintext secret authentication key (K.sub.SAK) 105 is never outside the boundary of the secure enclave 110.”);
(Storing secret/private authentication key material in a secure enclave, which corresponds to storing the first private key in a secure area.)
Islam does not teach, but Lindemann teaches:
and generating, by the passkey agent, a second asymmetric key (WRAPPINGDATA_RSA) to be applied to a protective symmetric key (DATAPROTECTION) to be used in a passkey synchronization process: (see Lindemann, [¶¶0685-0686, 0688]: “Has an individual asymmetric wrapping key encryption key (WKEK) 6703, 6713. It may be generated by the authenticator 3710-3711 on first use and never made accessible outside the authenticator. Has a symmetric wrapping key (WK) 6704, 6714 which may be generated on first use and overwritten by each join procedure. The key synchronization logic 6721 will encrypt the wrapping key (WK) 6714 and Group-ID 6712 using the public WKEK 6703 received in the join block.”);
(Lindemann teaches encrypting, for example: applying, the symmetric wrapping key WK using the public asymmetric wrapping key WKEK. Therefore, Lindemann’s WKEK corresponds to the claimed second asymmetric key, and WK corresponds to the claimed protective symmetric key.)
and storing a second private key of the second asymmetric key in the secure area: (see Lindemann, [¶¶0685]: “It may be generated by the authenticator 3710-3711 on first use and never made accessible outside the authenticator.”);
(WKEK private key is kept inaccessible outside the authenticator, corresponding to storing the second private key in a secure area. It would have been obvious to store that key in the same secure area used for the first private key to centralize key protection.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify Islam’s WebAuth/passkey key-generation system to include Lindemann’s asymmetric wrapping key encryption key and symmetric wrapping key synchronization technique. A person of ordinary skill would have been motivated to store and protect critical secret key material in a secure enclave or authenticator secure storage, and to use Lindemann’s WKEK/WK wrapping arrangement to securely synchronize protected authentication key material without exposing private keys. This combination would have yielded the predictable benefit of improved secure key management and synchronization for passkey credentials.
As to claim 2, the combination Islam in view of Lindemann teaches:
The security management method of claim 1, further comprising: delivering, by the passkey agent, a first public key of the first asymmetric key and a is second public key of the second asymmetric key to a passkey provider server communicating with the computing device: (see Islam, [¶¶0002, 0077]: “The public key is returned to the server via the browser, and the secret key remains on the authenticator. The first RP challenge 705 and the public authentication key (K.sub.PAK) 115 are provided to the relying party 116 by the user computing device 108.”);
(see Lindemann, [¶¶0688]: “The key synchronization logic 6721 will encrypt the wrapping key (WK) 6714 and Group-ID 6712 using the public WKEK 6703 received in the join block.”);
(Islam teaches delivering the first public authentication passkey key to the server. Lindemann teaches exchanging the public WKEK, which corresponds to the second public key used for synchronization.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify Islam’s passkey public-key delivery with Lindemann’s public WKEK exchange. A person of ordinary skill would have been motivated to provide both public keys to support passkey registration and secure synchronization. The combination would have yielded the predictable benefit of enabling server-side credential registration and protected key synchronization.
As to claim 3, Islam teaches:
wherein the protective symmetric key is generated by the passkey provider server, and 20 the security management method further comprises receiving, by the passkey agent, a key generated by applying, in the passkey provider server, Public Key Cryptography Standards (PKCS) using the protective symmetric key and the second public key of the second asymmetric key, and storing the received key in the secure area: (see Lindemann, [¶¶0686, 0688]: “Has a symmetric wrapping key (WK) 6704, 6714 which may be generated on first use and overwritten by each join procedure. The key synchronization logic 6721 will encrypt the wrapping key (WK) 6714 and Group-ID 6712 using the public WKEK 6703 received in the join block. This data block is called in the join response block.”);
(Lindemann teaches generating a symmetric wrapping key, WK, corresponding to the protective symmetric key, and encrypting the WK using the public WKEK, which corresponds to the second public key. To the extend Lindemann generates the WK at the authenticator rather than at the passkey provider server, generating the protective symmetric key at the server would have been an obvious design choice among known key management architectures to establish the same symmetric key for secure synchronization. Applying a PKCS key package format here would have been a routine use of a known cryptographic standard.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify the Islam/Lindemann combination so that the passkey provider server generates the protective symmetric key and applies standard PKCS formatting during encryption. A person of ordinary skill would have been motivated to do so because server-side key generation simplifies client-side processing, and PKCS formatting provides a standardized way to package encrypted key material for transfer and parsing. The combination would have yielded the predictable benefit of standardized, secure key transfer during passkey synchronization.
As to claim 5, Lindemann teaches:
further comprising: generating, by the passkey agent, an attestation (Attestation.Device) for verifying io whether the computing device has been hacked, when a hacking attempt on the computing device is identified, and storing the attestation in the secure area; (see Lindemann, [¶¶0169, 0178]: “In one embodiment, the AK uses the attestation key 1215 to validate the model and/or integrity of the authenticator during registration. In one embodiment, the registration message sent to the RP 1320 also has multiple (chained) signatures, one with the AK's attestation key 1605 and one for each of the other components (e.g., the UVC's attestation key 1604 and the DC's attestation key (not shown)).”);
(Lindemann teaches generating attestation data to validate authenticator integrity. To the extent Lindemann performs this during registration, it would have been obvious to generate and store the attestation when a hacking attempt is identified, because performing integrity attestation after detecting a security event is a routine security practice.)
and delivering, by the passkey agent, the attestation to a passkey provider server: (see Lindemann, [¶¶0178, 0430]: “In one embodiment, the registration message sent to the RP 1320 also has multiple (chained) signatures, one with the AK's attestation key 1605 and one for each of the other components (e.g., the UVC's attestation key 1604 and the DC's attestation key (not shown)). An attestation over the new device public key associated with the relying party (ND_Uauth.pub). In one embodiment, the attestation comprises a signature generated over the public key (e.g., using a public key of the relying party).”);
(Sending attestation/signature data to the relying party/server, corresponding to delivering the attestation to the passkey provider server.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to use Lindemann’s attestation technique in the Islam/Lindemann passkey system. A person of ordinary skill would have been motivated to send device authenticator attestation information to the server so the server can verify device integrity before trusting passkey key material. The combination would have yielded the predictable benefit of improving protection and verification of improved detection of compromised or untrusted devices during passkey registration and synchronization.
As to claim 7, the combination Islam in view of Lindemann teaches:
further comprising: adding, by the passkey agent, the public key of the passkey to the passkey generation request; (see Islam, [¶¶0002, 0077]: “The public key is returned to the server via the browser, and the secret key remains on the authenticator. The first RP challenge 705 and the public authentication key (K.sub.PAK) 115 are provided to the relying party 116 by the user computing device 108.”);
(Islam teaches returning/providing the public authentication key to the server during WebAuthn credential registration.)
acquiring, by the passkey agent, a signature value obtained by signing a value of data included in the passkey generation request with a private key of an asymmetric key (VERIFYDATA) previously stored in the secure area; (see Islam, [¶¶0032, 0080]: “The secret key may be stored on the user computing device 108 to sign challenges and the public key is sent to and stored by the secure enclave 110 to verify signatures of challenges are from the trusted user computing device 108. User authentication may include successful verification of a challenge signed with a secret device-enclave key (e.g., 325, 415, 505, and/or 605) corresponding to the trusted user computing device 108 and in association with the user.”);
(Signing challenge or request data using a private key stored on the user computing device.)
generating, by the passkey agent, an extension signature value by including the signature value in an extension; (see Lindemann, [¶¶0635, 0636]: “Additionally, one embodiment of the authenticator 6310 includes an extension containing a success indicator in the signed registration assertion to indicate that the data has indeed been used by the authenticator (and the relying party 6315 can assume the related user being enrolled to that authenticator). 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.”);
(Lindemann teaches including authentication related security data within a FIDO extension. Using that extension to carry verification/signature related data corresponds to including the signature value in an extension.)
and adding, by the passkey agent, the extension signature value to the passkey generation request and delivering the passkey generation request to the passkey provider server: (see Islam, [¶0077]: “The first RP challenge 705 and the public authentication key (K.sub.PAK) 115 are provided to the relying party 116 by the user computing device 108.”);
(see Lindemann, [¶0635]: “Additionally, one embodiment of the authenticator 6310 includes an extension containing a success indicator in the signed registration assertion to indicate that the data has indeed been used by the authenticator (and the relying party 6315 can assume the related user being enrolled to that authenticator).”);
(Islam teaches delivering the passkey registration response/request to the server, and Lindemann teaches including extension data in a signed registration assertion.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify Islam’s WebAuth/passkey key-registration process with Lindemann’s FIDO extension formatting. A person of ordinary skill would have been motivated to include signature-related verification data in an extension field during registration to provide additional security context to the server. The combination would have yielded the predictable benefit of improved registration integrity and server-side verification of passkey generation requests.
As to claim 8, the combination Islam in view of Lindemann teaches:
wherein the extension is a format defined in a Web Authentication (WebAuthn) Application Programming Interface (API) for credentialing public keys: (see Islam, [¶¶0002]: “Upon registration, the relying party may request a new WebAuthn credential from the authenticator, via the browser.”);
(see Lindemann, [¶¶0667, 0635]: “Current FIDO specifications (UAF, U2F and FIDO2/Web Authentication) expect authentication keys (e.g., Uauth keys) to be dedicated to an individual authenticator instance. Additionally, one embodiment of the authenticator 6310 includes an extension containing a success indicator in the signed registration assertion to indicate that the data has indeed been used by the authenticator (and the relying party 6315 can assume the related user being enrolled to that authenticator).”):
(Islam teaches WebAuthn credential registration, and Lindemann teaches using FIDO web authentication extension data in an assertion. Together, they teach that the extension is a WebAuthn/FIDO-format extension used during public key credentialing.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to use Lindemann’s FIDO/WebAuthn extension formatting in Islam’s WebAuthn credential registration process because both references operate in the WebAuthn/FIDO public key credential framework. The combination would have yielded the predictable benefit of using a standard extension format for public-key credential registration.
As to claim 9, the combination Islam in view of Lindemann teaches:
further comprising: when verification of the encrypted private key of the passkey delivered to the passkey provider server is completed, receiving, by the passkey agent, a passkey response message from the passkey provider server; (see Islam, [¶0002]: “During assertion, the authenticator may use the secret key to sign the challenge and the signed challenge is returned to the website via the client. The server is then able to verify the signed challenge using the matching public key.”);
(see Lindemann, [¶0740]: “Once received by the cloud service 3950, it decrypts the block, verifies the attestation signature and compares the state hash with the hash received along with the latest data block.”);
(Lindemann teaches a cloud service receiving and verifying an encrypted key data block. Islam teaches a response message being returned through the client, corresponding to the passkey agent receiving a server response after verification.)
and delivering, by the passkey agent, the passkey response message to the service application: (see Islam, [¶0002]: “During assertion, the authenticator may use the secret key to sign the challenge and the signed challenge is returned to the website via the client. The server is then able to verify the signed challenge using the matching public key.”);
wherein the encrypted private key of the passkey is stored in a secure area of the passkey provider server: (see Islam, [¶¶0009, 0076]: “In examples, secret key material is stored in the cloud-based secure enclave and decryption of the secret key material is performed within the cloud-based secure enclave to provide a highly secure system where the secret key cannot be stolen if the user computing device is compromised. As represented by a fifth data communication 716, the secure enclave 110 stores the encrypted secret authentication key (K.sub.SAK-E) 150.”);
(Islam teaches storing encrypted secret/passkey private key material in a cloud based secure enclave, corresponding to a secure area of the passkey provider server.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify Islam’s passkey flow to include Lindemann’s server-side verification techniques. A person of ordinary skill would have been motivated to have the server verify encrypted key material and state hashes, as taught by Lindemann, and then pass the resulting response message through the passkey agent to the service application, as taught by Islam. The combination would have yielded the predictable benefit of ensuring that only verified passkey data packages are accepted before completing communication with the service application.
As to claim 11, Islam Teaches:
A security management method for a passkey service, the security management method performed by a computing device, comprising: in response to receipt of a passkey authentication request from a service application, acquiring, by a passkey agent, a signature value obtained by signing a value of data included in the passkey authentication request with a private key of an asymmetric key previously stored in a secure area; (see Islam, [¶¶0032, 0080]: “For instance, the client application 106 may exchange a public key of an asymmetric device-enclave key pair with the secure enclave 110, where the secret key may be stored on the user computing device 108 to sign challenges and the public key is sent to and stored by the secure enclave 110 to verify signatures of challenges are from the trusted user computing device 108. User authentication may include successful verification of a challenge signed with a secret device-enclave key (e.g., 325, 415, 505, and/or 605) corresponding to the trusted user computing device 108 and in association with the user.”);
(Signing authentication challenge data using a device private key previously stored on the user computing device.)
and generating, by the passkey agent, a response message including a signature value signed with a private key (PASSKEY_PRIVATEKEY) of a pre-registered passkey and transmitting the response message to a passkey server: (see Islam, [¶0081]: “The decrypted secret authentication key (K.sub.SAK) 105 is then used to sign the second RP challenge 805, which is represented by operation 814. A sixth data communication 816 represents the secure enclave 110 returning the signed second RP challenge 805 to the user computing device 108, and a seventh data communication 818 represents the user computing device 108 passing the signed second RP challenge 805 to the relying party 116.”);
(The pre-registered secret passkey private key to sign the RP challenge and return the signed authentication response to the server.)
generating, by the passkey agent, an extension signature value by including the signature value in an extension; (see Lindemann, [¶¶0635, 0636]: “Additionally, one embodiment of the authenticator 6310 includes an extension containing a success indicator in the signed registration assertion to indicate that the data has indeed been used by the authenticator (and the relying party 6315 can assume the related user being enrolled to that authenticator). 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.”);
(Lindemann teaches including transaction specific security data within a FIDO extension. Using that extension to carry verification/signature related data corresponds to including the signature value in an extension.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify Islam’s WebAuth authentication response with Lindemann’s FIDO extension formatting. A person of ordinary skill would have been motivated to include additional cryptographic data within standard FIDO extension fields to provide extra verification context to the server. Because both references operate within the FIDO/WebAuthn framework, using Lindemann’s extension structure to carry Islam’s signature related data would have yielded the predictable benefit of improved authentication integrity.
As to claim 12, Islam teaches:
wherein the signature value included in the response message delivered to the passkey server is verified using a public key of an asymmetric key (VERIFYDATA) previously stored in a passkey provider server: (see Islam, [¶¶0032, 0080-0081]: “The public key is sent to and stored by the secure enclave 110 to verify signatures of challenges are from the trusted user computing device 108. User authentication may include successful verification of a challenge signed with a secret device-enclave key (e.g., 325, 415, 505, and/or 605) corresponding to the trusted user computing device 108 and in association with the user. The decrypted secret authentication key (K.sub.SAK) 105 is then used to sign the second RP challenge 805, which is represented by operation 814.”);
(Storing a public key corresponding to the device enclave key to verify challenge signatures. This corresponds to verifying the signature value using a previously stored VERIFYDATA public key at the passkey provider server.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to use Islam’s stored public key verification in the Islam/Lindemann passkey system. A person of ordinary skill would have been motivated to verify returned signature values using a previously stored public key so the server can confirm that the response was signed by the matching private key. The combination would have yielded the predictable benefit of reliable server-side verification of passkey authentication responses.
As to claim 13, Islam teaches:
A computing device, comprising: at least one processor; (see Islam, [¶0083]: “The computing device 900 may include at least one processing unit 910 and a system memory 920.”);
a memory for loading a computer program executed by the at least one processor; (see Islam, [¶0083]: “The system memory 920 may also include an operating system 930 that controls the operation of the computing device 900 and one or more program modules 940. A number of different program modules and data files may be stored in the system memory 920. While executing on the processing unit 910, the program modules 940 may perform the various processes described above.”);
and a storage for storing the computer program: (see Islam, [¶¶0084, 0089]: “The computing device 900 may also have additional features or functionality. For example, the computing device 900 may include additional data storage devices (e.g., removable and/or non-removable storage devices) such as, for example, magnetic disks, optical disks, or tape. The term computer-readable media as used herein may include computer storage media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, or program modules.”);
wherein the computer program includes instructions for performing operations of: in response to receipt of an account creation request from a service application, generating, by a passkey agent, a first asymmetric key (VERIFYDATA) for encryption and decryption to be used in a passkey generation process: (see Islam, [¶¶0002, 0012]: “Upon registration, the relying party may request a new WebAuthn credential from the authenticator, via the browser. In examples, the authenticator creates a pair of keys, one secret and one public. Generate an authentication key pair including an authentication secret key and an authentication public key.”);
(Islam teaches WebAuthn registration request and generation of an asymmetric authentication passkey key pair by an authenticator passkey agent.)
and storing a first private key of the first asymmetric key in a secure area; (see Islam, [¶¶0009, 0030]: “In examples, secret key material is stored in the cloud-based secure enclave and decryption of the secret key material is performed within the cloud-based secure enclave to provide a highly secure system where the secret key cannot be stolen if the user computing device is compromised. In examples, the plaintext secret authentication key (K.sub.SAK) 105 is never outside the boundary of the secure enclave 110.”);
(Storing secret/private authentication key material in a secure enclave.)
Islam does not teach but, Lindemann teaches:
and generating, by the passkey agent, a second asymmetric key is (WRAPPINGDATA_RSA) to be applied to a protective symmetric key (DATAPROTECTION) to be used in a passkey synchronization process: (see Lindemann, [¶¶0685-0686, 0688]: “Has an individual asymmetric wrapping key encryption key (WKEK) 6703, 6713. It may be generated by the authenticator 3710-3711 on first use and never made accessible outside the authenticator. Has a symmetric wrapping key (WK) 6704, 6714 which may be generated on first use and overwritten by each join procedure. The key synchronization logic 6721 will encrypt the wrapping key (WK) 6714 and Group-ID 6712 using the public WKEK 6703 received in the join block.”);
(Lindemann teaches encrypting, for example: applying, the symmetric wrapping key WK using the public asymmetric wrapping key WKEK. Therefore, Lindemann’s WKEK corresponds to the claimed second asymmetric key, and WK corresponds to the claimed protective symmetric key.)
and storing a second private key of the second asymmetric key in the secure area: (see Lindemann, [¶¶0685]: “It may be generated by the authenticator 3710-3711 on first use and never made accessible outside the authenticator.”);
(WKEK private key is kept inaccessible outside the authenticator, corresponding to storing the second private key in a secure area. It would have been obvious to store that key in the same secure area used for the first private key to centralize key protection.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify Islam’s WebAuth/passkey key-generation system to include Lindemann’s asymmetric wrapping key encryption key and symmetric wrapping key synchronization technique. A person of ordinary skill would have been motivated to store and protect critical secret key material in a secure enclave or authenticator secure storage, and to use Lindemann’s WKEK/WK wrapping arrangement to securely synchronize protected authentication key material without exposing private keys. This combination would have yielded the predictable benefit of improved secure key management and synchronization for passkey credentials.
As to claim 14, the combination Islam in view of Lindemann teaches:
wherein the computer program further includes instructions for performing an operation of delivering, by the passkey agent, a first public key of the first asymmetric key and a second public key of the second asymmetric key to a passkey provider server communicating with the computing device: (see Islam, [¶¶0002, 0077]: “The public key is returned to the server via the browser, and the secret key remains on the authenticator. The first RP challenge 705 and the public authentication key (K.sub.PAK) 115 are provided to the relying party 116 by the user computing device 108.”);
(see Lindemann, [¶¶0688]: “The key synchronization logic 6721 will encrypt the wrapping key (WK) 6714 and Group-ID 6712 using the public WKEK 6703 received in the join block.”);
(Islam teaches delivering the first public authentication passkey key to the server. Lindemann teaches exchanging the public WKEK, which corresponds to the second public key used for synchronization.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify Islam’s passkey public-key delivery with Lindemann’s public WKEK exchange. A person of ordinary skill would have been motivated to provide both public keys to support passkey registration and secure synchronization. The combination would have yielded the predictable benefit of enabling server-side credential registration and protected key synchronization.
As to claim 15, Lindemann teaches:
wherein the protective symmetric key is generated by the passkey provider server, and the computer program further includes instructions for performing an operation of receiving, by the passkey agent, a key generated by applying, in the passkey provider server, Public Key Cryptography Standards (PKCS) using the protective symmetric key and the second 5 public key of the second asymmetric key, and storing the received key in the secure area: (see Lindemann, [¶¶0686, 0688]: “Has a symmetric wrapping key (WK) 6704, 6714 which may be generated on first use and overwritten by each join procedure. The key synchronization logic 6721 will encrypt the wrapping key (WK) 6714 and Group-ID 6712 using the public WKEK 6703 received in the join block. This data block is called in the join response block.”);
(Lindemann teaches generating a symmetric wrapping key, WK, corresponding to the protective symmetric key, and encrypting the WK using the public WKEK, which corresponds to the second public key. To the extend Lindemann generates the WK at the authenticator rather than at the passkey provider server, generating the protective symmetric key at the server would have been an obvious design choice among known key management architectures to establish the same symmetric key for secure synchronization. Applying a PKCS key package format here would have been a routine use of a known cryptographic standard.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify the Islam/Lindemann combination so that the passkey provider server generates the protective symmetric key and applies standard PKCS formatting during encryption. A person of ordinary skill would have been motivated to do so because server-side key generation simplifies client-side processing, and PKCS formatting provides a standardized way to package encrypted key material for transfer and parsing. The combination would have yielded the predictable benefit of standardized, secure key transfer during passkey synchronization.
As to claim 17, Lindemann teaches:
wherein the computer program further includes instructions for performing operations of: generating, by the passkey agent, an is attestation (Attestation.Device) for verifying whether the computing device has been hacked, when a hacking attempt on the computing device is identified, and storing the attestation in the secure area; (see Lindemann, [¶¶0169, 0178]: “In one embodiment, the AK uses the attestation key 1215 to validate the model and/or integrity of the authenticator during registration. In one embodiment, the registration message sent to the RP 1320 also has multiple (chained) signatures, one with the AK's attestation key 1605 and one for each of the other components (e.g., the UVC's attestation key 1604 and the DC's attestation key (not shown)).”);
(Lindemann teaches generating attestation data to validate authenticator integrity. To the extent Lindemann performs this during registration, it would have been obvious to generate and store the attestation when a hacking attempt is identified, because performing integrity attestation after detecting a security event is a routine security practice.)
and delivering, by the passkey agent, the attestation to a passkey provider server: (see Lindemann, [¶¶0178, 0430]: “In one embodiment, the registration message sent to the RP 1320 also has multiple (chained) signatures, one with the AK's attestation key 1605 and one for each of the other components (e.g., the UVC's attestation key 1604 and the DC's attestation key (not shown)). An attestation over the new device public key associated with the relying party (ND_Uauth.pub). In one embodiment, the attestation comprises a signature generated over the public key (e.g., using a public key of the relying party).”);
(Sending attestation/signature data to the relying party/server, corresponding to delivering the attestation to the passkey provider server.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to use Lindemann’s attestation technique in the Islam/Lindemann passkey system. A person of ordinary skill would have been motivated to send device authenticator attestation information to the server so the server can verify device integrity before trusting passkey key material. The combination would have yielded the predictable benefit of improving protection and verification of improved detection of compromised or untrusted devices during passkey registration and synchronization.
Claims 4, 6, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Islam et al (U.S. PGPub. No. US 2024/0283664 A1, hereinafter Islam) in view of Lindemann et al (U.S. PGPub. No. 2018/0191501, hereinafter Lindemann), and in further view of Cooley et al. (U.S. Pat. No. 9,639,710 B2, hereinafter Cooley).
As to claim 4, Cooley teaches:
further comprising: storing, by the passkey agent, a first key (PIN_INFO) for encryption and a second key (PIN_ID) for verification, in the secure area, the first and second keys being generated using PIN input information of a user; (see Cooley, [4:42- 44]; [5:1-4]: “The PIN (and a random 256 byte salt) may be used to generate an encryption key (EK2) used to encrypt the PIN encryption key (EK1). In addition, the encryption client 102 generates a device lookup key (PID) from the PIN value (and salt). For example, the PID key may be a 32 byte value generated from the PIN and salt value using 10,000 iterations of PBKDF2.”);
(Cooley teaches generating an encryption key from PIN information and also generating a PIN lookup or verification key, PID, from the PIN value.)
and delivering, by the passkey agent, a symmetric key of the second key to the passkey provider server: (see Cooley, [7:19-20]; [3:25-27]: “The mobile device sends the PID key and device ID to the server. The PID key, along with a device ID, may be used by the server as a device specific lookup combination. The device key may be generated as random data.”);
(Delivering the PIN-derived PID key to the server for lookup/verification. To the extent Cooley’s PID is an identification key rather than expressly a symmetric key, implementing the verification key a symmetric key, such as an HMAC key, would have been a routine cryptographic choice to authenticate the server-side verification request.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify the Islam/Lindemann passkey system to include Cooley’s PIN-derived encryption and verification key techniques. A person of ordinary skill would have been motivated to generate and store PIN-derived encryption and verification keys in a secure area and provide verification related key information to the server to support secure user authentication and recovery operations. The combination would have yielded the predictable benefit of improving protection and verification of passkey related key material using user PIN-based security.
As to claim 6, the combination Islam in view of Cooley teaches:
A security management method for a passkey service, the security management is method performed by a computing device, comprising: in response to receipt of a passkey generation request from a service application, generating, by a passkey agent, a private key (PASSKEY_PRIVATEKEY) and a public key (PASSKEY_PUBLICKEY) of a passkey and storing the private and public keys in a secure area; (see Islam, [¶¶0002, 0012]: “Upon registration, the relying party may request a new WebAuthn credential from the authenticator, via the browser. In examples, the authenticator creates a pair of keys, one secret and one public. The public key is returned to the server via the browser, and the secret key remains on the authenticator. Generate an authentication key pair including an authentication secret key and an authentication public key.”);
(Islam teaches generating a WebAuthn/passkey key pair including a secret/private key and a public key.)
Islam does not teach, but Cooley teaches:
generating, by the passkey agent, an encrypted private key (Encrypted PASSKEY_PRIVATEKEY) of the passkey by performing primary encryption on the private key of the passkey using a key (PIN_INFO) derived from PIN input information of a user: (see Cooley, [Abstract]; [4:42- 44]; [7:10-13]: “The second encryption key is derived from the PIN value. The PIN (and a random 256 byte salt) may be used to generate an encryption key (EK2) used to encrypt the PIN encryption key (EK1). As noted, EK2 comprises an encryption key generated based on the PIN value and current salt using a password based key derivation function.”);
(Cooley teaches deriving an encryption key from user PIN information and using that PIN derived key to encrypt protected key material.)
and then performing secondary encryption using a protective symmetric key (DATAPROTECTION) previously stored in the secure area; (see Cooley, [3:37- 38]; [6:53-55]; [7:39-46]: “The vault key is encrypted with PIN encryption key (EK1) and stored on the client. At step 310, the mobile device initializes an encryption engine with EK1 and an initialization vector (e.g., 16 bytes of random data). In addition, the client key store 104 stores the encrypted vault key 506 needed to access encrypted vault data 508. The vault key 506 has been encrypted using the encryption key EK1 (and an initialization vector). The vault data 508 is encrypted using the vault key (VK) (and another initialization vector). Importantly, the encryption key (EK1) used to encrypted the vault key (VK) is not accessible in the client key store 104.”);
(Coley teaches using EK1 to encrypt the protected key material, and EK1 is a symmetric encryption key because it describes initializing an encryption engine with EK1 to encrypt the vault key. This corresponds to using a protective symmetric key for an additional encryption layer.)
and delivering, by the passkey agent, the encrypted private key of the passkey to a passkey provider server communicating with the computing device: (see Cooley, [2:4-7]; [7:23-24]: “The second encryption key is derived from a user-supplied value entered on the computing device. This method may also include sending the encrypted first encryption key to a remote server. As part of this step, the mobile device also sends the signed, encrypted package storing EK1 to the server.
(Sending encrypted protected key material from the computing device to a remote server, corresponding to delivering the encrypted private key to a passkey provider server.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify Islam’s passkey system to include Cooley’s PIN-derived and layered encryption techniques. A person of ordinary skill would have been motivated to apply these layered keys, including the PIN-derived key and stored protective symmetric key, to encrypt the passkey private key before server delivery. Whether the protective symmetric key is applied as the primary or secondary layer is a predictable choice among known cryptographic design options. This combination would have yielded the predictable benefit of multi-layered key protection and improved security for passkey private key material during server synchronization.
As to claim 10, the combination Islam in view of Cooley teaches:
further comprising: performing, by the passkey agent, primary decryption on a key delivered through encryption of the encrypted private key stored in the secure area of the passkey provider server, using the protective symmetric key previously stored in the secure area; (see Cooley, [8:19- 26]: “Once initialized the encryption engine recovers EK1 from the encrypted package. At step 630, the encryption engine is initialized using the recovered PIN encryption key (EK1) and corresponding initialization value. Thereafter the encryption engine can decrypt the package storing the encrypted vault key, i.e., the engine recovers the vault key (VK), allowing the vault data to be decrypted.”);
(Cooley teaches decrypting a key package using an encryption key, corresponding to performing primary decryption on protected key material. To the extent Cooley applies its decryption layers in a different order, performing primary decryption with the stored protective symmetric key and secondary decryption with the PIN-derived key would have a predictable variation of Cooley’s layered decryption technique.)
performing, by the passkey agent, secondary decryption using a key (PIN_INFO) derived from the PIN input information of the user; (see Cooley, [8:10- 11]; [8:19-21]: “At step 620, the mobile device regenerates, from the PIN and current salt, the encryption key (EK2). Once initialized the encryption engine recovers EK1 from the encrypted package.”);
(Cooley teaches regenerating an encryption key from a user PIN and using it to decrypt protected key material, corresponding to performing secondary decryption using a key derived from PIN input information.)
and synchronizing the passkey through the primary and secondary decryptions: (see Islam, [¶0030]: “In further examples, the encrypted secret authentication key (K.sub.SAK-E) 150 can be synchronized and made available to the user across a plurality of the user computing devices 108 and the user does not need to know where the encrypted secret authentication key (K.sub.SAK-E) 150 resides (e.g., unlike current methods, where users may be required to remember on which platform vendor their authentication credential is stored and/or where a specialized flow may be required to transfer a challenge from one platform to another in order to sign it using the correct authentication credential).”);
(see Cooley, [8:23-26]: “Thereafter the encryption engine can decrypt the package storing the encrypted vault key, i.e., the engine recovers the vault key (VK), allowing the vault data to be decrypted.”);
(Islam teaches synchronization of encrypted passkey/private key material across user devices, and Cooley teaches using layered decryption to recover protected key material. Together, they teach synchronizing the passkey through primary and secondary decryptions.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify Islam’s passkey synchronization system to use Cooley’s PIN-derived and layered decryption techniques. A person of ordinary skill would have been motivated to use layered decryption so that synchronized passkey private key material could only be recovered after both stored key protection and user PIN-derived protection are satisfied. Whether the protective symmetric key layer or the user PIN-derived layer is decrypted first represents a predictable choice among known cryptographic engineering alternatives. The combination would have yielded the predictable benefit of secure passkey synchronization and recovery while reducing the risk of unauthorized access to private key material.
As to claim 16, Cooley teaches:
wherein the computer program further includes instructions for performing operations of: storing, by the passkey agent, a first key PIN_INFO for encryption and a second key PIN_ID for verification, in the secure area, the first io and second keys being generated using PIN input information of a user; (see Cooley, [4:42- 44]; [5:1-4]: “The PIN (and a random 256 byte salt) may be used to generate an encryption key (EK2) used to encrypt the PIN encryption key (EK1). In addition, the encryption client 102 generates a device lookup key (PID) from the PIN value (and salt). For example, the PID key may be a 32 byte value generated from the PIN and salt value using 10,000 iterations of PBKDF2.”);
(Cooley teaches generating an encryption key from PIN information and also generating a PIN lookup or verification key, PID, from the PIN value.)
and delivering, by the passkey agent, a symmetric key of the second key to the passkey provider server: (see Cooley, [7:19-20]; [3:25-27]: “The mobile device sends the PID key and device ID to the server. The PID key, along with a device ID, may be used by the server as a device specific lookup combination. The device key may be generated as random data.”);
(Delivering the PIN-derived PID key to the server for lookup/verification. To the extent Cooley’s PID is an identification key rather than expressly a symmetric key, implementing the verification key a symmetric key, such as an HMAC key, would have been a routine cryptographic choice to authenticate the server-side verification request.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the clamed invention to modify the Islam/Lindemann passkey system to include Cooley’s PIN-derived encryption and verification key techniques. A person of ordinary skill would have been motivated to generate and store PIN-derived encryption and verification keys in a secure area and provide verification related key information to the server to support secure user authentication and recovery operations. The combination would have yielded the predictable benefit of improving protection and verification of passkey related key material using user PIN-based security.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARHAM AHMED whose telephone number is (571)272-8950. The examiner can normally be reached Monday-Friday 7:30 am - 5 pm. Alternate Friday off..
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Alexander Lagor can be reached at (571) 270-5143. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/A.N.A./Examiner, Art Unit 2437
/BENJAMIN E LANIER/Primary Examiner, Art Unit 2437
Prosecution Insights