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 . In communications filed on 04/27/2026. Claims 1, 3, 7-8, 14-15, 17, and 20 are amended. Claims 1-20 are pending in this examination.
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 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. This examination is in response to US Patent Application No. 17/335,118.
Examiner Note
Examiner withdrawn the previously raised claim objection for claims 7, 14, and 20.
Applicant’s amendment to claims 1, 8, and 15 obviates previously raised claims 1-20, 35 U.S.C .112(b) second paragraph rejection for the claims containing the word “being”, and “root key”.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 7, 14, and 20 rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. The claims 7, 14, and contain the limitation “wherein the authenticating entity determines that the public key of the SYH certificate is the public key of the authorized entity by: comparing the public key of the SYH certificate to the public key of the authorized entity; and determining that the public key of the SYH certificate has been digitally signed by the CA-CO system using at the certificate authority root key that is known to the authenticating entity and associated with a CA-CO”. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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-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 pre-AIA the applicant regards as the invention.
In regard to Claims 1, 8, and 15, the limitation “the SYH certificate to a stored public key of the authorized entity and verifying that the SYH certificate has been digitally signed by a certificate authority using a certificate authority root key known to the authenticating entity.” renders the claim indefinite, because, the root key has not been described in the specification to indicate what kind of the key it is, and if we consider this key being the CA private key for signing the SYH certificate, then, how come this private key is known to the authenticating entity? Does CA share its private keys with other entities? And if it is a private key, then what is the root key that signs a certificate?
Claims 2-7, 9-14,and 16-20 do not cure the deficiency of claims 1, 8, and 15 and are rejected under 35 USC 112, 2nd paragraph, for their dependency upon claims 1, 8, and 15.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL. —The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement.
The independent claims 1,8 , and 15 contain “receiving, using a processor of an authenticating entity, an SYH certificate from a to-be-authenticated (TBA) entity, the SYH certificate being presented unaltered by the to-be- authenticated entity and not signed by the to-be-authenticated entity; and determining, using the processor, that the SYH-MFA factor is satisfied by determining that the SYH certificate possessed by the TBA entity is valid by evaluating key data included in the SYH certificate, the key data comprising a public key of an authorized entity, including comparing the public key in the SYH certificate to a stored public key of the authorized entity and verifying that the SYH certificate has been digitally signed by a certificate authority using a root key known to the authenticating entity.” which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention. The claimed underlined limitation above contradict what is described in the specification( see below) in that the TBA entity send the SYH digital certificate to the authenticating entity , not the SYH certificate.
Applicant specification in paragraphs 24, and 33, and claimed limitations mentioned above contradicts each other , claim 24 states: [0024…A first one of the multiple categories of MFA factors includes the novel SYH digital certificate 174. In accordance with embodiments of the invention, the SYH certificate 174 is configured such that the TBA entity 120 can satisfy the SYH authentication factor by presenting an SYH certificate 174, unaltered by the TBA entity 120, to the authenticating entity 140 and having the authenticating entity 140 determine that the SYH certificate 174 presented by the TBA entity 120 is valid], and claim 33 states: [0033…The CO-1120C generates a request for certificate (not shown) containing CO-1public key 404 and the CO-1 identification 408 and sends the request to the CA CO-0 system 402, which is in possession of a root key 420 for the CA CO-0 system 402. CA CO-0 system 402 verifies the identity of the CO-1120C in some manner and generates the SYH digital certificate 174A containing CO-1public key 404 that was signed with the CA CO-0 root key 420. The SYH digital certificate 174A is then returned to CO-1120C. An entity (e.g., ES 140A) that receives SYH digital certificate 174A can verify the validity of the root key signature by using CO-1public key 404, which is published and available to the verifying entity. In operation, the CA CO-0 system 402 can create a SYH digital certificate for each of the other COs 120A(i.e., CO-2 120D and CO-3 120E) using their sets of public keys. The appropriate CO's SYH digital certificate (e.g., SYH digital certificate 174A) can be incorporated in any signed command submitted to the ES 140A by the actors 302 (shown in FIG. 3), and the ES 140A will check the root key signature in order to validate that the entity submitting the SYH digital certificate is in possession of a valid SYH digital certificate. An adversary will not be able to forge a SYH digital certificate 174, 174A because the SYH digital certificates will be signed the CA CO-0 root key 420. Although the SYH digital certificate 174, 174A will, in principle, be public knowledge, an adversary cannot use the SYH digital certificate as its own because the public key in the SYH digital certificate 174, 174A matches the public key of the authorized entity for which the SYH certificate 174, 174A was generated, and because the public key is known independently by the authorizing entity when it is time to validate the SYH certificate 174, 174A.] .
Applicant is kindly requested to show the examiner support in the original disclosure for the new or amended claims. See MPEP 714.02 and 2163.06 (“Applicant should specifically point out the support for any amendments made to the disclosure").
Claims 2-7, 9-14,and 16-20 do not cure the deficiency of claims 1, 8, and 15 and are rejected under 35 USC 112, 1st paragraph, for their dependency upon claims 1, 8, and 15.
Claim Comment on 35 USC § 101
There is no need for a rejection of Claims 15-20 under 35 U.S.C. 101. Although Claims 15-20 are drawn towards a " computer program product comprising a computer readable program stored on a computer readable storage medium" which could include a non-statutory digital signal, the specification clearly states that propagating signals are excluded [paragraph 066, The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination… A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire].
Response to Arguments
Applicant's arguments filed 04/27/2026 have been fully considered but they are not persuasive:
Applicant submits on pages 13-16 of remarks filed on 04/27/2026 regarding claim 1 that on pages 10-13 of the remarks filed 12/08/2025,the "Response to Arguments" does not fully answer the distinctions raised in Applicants' prior remarks.
Examiner respectfully disagrees with applicant argument for claim 1 filed on 04/27/2026 on pages 13-16 of remarks. Examiner maintain the rejection.
Per Response to Argument (1):
Peeters discloses:
receiving, using a processor of an authenticating entity, an SYH certificate from a to-be-authenticated (TBA) entity, the SYH certificate being presented unaltered by the to-be- authenticated entity and not signed by the to-be-authenticated entity [Abstract, A key fob device (equated to SYH authentication factor, to-be-authenticated (TBA) entity), in one embodiment, includes a transceiver that receives and sends signals, a memory that stores a public key and a certificate of authenticity associated with the key fob device( equated to the certificate unaltered and not signed), and a processor coupled to the transceiver and memory. The processor is configured to execute instructions causing the key fob device to transmit the public key and the certificate of authenticity, execute a public key agreement protocol to generate a common secret encryption key.
[0034] The initial pairing process 300 may begin by the pairing device 302 receiving from the key fob 204 the PK.sub.KF and the Cert.sub.KF associated with the key fob, step 1a. The information may be sent to the pairing device 302 from the key fob 204 as a result of a request sent by the pairing device 302. Alternatively, the key fob 204 may be periodically broadcasting its PK.sub.KF and Cert.sub.KF. The pairing device 302 may then verify the identity of the key fob 204 by verifying the authenticity of the Cert.sub.KF, step 1b. The Cert.sub.KF may be verified by the pairing device
Examiner Note: It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to indicate that if the key fob device stores the original certificate received from certificate authority in the memory since there is no indication of any altering or singing the certificate by TBA entity.
Per Response to Arguments (2, and 3):
Peeters discloses:
and determining, using the processor, that the SYH-MFA factor is satisfied by determining that the SYH certificate possessed by the TBA entity is valid by evaluating key data included in the SYH certificate, the key data comprising a public key of an authorized entity, including comparing the public key in the SYH certificate to a stored public key of the authorized entity
[Abstract, A key fob device (equated to SYH authentication factor, to-be-authenticated (TBA) entity), in one embodiment, includes a transceiver that receives and sends signals, a memory that stores a public key and a certificate of authenticity associated with the key fob device( equated to the certificate unaltered and not signed), and a processor coupled to the transceiver and memory. The processor is configured to execute instructions causing the key fob device to transmit the public key and the certificate of authenticity, execute a public key agreement protocol to generate a common secret encryption key], and
[Claim 10. The key fob device of claim 9, wherein the certificate authority is a vehicle manufacturer], and [¶5, Another solution to the above problem may be a method to pair a key fob and a control unit of a vehicle that includes reading, by a pairing device, a public encryption key (PKKF) and a certificate of authenticity (CertKF) from a key fob, verifying, by the pairing device, the CertKF using a public encryption key of a vehicle manufacturer (PKVM), transmitting, by the pairing device, a certificate of authenticity (CertVD) to a control unit, verifying, by the control unit, the CertVD using the PKVM], and [¶21, The certificate-based approach to pairing a key fob to a control unit may involve all actors (manufacturers, assemblers, dealerships, etc.) to obtain a public and secret (private) encryption key, which may be used to authenticate one another in the pairing process. That may mean that each vehicle dealership (or dealer/pairing device), the vehicle manufacturer, each key fob manufactured and assembled and each control unit manufactured and installed in a vehicle to have their own associated public/secret key pairs. Once the components involved have acquired their key pairs, the public keys may be certified by a trusted third party or a certificate authority (CA). The CA may receive the public key and identification from the associated component to prove their identity. After their identity is proven, the CA may then sign the party's public key with the trusted third party's secret key. The signed public key becomes the certificate of authenticity for the requesting party. To verify the identity of a certificate, another party needs to unlock the certificate using the trusted third party's public key. The CA, for example, may be the vehicle manufacturer or a third party designated by the car manufacturer], and [¶¶24-25, Each key fob may have a public key (PK.sub.KF) and a secret key (SK.sub.KF) pair assigned to it and internally stored. The PK.sub.KF/SK.sub.KF pair may be generated for and installed in each key fob by the key fob manufacturer 102, the key fob assembly 104 or the vehicle manufacturer 110. The vehicle manufacturer 110 may choose the most trusted entity for the generation and installation of the PK.sub.KF/SK.sub.KF pairs to ensure secrecy and security. The same goes for each control unit that is manufactured and installed in a vehicle—each will have a key pair (PK.sub.CU/SK.sub.CU) generated and installed into an associated CU by a trusted party—the CU manufacturer 106, the CU assembly 108 or the vehicle manufacturer 110. In addition to the key fobs and CUs including their respective PK/SK pairs, each unit may also include a certificate of authenticity (Cert) that authenticates the component's identity. Conventionally, a Cert is a verified and signed public key where the Cert is signed by a CA. The CA may sign a Cert with its secret key. For security reasons, the vehicle manufacturer 110 may be the trusted third party so they can control the flow and validity of Certs in the manufacturing and key fob-auto pairing process. As such, the vehicle manufacturer 110 may sign all public keys with its secret key (SK.sub.VM) to generate a corresponding certificate. For example, a Cert.sub.KF will be inserted into an associated key fob. A Cert.sub.CU may correspond to a CU], and [¶34, The initial pairing process 300 may begin by the pairing device 302 receiving from the key fob 204 the PK.sub.KF and the Cert.sub.KF associated with the key fob, step 1a. The information may be sent to the pairing device 302 from the key fob 204 as a result of a request sent by the pairing device 302. Alternatively, the key fob 204 may be periodically broadcasting its PK.sub.KF and Cert.sub.KF. The pairing device 302 may then verify the identity of the key fob 204 by verifying the authenticity of the Cert.sub.KF, step 1b. The Cert.sub.KF may be verified by the pairing device using the stored PK.sub.VM. The verification of the Cert.sub.KF may be performed by hashing the Cert.sub.KF with the PK.sub.VM].
Examiner Note: Examiner maps the claimed limitation based on what is claimed. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to indicate that something you have device such as key fob device with certificate of authenticity is used as one of the multi-factor authentication , and also indicate that the public key and certificate associated with the fob device and its identity is verified by the paring device using the public key of the fob device, and also indicate that the public keys of all the devices are publicly available for all device and can be shared among all the devices for the purpose of identification , comparison and for other purposes.
Per Response to Argument (4):
Peeters discloses:
and verifying that the SYH certificate has been digitally signed by a certificate authority using a certificate authority root key known to the authenticating entity
[Claim 9. The key fob device of claim 1, wherein the certificate of authenticity is signed by a certificate authority (validating the SYH-MFA (key fob device) certificate)], and [Claim 10. The key fob device of claim 9, wherein the certificate authority is a vehicle manufacturer], and [¶5, Another solution to the above problem may be a method to pair a key fob and a control unit of a vehicle that includes reading, by a pairing device, a public encryption key (PKKF) and a certificate of authenticity (CertKF) from a key fob, verifying, by the pairing device, the CertKF using a public encryption key of a vehicle manufacturer (PKVM), transmitting, by the pairing device, a certificate of authenticity (CertVD) to a control unit, verifying, by the control unit, the CertVD using the PKVM], and[¶21, The certificate-based approach to pairing a key fob to a control unit may involve all actors (manufacturers, assemblers, dealerships, etc.) to obtain a public and secret (private) encryption key, which may be used to authenticate one another in the pairing process. That may mean that each vehicle dealership (or dealer/pairing device), the vehicle manufacturer, each key fob manufactured and assembled, and each control unit manufactured and installed in a vehicle to have their own associated public/secret key pairs. Once the components involved have acquired their key pairs, the public keys may be certified by a trusted third party or a certificate authority (CA). The CA may receive the public key and identification from the associated component to prove their identity. After their identity is proven, the CA may then sign the party's public key with the trusted third party's secret key. The signed public key becomes the certificate of authenticity for the requesting party. To verify the identity of a certificate, another party needs to unlock the certificate using the trusted third party's public key. The CA, for example, may be the vehicle manufacturer or a third party designated by the car manufacturer], and [¶¶24-25, Each key fob may have a public key (PK.sub.KF) and a secret key (SK.sub.KF) pair assigned to it and internally stored. The PK.sub.KF/SK.sub.KF pair may be generated for and installed in each key fob by the key fob manufacturer 102, the key fob assembly 104 or the vehicle manufacturer 110. The vehicle manufacturer 110 may choose the most trusted entity for the generation and installation of the PK.sub.KF/SK.sub.KF pairs to ensure secrecy and security. The same goes for each control unit that is manufactured and installed in a vehicle—each will have a key pair (PK.sub.CU/SK.sub.CU) generated and installed into an associated CU by a trusted party—the CU manufacturer 106, the CU assembly 108 or the vehicle manufacturer 110. In addition to the key fobs and CUs including their respective PK/SK pairs, each unit may also include a certificate of authenticity (Cert) that authenticates the component's identity. Conventionally, a Cert is a verified and signed public key where the Cert is signed by a CA. The CA may sign a Cert with its secret key. For security reasons, the vehicle manufacturer 110 may be the trusted third party so they can control the flow and validity of Certs in the manufacturing and key fob-auto pairing process. As such, the vehicle manufacturer 110 may sign all public keys with its secret key (SK.sub.VM) to generate a corresponding certificate. For example, a Cert.sub.KF will be inserted into an associated key fob. A Cert.sub.CU may correspond to a CU], and [¶34, The initial pairing process 300 may begin by the pairing device 302 receiving from the key fob 204 the PK.sub.KF and the Cert.sub.KF associated with the key fob, step 1a. The information may be sent to the pairing device 302 from the key fob 204 as a result of a request sent by the pairing device 302. Alternatively, the key fob 204 may be periodically broadcasting its PK.sub.KF and Cert.sub.KF. The pairing device 302 may then verify the identity of the key fob 204 by verifying the authenticity of the Cert.sub.KF, step 1b. The Cert.sub.KF may be verified by the pairing device using the stored PK.sub.VM. The verification of the Cert.sub.KF may be performed by hashing the Cert.sub.KF with the PK.sub.VM].
Examiner Note: Examiner maps the claimed limitation based on what is claimed. As indicate in the 112(b), the claim does not indicate what really rook key is, however, if it is considered that the rook key is the CA private key, then how come the authentication entity have access to this key. As indicated above the certificate of authenticity of the key fob device is signed by a certificate authority (validating the SYH-MFA (key fob device) certificate).
Per Response to Argument (5):
Examiner Note: Examiner maps the claimed limitation based on what is claimed not based on the application position such as mentioned above possession-token behavior, absence of holder signing, and etc. which are not even included in the claimed limitations. Examiner maintain his position that the combination of Peeters and Grim references read on each of the claimed limitations of independent claims.
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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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-2, 4-9, 11-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2017/0203720) issued to Peeters and in view of US Patent No. (US8578454) issued to Grim (filed in IDS 06/01/2021).
Regarding claims 1, 8, and 15, Peeters discloses wherein analyzing the SYH-MFA factor comprises: receiving, using a processor of an authenticating entity, an SYH certificate from a to-be-authenticated (TBA) entity, wherein the SYH certificate being presented unaltered by the to-be- authenticated entity and not signed by the to-be-authenticated entity [Abstract, A key fob device (equated to SYH authentication factor, to-be-authenticated (TBA) entity), in one embodiment, includes a transceiver that receives and sends signals, a memory that stores a public key and a certificate of authenticity associated with the key fob device( equated to the certificate unaltered and not signed), and a processor coupled to the transceiver and memory. The processor is configured to execute instructions causing the key fob device to transmit the public key and the certificate of authenticity, execute a public key agreement protocol to generate a common secret encryption key]; and
and determining, using the processor, that the SYH-MFA factor is satisfied by determining that the SYH certificate possessed by the TBA entity is valid by evaluating key data included in the SYH certificate, the key data comprising a public key of an authorized entity, including comparing the public key in the SYH certificate to a stored public key of the authorized entity [Abstract, A key fob device (equated to SYH authentication factor, to-be-authenticated (TBA) entity), in one embodiment, includes a transceiver that receives and sends signals, a memory that stores a public key and a certificate of authenticity associated with the key fob device( equated to the certificate unaltered and not signed), and a processor coupled to the transceiver and memory. The processor is configured to execute instructions causing the key fob device to transmit the public key and the certificate of authenticity, execute a public key agreement protocol to generate a common secret encryption key], and
[Claim 10. The key fob device of claim 9, wherein the certificate authority is a vehicle manufacturer], and [¶5, Another solution to the above problem may be a method to pair a key fob and a control unit of a vehicle that includes reading, by a pairing device, a public encryption key (PKKF) and a certificate of authenticity (CertKF) from a key fob, verifying, by the pairing device, the CertKF using a public encryption key of a vehicle manufacturer (PKVM), transmitting, by the pairing device, a certificate of authenticity (CertVD) to a control unit, verifying, by the control unit, the CertVD using the PKVM], and [ ¶25, In addition to the key fobs and CUs including their respective PK/SK pairs, each unit may also include a certificate of authenticity (Cert) that authenticates the component's identity. Conventionally, a Cert is a verified and signed public key where the Cert is signed by a CA. The CA may sign a Cert with its secret key. For security reasons, the vehicle manufacturer 110 may be the trusted third party so they can control the flow and validity of Certs in the manufacturing and key fob-auto pairing process. As such, the vehicle manufacturer 110 may sign all public keys with its secret key (SK.sub.VM) to generate a corresponding certificate. For example, a Cert.sub.KF will be inserted into an associated key fob. A Cert.sub.CU may correspond to a C].
Examiner Note: The public keys of all the devices are publicly available for all device and can be shared among all the devices for the purpose of identification , comparison and for other purposes.
and verifying that the SYH certificate has been digitally signed by a certificate authority using a certificate authority root key known to the authenticating entity
[Claim 9. The key fob device of claim 1, wherein the certificate of authenticity is signed by a certificate authority (validating the SYH-MFA (key fob device) certificate)], and [Claim 10. The key fob device of claim 9, wherein the certificate authority is a vehicle manufacturer], and [¶5, Another solution to the above problem may be a method to pair a key fob and a control unit of a vehicle that includes reading, by a pairing device, a public encryption key (PKKF) and a certificate of authenticity (CertKF) from a key fob, verifying, by the pairing device, the CertKF using a public encryption key of a vehicle manufacturer (PKVM), transmitting, by the pairing device, a certificate of authenticity (CertVD) to a control unit, verifying, by the control unit, the CertVD using the PKVM], and [¶¶24-25, Each key fob may have a public key (PK.sub.KF) and a secret key (SK.sub.KF) pair assigned to it and internally stored. The PK.sub.KF/SK.sub.KF pair may be generated for and installed in each key fob by the key fob manufacturer 102, the key fob assembly 104 or the vehicle manufacturer 110. The vehicle manufacturer 110 may choose the most trusted entity for the generation and installation of the PK.sub.KF/SK.sub.KF pairs to ensure secrecy and security. The same goes for each control unit that is manufactured and installed in a vehicle—each will have a key pair (PK.sub.CU/SK.sub.CU) generated and installed into an associated CU by a trusted party—the CU manufacturer 106, the CU assembly 108 or the vehicle manufacturer 110. In addition to the key fobs and CUs including their respective PK/SK pairs, each unit may also include a certificate of authenticity (Cert) that authenticates the component's identity. Conventionally, a Cert is a verified and signed public key where the Cert is signed by a CA. The CA may sign a Cert with its secret key. For security reasons, the vehicle manufacturer 110 may be the trusted third party so they can control the flow and validity of Certs in the manufacturing and key fob-auto pairing process. As such, the vehicle manufacturer 110 may sign all public keys with its secret key (SK.sub.VM) to generate a corresponding certificate. For example, a Cert.sub.KF will be inserted into an associated key fob. A Cert.sub.CU may correspond to a CU], and [¶34, The initial pairing process 300 may begin by the pairing device 302 receiving from the key fob 204 the PK.sub.KF and the Cert.sub.KF associated with the key fob, step 1a. The information may be sent to the pairing device 302 from the key fob 204 as a result of a request sent by the pairing device 302. Alternatively, the key fob 204 may be periodically broadcasting its PK.sub.KF and Cert.sub.KF. The pairing device 302 may then verify the identity of the key fob 204 by verifying the authenticity of the Cert.sub.KF, step 1b. The Cert.sub.KF may be verified by the pairing device using the stored PK.sub.VM. The verification of the Cert.sub.KF may be performed by hashing the Cert.sub.KF with the PK.sub.VM].
Peeters does not explicitly disclose, however, Grim discloses a computer-implemented method of executing multi-factor authentication (MFA), the computer-implemented method comprising [ Col. 1 lines 44-53, Recently, some two-factor authentication (TFA) mechanisms have been used; however, none of these known solutions are ideal. Many TFA mechanisms in current use center around the use of a security token. In this scheme, users are issued a token, often a small hardware device with a screen which displays a seemingly random number that changes periodically. Users that have paired a token with a network resource must supply the number currently on the screen at any given moment as part of the login procedure (in addition to a static password, the first authentication factor)].
analyzing one or more categories of MFA factors; wherein a first category of the one or more categories of MFA factors comprises a something-you-have MFA (SYH-MFA) factor [Col. 1 lines 44-61, Many TFA mechanisms in current use center around the use of a security token. In this scheme, users are issued a token, often a small hardware device with a screen which displays a seemingly random number that changes periodically. Users that have paired a token with a network resource must supply the number currently on the screen at any given moment as part of the login procedure (in addition to a static password, the first authentication factor). If the provided code matches an expected value at a token-aware backend for a given instance, then the system grants the authentication request -- feeling confident that a request that can provide a password (something known) and a valid code from the token screen (something possessed) is reasonably likely to be an authentic request. Security schemes using hardware tokens have been relatively successful as a two-factor authentication mechanism].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Peeters: a memory that stores a public key and a certificate of authenticity associated with the key fob device for a certificate-based authentication process, may involve the use of authenticated certificates and public/private key pairs associated with the various components and actors involved in the pairing process, by incorporating “Two-factor authentication (TFA)”, as taught by Grim. One could have been motivated to do so in order to use a issued a token (hardware token) to users, often a small hardware device with a screen which displays a seemingly random number that changes periodically. Users that have paired a token with a network resource must supply the number currently on the screen at any given moment as part of the login procedure (in addition to a static password, the first authentication factor), which, the security community has long sought a viable second factor to supplement and fortify passwords as a means for user authentication [ Grim, Col.1 lines 19-21; Col. 1 lines 48-53].
Regarding claims 2, 9, and 16, Peeters discloses wherein: the SYH certificate includes key data; and determining that SYH certificate possessed by the TBA entity is valid comprises determining that the key data of the SYH certificate comprises valid key data [¶30, The conditioning process 200 may also include the vehicle manufacturer 110 inserting its public key, PK.sub.VM, into each vehicle's CU(s) 202 and also into each key fob 204. The PK.sub.VM inserted into the key fob 204 and the CU 202 may be used at a later time to verify the authenticity/identity of another device since all certificates of authenticity should be signed by the vehicle manufacturer 110, which can be verified using the PK.sub.VM], and [Claim 9. The key fob device of claim 1, wherein the certificate of authenticity is signed by a certificate authority. Claim 10. The key fob device of claim 9, wherein the certificate authority is a vehicle manufacture].
Regarding claims 4, 11, and 18, Peeters discloses wherein the authenticating entity is selected from the group consisting of an embedded system, a coprocessor, and a hardware security module [¶41, server at the vehicle manufacturer 110]
Regarding claims 5, 12, and 19, Peeters discloses wherein: the key data of the SYH certificate comprises a public key; and the SYH certificate is generated using a certificate-authority cryptographic-officer (CA-CO) system configured to verify credentials of an authorized entity [¶21, The certificate-based approach to pairing a key fob to a control unit may involve all actors (manufacturers, assemblers, dealerships, etc.) to obtain a public and secret (private) encryption key, which may be used to authenticate one another in the pairing process. That may mean that each vehicle dealership (or dealer/pairing device), the vehicle manufacturer, each key fob manufactured and assembled and each control unit manufactured and installed in a vehicle to have their own associated public/secret key pairs. Once the components involved have acquired their key pairs, the public keys may be certified by a trusted third party or a certificate authority (CA). The CA may receive the public key and identification from the associated component to prove their identity. After their identity is proven, the CA may then sign the party's public key with the trusted third party's secret key. The signed public key becomes the certificate of authenticity for the requesting party. To verify the identity of a certificate, another party needs to unlock the certificate using the trusted third party's public key. The CA, for example, may be the vehicle manufacturer or a third party designated by the car manufacturer].
Regarding claims 6, and 13, Peeters discloses, wherein the authorized entity is authorized to make changes to resources of the authenticating entity [¶21, The certificate-based approach to pairing a key fob to a control unit may involve all actors (manufacturers, assemblers, dealerships, etc.) to obtain a public and secret (private) encryption key, which may be used to authenticate one another in the pairing process. That may mean that each vehicle dealership (or dealer/pairing device), the vehicle manufacturer, each key fob manufactured and assembled, and each control unit manufactured and installed in a vehicle to have their own associated public/secret key pairs. Once the components involved have acquired their key pairs, the public keys may be certified by a trusted third party or a certificate authority (CA). The CA may receive the public key and identification from the associated component to prove their identity. After their identity is proven, the CA may then sign the party's public key with the trusted third party's secret key. The signed public key becomes the certificate of authenticity for the requesting party. To verify the identity of a certificate, another party needs to unlock the certificate using the trusted third party's public key. The CA, for example, may be the vehicle manufacturer or a third party designated by the car manufacturer].
Regarding claims 7, 14, and 20, Peeters discloses wherein the authenticating entity determines that the public key of the SYH certificate is the public key of the authorized entity by: comparing the public key of the SYH certificate to the public key of the authorized entity; and determining that the public key of the SYH certificate has been digitally signed by the CA-CO system using the certificate authority root key that is known to the authenticating entity and associated with a CA-CO [¶21, The certificate-based approach to pairing a key fob to a control unit may involve all actors (manufacturers, assemblers, dealerships, etc.) to obtain a public and secret (private) encryption key, which may be used to authenticate one another in the pairing process. That may mean that each vehicle dealership (or dealer/pairing device), the vehicle manufacturer, each key fob manufactured and assembled, and each control unit manufactured and installed in a vehicle to have their own associated public/secret key pairs. Once the components involved have acquired their key pairs, the public keys may be certified by a trusted third party or a certificate authority (CA). The CA may receive the public key and identification from the associated component to prove their identity. After their identity is proven, the CA may then sign the party's public key with the trusted third party's secret key. The signed public key becomes the certificate of authenticity for the requesting party. To verify the identity of a certificate, another party needs to unlock the certificate using the trusted third party's public key. The CA, for example, may be the vehicle manufacturer or a third party designated by the car manufacturer], and [ Abstract, claim 10, ¶¶5, 24-25, 34].
Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2017/0203720) issued to Peeters and in view of US Patent No. (US8578454) issued to Grim (filed in IDS 06/01/2021) and in view of US Patent No. (US2009/0031131) issued to Qin.
Regarding claims 3, 10, and 17, Peeters does not explicitly disclose, however, Grim discloses wherein: a second category of the one or more categories of MFA factors comprises a something-you-know MFA (SYK-MFA) factor [Col. Lines 53-62, a first authentication factor (e.g., a password) is communicated from an authenticating terminal 202 to the authenticating service 204. The authenticating service 204 communicates with the authentication service 206 to verify a user action. This is done by sending a permission request to a mobile authentication device 208 associated with the user. The user uses the mobile device 208 to send a permission response to the authentication service 206 which is passed along to the authenticating service 204, providing the second factor of authentication
Peeters and Grim do not explicitly disclose, however, Qin discloses and analyzing the SYK-MFA factor comprises: receiving, using the processor, an SYK-MFA certificate from the TBA entity [¶30, Hardware tokens used as part of a multifactor authentication scheme within a PKI security system can provide significantly higher levels of authentication and trust, which is very much needed in an unsecure and untrusted factory/repair service environment. Possession or control of the hardware token can be required in addition to other authentication means, such as the entry of a user identification and/or password. The hardware token can provide strong evidence of the origin of a PKI request and prevent undue reliance on a user generated and user supplied secrets for security.], and [¶32, The hardware token may take many embodiments including an RJ45 jack that plugs into an Ethernet adaptor, smart cards, parallel port dongles, or a USB flash drives. The hardware tokens may incorporate a variety of techniques for more secure authentication. According to one exemplary embodiment, the hardware token contains the private key in a PKI system. The private key cannot be extracted from the hardware token. In another embodiment, tokens may use one-time passwords or time synchronized passwords that change constantly at a set time interval, e.g., once per minute], and [¶41, Information that identifies the operator, such as a username and password can be signed with the key/certificate of the hardware token (122) that is bound to the workstation (114)]; and
wherein the SYK-MFA certificate includes an SYK-MFA digital signature created by the TBA entity; and determining, using the processor, that the SYK-MFA factor is satisfied by determining that the SYK-MFA digital signature created by the TBA entity comprises a valid SYK digital signature [¶41, In addition, each hardware token (122) is exclusively bound to a particular workstation (114) or other machine. When the operator of a workstation (114) desires to obtain PKI data from the PKI server (110), a request is made through the two-way TLS connection to the PKI server (110). Information that identifies the operator, such as a username and password can be signed with the key/certificate of the hardware token (122) that is bound to the workstation (114). The PKI server (110) receives the information and verifies it], and [¶¶45-46, According to one exemplary embodiment, the service center workstations (206) are paired with hardware tokens (122) that enable the workstation (206) to communicate with a centralized PKI server (208) via a web services portal (200). The web services portal (200) may communicate with an LDAP server (202) to authenticate user names, passwords, or other data associated with each service center], andAfter the basic authentication is completed, the web service portal (200) initializes a two-way TLS communication with the centralized PKI server (208) and forwards the PKI data request message signed by a station's token (122) to the PKI server (208). The PKI server (208) first validates the Web Service Portal (200) TLS client request, and then validates the PKI data download request message generated by the station (206). The PKI server (208) then generates a response message with the requested PKI data included], and [¶78, FIG. 9 is a diagram illustrating one exemplary message and certificate validation between tokens (710, 740, 770) and the PKI servers (722, 752, 782) using the keys/CA certificates. The tokens (710, 740, 770) are paired with one or more matching PKI servers (722, 752, 782) during the personalization process. When token m (710) requests information from a PKI server (722), token m (710) sends a message (818) signed with token m's private key along with token m's certificate (822, FIG. 8). The PKI server (722) authenticates token m's certificate (822, FIG. 8) using the certificates of token m's sub-certificate authority and root certificate authority which are embedded inside the hardware security module (HSM) (724) within the PKI server (722) …].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Peeters, Grim with the teaching Qin in order to implement multifactor authentication scheme within a PKI security system which uses Hardware tokens as part of a multifactor authentication which can provide significantly higher levels of authentication and trust, which is very much needed in an unsecure and untrusted factory/repair service environment. Possession or control of the hardware token can be required in addition to other authentication means, such as the entry of a user identification and/or password. The hardware token can provide strong evidence of the origin of a PKI request and prevent undue reliance on a user generated and user supplied secrets for security [ Qin, ¶30].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ponsini ( (US107/0118196) [0052] In one or more embodiments, as a space-saving measure (e.g., since the hardware token may have limited memory resources), a hash (also known as a digest, or a cryptographic hash) of each public key may be stored in the list of public keys, instead of storing the public key itself. Since the hash maps data of any length into a fixed-length sequence, the hash may be significantly smaller than the public key. A hash of each public key may be computed, which may be compared to the hashes of public keys already stored in a list of public keys in the hardware token. If the hash is already stored in the hardware token, then it may be unnecessary to re-verify the public key corresponding to the hash.
Ben-Shalom (US2013/0339740) [MULTI-FACTOR CERTIFICATE AUTHORITY, disclosed herein is a certificate authority server configured to provide multi-factor digital certificates. A processor readable medium may include a plurality of instructions configured to enable a certificate authority server of a certificate authority, in response to execution of the instructions by a processor, to receive a request to provide a multi-factor digital security certificate by digitally signing a certificate request having a plurality of factors and a cryptographic key, wherein a first of the plurality of factors is an identifier of a device and a second of the plurality of factors is an identifier of a user of the device. The instructions are also configured to enable the certificate authority server to associate the cryptographic key with the plurality of factors and issue the digital security certificate based on the certificate request. Also disclosed is a method of using a multi-factor digital certificate as part of the authorization process to implicitly bind the plurality of factors].
Buer (US2007/0118745) [ Multi-factor Authentication Using a Smartcard].
Thirumalai (US2019/0394189) [ TWO-FACTOR DEVICE AUTHENTICATION].
Soriente (US2021/0167958) [ PASSWORD-AUTHENTICATED PUBLIC KEY ESTABLISHMENT].
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights