DETAILED ACTION
This action is in response to the application filed on October 16, 2024. Claims 1-20 are pending. Claims 1-8 represent a method, claims 9-15 represents a system, and claims 16-20 represents a non-transitory computer accessible medium directed to restricting fido key derivation identity binding.
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 .
Specification
The abstract of the disclosure is objected to because in line 1, the abstract contains the acronym “FIDO” and should be expanded upon during its initial representation to disclose “fast identification online”. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
Claim Objections
Claims 10 and 15 are objected to because of the following informalities:
Claim 10 and 15 disclose the term “Wherein” which should not be capitalized.
Appropriate correction is required.
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-8 and 16-20 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.
Claims 1 and 16 recites the limitation "the issuing entity" and “the account issuing party” in lines 12 and 13. Unclear if the applicant is referencing the “account issuing entity” previously used. There is insufficient antecedent basis for this limitation in the claim.
Claims 2-8 and 17-20 are rejected due to their dependency on claims 1 and 16.
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.
Claim(s) 1-8 and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jordan et al. (NPL: VICEROY: GDPR-/CCPA-compliant Enforcement of Verifiable Accountless Consumer Requests), hereinafter referred to as Jordan, in view of Wen et al. (US 20210272097), hereinafter referred to as Wen.
Regarding Claim 1, Jordan discloses:
A method for generation of a verifiable fast identification online (FIDO) security key, the method comprising: generating an extended public key from an extended private key (On page 5, Section IV.D, Jordan discloses “The client first generates a master private key sk(t) on a trusted consumer device t. This key is then used to derive a device-specific public key for each of device the client will use for interacting with websites, e.g., pk(t/i) for device i.”), the extended public key being stored with an account issuing entity (On page 5, Section IV.D, Jordan discloses “The device public keys are stored within the respective devices for rapid future VCR key generation.”); deriving, from the extended private key, a plurality of child key pairs, including a plurality of child private keys and a plurality of corresponding child public keys (On page 7, Section V.A, Jordan discloses “Extended keys can be used to derive one or more child keys, following the rule that private keys can be used to derive private or public keys, while public keys can only derive public keys.”), wherein the extended private key is stored on an authenticator device associated with a user (On page 6, Table 1, Jordan discloses “Master private key: generated and stored in trusted device”), initiating a FIDO registration of the authenticator device with a FIDO-reliant site using a user-specific identifier and a site-specific child public key derived for a FIDO-reliant party (On page 5, Section IV.D, Jordan discloses “The client generates a new VCR public key pk(t/i/j) for session j, derived from the device public key. The client then sends this newly-generated key, along with the client id cookie, to the server as shown in Figure 1 (B).”); sending, by the FIDO-reliant party, the user-specific identifier and the site-specific child public key to the issuing entity (On page 9, Section V.D, Jordan discloses “The client’s browser extension sends the client id cookie set by the server and a freshly-generated VCR public key to this endpoint, and the server then generates a wrapper that cryptographically binds these two pieces of information.”); verifying, by the account issuing party, that the site-specific child public key is associated with the user-specific identifier using the extended public key to derive a matching key (On page 5, Section IV.D, Jordan discloses “Upon receiving a VCR, the server first verifies its own signature on the wrapper to confirm the authenticity of the wrapper. The server then verifies the client’s signature on the VCR using the public key pk(t/i/j) from the wrapper. If these checks succeed, the server accepts the VCR and proceeds with the requested data operation.”); and completing the FIDO registration upon receiving a verification message from the account issuing entity (On page 8, in section V.A, Jordan discloses “Finally, the server’s response is displayed in the client’s browser.”).
However, Jordan does not explicitly disclose the authenticator device provided by an account issuing entity.
Wen discloses:
the authenticator device being provided by the account issuing entity (In ¶ 41, Wen discloses “Contactless-enabled card 120 may be any suitable payment or other identify card that is NFC or similarly enabled. For example, contactless-enabled card 120 may be a credit card, a debit card, etc. that may be issued by a financial institution.”);
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Jordan’s approach by utilizing Wen’s approach of use an authenticator device or contactless card issued by the verifying entity as the motivation would be to add an additional layer of protection when attempting to access or perform an action (See Wen, ¶ 90).
Regarding Claim 2, the combination of Jordan and Wen disclose the limitations of claim 1.
However, Jordan does not explicitly disclose the authenticator device provided by an account issuing entity.
Wen discloses:
wherein the account issuing party corresponds to a financial institution associated with a user financial account. (In ¶ 41, Wen discloses “Contactless-enabled card 120 may be any suitable payment or other identify card that is NFC or similarly enabled. For example, contactless-enabled card 120 may be a credit card, a debit card, etc. that may be issued by a financial institution.”);
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Jordan’s approach by utilizing Wen’s approach of use an authenticator device or contactless card issued by the verifying entity as the motivation would be to add an additional layer of protection when attempting to access or perform an action (See Wen, ¶ 90).
Regarding Claim 3, the combination of Jordan and Wen disclose:
The method of claim 1, wherein the user-specific identifier corresponds to one of a user name and an email address associated with the user. (On page 2, section II.A, Jordan discloses “information is paired with a name, telephone number, email address…Information paired with an identifier created by a business (e.g., a cookie) is personally identifiable if it can be combined with other information to allow the consumer to whom it relates to be identified [34].”)
Regarding Claim 4, the combination of Jordan and Wen disclose:
The method of claim 1, wherein a FIDO challenge request from the FIDO-reliant party is signed by a child private key corresponding to the child public key registered with the FIDO-reliant site (On page 4, section IV.B, Jordan discloses “When the client issues a VCR signed with the relevant VCR private key (as described above), the client also sends the corresponding cookie wrapper to the server, along with the request.”).
Regarding Claim 5, the combination of Jordan and Wen disclose:
The method of claim 4, wherein the FIDO challenge request is transmitted in response to a FIDO authentication request initiated from the authenticator device storing the extended private key. (On page 5, section IV.D, Jordan discloses “When initiating a session with a server, upon a client request, the server generates a unique client id and sends it to the client in the form of a cookie.”)
Regarding Claim 6, the combination of Jordan and Wen disclose the limitations of claim 1.
However, Jordan does not explicitly disclose the authenticator device consisting of a contactless card.
Wen discloses:
wherein the authenticator device corresponds to a contactless card. (In ¶ 41, Wen discloses “Contactless-enabled card 120 may be any suitable payment or other identify card that is NFC or similarly enabled. For example, contactless-enabled card 120 may be a credit card, a debit card, etc. that may be issued by a financial institution.”);
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Jordan’s approach by utilizing Wen’s approach of use an authenticator device or contactless card issued by the verifying entity as the motivation would be to add an additional layer of protection when attempting to access or perform an action (See Wen, ¶ 90).
Regarding Claim 7, the combination of Jordan and Wen disclose:
The method of claim 6, wherein the contactless card communicates with the FIDO-reliant party, via an intermediary communication device (On page 7, section V.A, Jordan discloses “It also handles communication between the browser and the trusted device (or application) that holds the master private key”).
Regarding Claim 8, the combination of Jordan and Wen disclose:
The method of claim 1, wherein the authenticator device corresponds to a computing device storing the extended private key (On page 6, Table 1, Jordan discloses “Master private key: generated and stored in trusted device”).
Claims 16-20 are directed to a non-transitory computer-accessible medium having functionality corresponding to the method of Claims 1-5 respectively, and are rejected by a similar rationale, mutatis mutandis.
Claim(s) 9 and 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over Jordan et al. (NPL: VICEROY: GDPR-/CCPA-compliant Enforcement of Verifiable Accountless Consumer Requests), hereinafter referred to as Jordan, in view of Lindemann et al. (US 20230091318), hereinafter referred to as Lindemann.
Regarding Claim 9, Jordan discloses:
A system for implementing a pre-registration of FIDO security keys, the system comprising an authenticator device comprising a processor and a memory, (On page 8, section V.C, Jordan discloses “We implemented a proof-of-concept trusted device using the Solokey Hacker [51], a security token with open source software and hardware. Solokey includes an STM32L432KC microprocessor with an Arm Cortex-M4 MCU (80MHz) 64 kB of RAM, 256 kB of flash memory”), an extended private FIDO key generated using a hierarchically deterministic key generation algorithm (On page 7, section V.A, Jordan discloses “To realize derivable asymmetric keys, we used a mechanism proposed for hierarchical deterministic wallets, commonly known as Bitcoin Improvement Proposal 32 [60], or BIP32.”), wherein the processor is configured to: generate a child FIDO key pair including a child private key and a child public key (On page 7, Section V.A, Jordan discloses “Extended keys can be used to derive one or more child keys, following the rule that private keys can be used to derive private or public keys, while public keys can only derive public keys.”); transmit the child public key along with the user-specific identifier to a FIDO-reliant server during a FIDO registration process associated with the authenticator device (On page 5, Section IV.D, Jordan discloses “The client generates a new VCR public key pk(t/i/j) for session j, derived from the device public key. The client then sends this newly-generated key, along with the client id cookie, to the server as shown in Figure 1 (B).”); a server, comprising a processor and a memory, the memory containing the user-specific identifier and an extended public FIDO key generated from the extended private FIDO key (On page 5, Section IV.D, Jordan discloses “The device public keys are stored within the respective devices for rapid future VCR key generation.”), wherein the processor being configured to: receive the child public key along with the user-specific identifier from the FIDO reliant server during the FIDO registration process of the authenticator device (On page 9, Section V.D, Jordan discloses “The client’s browser extension sends the client id cookie set by the server and a freshly-generated VCR public key to this endpoint, and the server then generates a wrapper that cryptographically binds these two pieces of information.”), verify that the child public key is associated with the user-specific identifier using the extended public FIDO key (On page 5, Section IV.D, Jordan discloses “Upon receiving a VCR, the server first verifies its own signature on the wrapper to confirm the authenticity of the wrapper. The server then verifies the client’s signature on the VCR using the public key pk(t/i/j) from the wrapper. If these checks succeed, the server accepts the VCR and proceeds with the requested data operation.”); and transmit a verification message to the FIDO-reliant server, the verification being operative to complete a registration of the authenticator device associated with the child public key and the user-specific identifier (On page 8, in section V.A, Jordan discloses “Finally, the server’s response is displayed in the client’s browser.”).
However, Jordan does not explicitly disclose the authenticator device storing the user identifier.
Lindemann discloses:
the memory containing a user-specific identifier (In ¶ 501, Lindemann discloses “the Interface 4602 may also provide secure access to a secure storage device 4620 on the client 4600 which stores information related to each of the authentication devices 4610-4612 such as a device identification code, user identification code,”)
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Jordan’s approach by utilizing Lindemann’s approach of storing a unique identifier on the authenticator device as the motivation would be to allow the identifier to be used when communicating with other parties and associating the identifier with keys used for authentication and registration. (See Lindemann, ¶ 501).
Regarding Claim 12, the combination of Jordan and Lindemann disclose:
The system of claim 9, wherein the child public key corresponds to a site-specific FIDO public key uniquely associated with the FIDO-reliant server. (On page 5, Section IV.D, Jordan discloses “The client generates a new VCR public key pk(t/i/j) for session j, derived from the device public key. The client then sends this newly-generated key, along with the client id cookie, to the server as shown in Figure 1 (B).”);
Regarding Claim 13, the combination of Jordan and Lindemann disclose:
The system of claim 12, wherein the unique association is generated by using a site-specific identifier for generating the child FIDO key pair. (On page 12, section VII, Jordan discloses “Such applications can use VICEROY wrappers to bind client-generated public keys to any type of symmetric session identifier, and the same protocol to issue VCRs for data associated with that identifier.”)
Regarding Claim 14, the combination of Jordan and Lindemann disclose:
The system of claim 9, wherein the verification comprises deriving a child public key from an origin public key and confirming a match between the generated child public key and the received child public key. (On page 5, Section IV.D, Jordan discloses “Upon receiving a VCR, the server first verifies its own signature on the wrapper to confirm the authenticity of the wrapper. The server then verifies the client’s signature on the VCR using the public key pk(t/i/j) from the wrapper. If these checks succeed, the server accepts the VCR and proceeds with the requested data operation.”)
Regarding Claim 15, the combination of Jordan and Lindemann disclose:
The system of claim 14, Wherein deriving the child public key comprises using a site-specific ID received from the FIDO-reliant server along with the extended public key to derive the child public key for matching against a registered child public key. (On page 5, Section IV.D, Jordan discloses “Upon receiving a VCR, the server first verifies its own signature on the wrapper to confirm the authenticity of the wrapper. The server then verifies the client’s signature on the VCR using the public key pk(t/i/j) from the wrapper. If these checks succeed, the server accepts the VCR and proceeds with the requested data operation.”)
Claim(s) 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Jordan et al. (NPL: VICEROY: GDPR-/CCPA-compliant Enforcement of Verifiable Accountless Consumer Requests), hereinafter referred to as Jordan, in view of Lindemann et al. (US 20230091318), hereinafter referred to as Lindemann, in further view of Wen et al. (US 20210272097), hereinafter referred to as Wen.
Regarding Claim 10, the combination of Jordan and Lindemann disclose the limitations of claim 9.
However, Jordan does not disclose the association of the issuer of the authentication device.
Wen discloses:
Wherein the server is associated with an issuer of the authenticator device for a user identified by the user-specific identifier (In ¶ 73, Wen discloses “In step 335, the backend may retrieve contactless card data for cards associated with the user associated with the authentication credential, and may verify that the card data received matches that for a contactless card issued to the user.”)
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Jordan’s approach by utilizing Wen’s approach of use an authenticator device or contactless card issued by the verifying entity as the motivation would be to add an additional layer of protection when attempting to access or perform an action (See Wen, ¶ 90).
Regarding Claim 11, the combination of Jordan, Lindemann and Wen disclose the limitations of claim 10.
However, Jordan does not explicitly disclose the authenticator device provided by an account issuing entity.
Wen discloses:
wherein the issuer of the authenticator device corresponds to an account issuing party. (In ¶ 41, Wen discloses “Contactless-enabled card 120 may be any suitable payment or other identify card that is NFC or similarly enabled. For example, contactless-enabled card 120 may be a credit card, a debit card, etc. that may be issued by a financial institution.”);
One of ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Jordan’s approach by utilizing Wen’s approach of use an authenticator device or contactless card issued by the verifying entity as the motivation would be to add an additional layer of protection when attempting to access or perform an action (See Wen, ¶ 90).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kim IL Young (KR 20200064017) discloses a method for using FIDO2.0 with blockchain.
You Ji Eun (KR 20220111027) discloses methods for a server mediating a fast identity online authentication for a user accessing a website.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHADI H KOBROSLI whose telephone number is (571)272-1952. The examiner can normally be reached M-F 9am-5pm ET.
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, Rupal Dharia can be reached at 571-272-3880. 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.
/SHADI H KOBROSLI/Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492