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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on February 20, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
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 12 and 16 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 12 recites the limitation "the certificate authority" in lines 17-18 and similarly, claim 16 recites the limitation "the certificate authority" in lines 17-18. There is insufficient antecedent basis for this limitation in the claim. For examination purposes, the limitations “the certificate authority” will be interpreted as “a certificate authority” that is similar to the other independent claims.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 2, and 4-17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Pochuev et al, U.S. Patent 11,777,926.
As per claim 1, it is taught of a communication system comprising a communication device (IoT device), a terminal device (Authentication policy server), and a certificate authority (Provisioning server acts as a Certificate Authority by issuing certificates, col. 23, lines 45-48), wherein
the communication device (IoT device) is configured to send, to the terminal device (Authentication policy server), a certificate signing request which requests issuance of a certificate used for the communication device to communicate with a server device (IoT device (i.e., communication device) is checked to determine whether access is to be granted to the IoT gateway which contains an IoT Application server (i.e., server device), col. 5, lines 2-4 & 32-36, and as shown in Figure 1; and the IoT device generates an authentication request to send to an authentication policy server (i.e., terminal device) to prove authentication, identity, and attestation with the IoT application service (i.e., hosted by the server device), wherein a signed certificate requesting certificate issuance is generated, col. 22, lines 6-10 & 21-23; col. 22, line 66 through col. 23, line 5; and as shown in Figure 8), and which includes device information on the communication device (IoT device), an attestation nonce, and an electronic signature generated using a private key for attestation as held in advance in the communication device for the device information and the attestation nonce (device information includes attestation data about the IoT device attributes and additionally includes a RoT ID that is an immutable root-of-trust ID, a nonce (i.e., attestation nonce), and an electronic signature generated using a private key that only the IoT device (i.e., communication device) has in advance, col. 15, lines 3-6 & 42-47; col. 22, lines 21-23 & 45-46: col. 23, line 66 through col. 24, line 5; and col. 23, lines 16-19),
the terminal device (Authentication policy server) is configured to send the certificate signing request sent from the communication device, to the certificate authority (the certificate signing request from the authentication policy server (i.e., terminal device) is then provided to the Provisioning server acting as a Certificate Authority by issuing certificates to an authenticated IoT device (i.e., communication device) request, col. 23, lines 7-9, 29-32, 36-38, & 45-48), verification of the electronic signature included in the certificate signing request is executed using a public key for attestation, which is paired with the private key for attestation (the signed certificate request is then verified by the authentication policy server by validation of the attestation data included in the certificate signing request, along with a public key system that is paired with an IoT device (i.e., communication device) private key, col. 22, line 66 through col. 23, line 9 and col. 23, lines 12-29), and
the certificate authority is configured to issue the certificate in response to the verification result (once the Provisioning server (i.e., Certificate Authority) verifies the identity of the requesting IoT device (i.e., communication device), a certificate is then issued, col. 23, lines 36-48).
As per claim 2, it is disclosed wherein the verification of the device information included in the certificate signing request sent from the terminal device (authentication policy server) is further executed by collating the device information included in the certificate signing request sent from the terminal device (authentication policy server) with an expected value of the device information associated with the public key for attestation (the signed certificate request is then verified by the authentication policy server by validation of the attestation data included in the certificate signing request, along with a public key system that is paired with an IoT device (i.e., communication device) private key by comparison of known previously collated values of the device information known by the RoT identity server, col. 22, line 66 through col. 23, line 9 and col. 23, lines 12-29).
As per claim 4, it is disclosed wherein the verification is executed by the certificate authority (once the Provisioning server (i.e., Certificate Authority) verifies the identity of the requesting IoT device (i.e., communication device), a certificate is then issued, col. 23, lines 36-48).
As per claim 5, it is taught wherein the certificate authority is configured to issue the attestation nonce in response to a request from the terminal device, and
the terminal device is configured to send to the communication device an initial setting start message including the attestation nonce issued by the certificate authority and instruct the communication device to generate the certificate signing request, when the communication device and the terminal device are connected communicably with each other (as the IoT device (communication device) initiates an initial request, then receives a nonce from a provisioning policy server that works with a provisioning server (i.e., certificate authority), then generates attestation data to generate a certificate signing request that is then sent to an authentication policy server (i.e., terminal device), col. 22, lines 6-23 & 44-45 and col. 22, line 66 through col. 23, line 5).
As per claim 6, it is disclosed of further comprising:
a verifying server device (RoT identity server) executing the verification, wherein the verifying server device is configured to send the verification result to the terminal device (the RoT identity server (i.e., verifying server device) executes the verification, then sends the verification result to the authentication policy server (i.e., terminal device), col. 23, lines 20-32), and
the terminal device (Authentication policy server) is configured to verify the verification result sent from the verifying server device and send the verification result to the certificate authority (once the authentication policy server (i.e., terminal device) receives verification results from the RoT identity server (i.e., verifying server), an identity token is then issued for the IoT device (i.e., communication device) to be used for issuing a certificate from the provisioning policy server (i.e., certificate authority), col. 23, lines 20-48).
As per claim 7, it is taught wherein the verifying server device is configured to issue the attestation nonce in response to a request from the terminal device, and
the terminal device is configured to send, to the communication device, an initial setting start message including the attestation nonce issued by the verifying server device and instruct the communication device to generate the certificate signing request, when the communication device and the terminal device are connected communicably with each other (as the IoT device (communication device) initiates an initial request, then receives a nonce from a provisioning policy server that works with a provisioning server (i.e., certificate authority), then generates attestation data to generate a certificate signing request that is then sent to an authentication policy server (i.e., terminal device), col. 22, lines 6-23 & 44-45 and col. 22, line 66 through col. 23, line 5).
As per claim 8, it is disclosed wherein the terminal device is configured to:
issue the attestation nonce generated from the attestation secret shared with the certificate authority (once the authentication policy server (i.e., terminal device) receives verification results from the RoT identity server (i.e., verifying server), an identity token containing the attestation is then issued for the IoT device (i.e., communication device) to be used for issuing a certificate from the provisioning policy server (i.e., certificate authority) based upon a pre-shared key (i.e., secret shared), col. 22, lines 17-20 and col. 23, lines 20-48); and
send, to the communication device, an initial setting start message including the issued attestation nonce and instruct the communication device to generate the certificate signing request, when the communication device and the terminal device are connected communicably with each other (as the IoT device (communication device) initiates an initial request, then receives a nonce from a provisioning policy server that works with a provisioning server (i.e., certificate authority), then generates attestation data to generate a certificate signing request that is then sent to an authentication policy server (i.e., terminal device), col. 22, lines 6-23 & 44-45 and col. 22, line 66 through col. 23, line 5).
As per claim 9, it is taught wherein the certificate authority is configured to execute verification of the attestation nonce included in the certificate signing request sent from the terminal device by collating the attestation nonce included in the certificate signing request sent from the terminal device with the attestation nonce generated from the attestation secret shared with the terminal device (the signed certificate request is then verified by the authentication policy server by validation of the attestation data and nonce included in the certificate signing request, along with a public key system that is paired with an IoT device (i.e., communication device) private key, col. 22, line 66 through col. 23, line 9 and col. 23, lines 12-29, wherein a pre-shared key (i.e., secret shared) is established, col. 22, lines 17-20).
As per claim 10, it is disclosed wherein the certificate authority is configured to, when a user using the terminal device sending the certificate signing request is an agent of initial settings of the communication device specified by an owner owing the communication device, execute verification as to whether the communication device specified by the device information included in the certificate signing request is a device owned by the owner and a device for which the agent is capable of issuing a certificate (IoT devices are manufactured as OEM (i.e., owner owning the IoT device) establishes the initial settings at fabrication, col. 12, lines 15-26 & 38-43 and the signed certificate request is then verified by the authentication policy server by validation of the attestation data included in the certificate signing request, along with a public key system that is paired with an IoT device (i.e., communication device) private key, col. 22, line 66 through col. 23, line 9 and col. 23, lines 12-29).
As per claim 11, it is taught of a terminal device (Authentication policy server) communicably connected with a communication device (IoT device) and a certificate authority (Provisioning server acts as a Certificate Authority by issuing certificates, col. 23, lines 45-48), the terminal device comprising a processor configured to:
receiving, from the communication device (IoT device), a certificate signing request requesting issuance of a certificate used for the communication device (IoT device) to communicate with a server device (IoT device (i.e., communication device) is checked to determine whether access is to be granted to the IoT gateway which contains an IoT Application server (i.e., server device), col. 5, lines 2-4 & 32-36, and as shown in Figure 1; and the IoT device generates an authentication request to send to an authentication policy server (i.e., terminal device) to prove authentication, identity, and attestation with the IoT application service (i.e., hosted by the server device), wherein a signed certificate requesting certificate issuance is generated, col. 22, lines 6-10 & 21-23; col. 22, line 66 through col. 23, line 5; and as shown in Figure 8); and
send the received certificate signing request to the certificate authority (the certificate signing request is provided to the Provisioning server acts as a Certificate Authority by issuing certificates to an authenticated IoT device (i.e., communication device), col. 23, lines 7-9, 29-32, 36-38, & 45-48), wherein
the certificate signing request includes device information on the communication device, an attestation nonce, and an electronic signature generated using a private key for attestation as held in advance in the communication device for the device information and the attestation nonce (device information includes attestation data about the IoT device attributes and additionally includes a RoT ID that is an immutable root-of-trust ID, a nonce (i.e., attestation nonce), and an electronic signature generated using a private key that only the IoT device (i.e., communication device) has in advance, col. 15, lines 3-6 & 42-47; col. 22, lines 21-23 & 45-46: col. 23, line 66 through col. 24, line 5; and col. 23, lines 16-19),
verification of the electronic signature included in the certificate signing request is executed using a public key for attestation, which is paired with the private key for attestation (the signed certificate request is then verified by the authentication policy server by validation of the attestation data included in the certificate signing request, along with a public key system that is paired with an IoT device (i.e., communication device) private key, col. 22, line 66 through col. 23, line 9 and col. 23, lines 12-29), and
the certificate is issued by the certificate authority in response to the verification result (once the Provisioning server (i.e., Certificate Authority) verifies the identity of the requesting IoT device (i.e., communication device), a certificate is then issued, col. 23, lines 36-48).
As per claim 12, it is disclosed of a communication device (IoT device) communicably connected with a terminal device (Authentication policy server), comprising a processor configured to:
send, to the terminal device, a certificate signing request which requests issuance of a certificate used for communication with a server device (IoT device (i.e., communication device) is checked to determine whether access is to be granted to the IoT gateway which contains an IoT Application server (i.e., server device), col. 5, lines 2-4 & 32-36, and as shown in Figure 1; and the IoT device generates an authentication request to send to an authentication policy server (i.e., terminal device) to prove authentication, identity, and attestation with the IoT application service (i.e., hosted by the server device), wherein a signed certificate requesting certificate issuance is generated, col. 22, lines 6-10 & 21-23; col. 22, line 66 through col. 23, line 5; and as shown in Figure 8), and which includes device information on the communication device (IoT device), an attestation nonce, and an electronic signature generated using a private key for attestation as held in advance in the communication device for the device information and the attestation nonce (device information includes attestation data about the IoT device attributes and additionally includes a RoT ID that is an immutable root-of-trust ID, a nonce (i.e., attestation nonce), and an electronic signature generated using a private key that only the IoT device (i.e., communication device) has in advance, col. 15, lines 3-6 & 42-47; col. 22, lines 21-23 & 45-46: col. 23, line 66 through col. 24, line 5; and col. 23, lines 16-19), wherein
verification of the electronic signature included in the certificate signing request is executed using a public key for attestation, which is paired with the private key for attestation (the signed certificate request is then verified by the authentication policy server by validation of the attestation data included in the certificate signing request, along with a public key system that is paired with an IoT device (i.e., communication device) private key, col. 22, line 66 through col. 23, line 9 and col. 23, lines 12-29), and
the certificate is issued by the certificate authority (Provisioning server acts as a Certificate Authority by issuing certificates, col. 23, lines 45-48) in response to the verification result (once the Provisioning server (i.e., Certificate Authority) verifies the identity of the requesting IoT device (i.e., communication device), a certificate is then issued, col. 23, lines 36-48).
As per claim 13, it is taught of a certificate authority (Provisioning server acts as a Certificate Authority by issuing certificates, col. 23, lines 45-48) communicably connected with a terminal device (Authentication policy server), comprising a processor configured to:
receiving, from the terminal device (Authentication policy server), a certificate signing request which requests issuance of a certificate used for communication with a server device (IoT device (i.e., communication device) is checked to determine whether access is to be granted to the IoT gateway which contains an IoT Application server (i.e., server device), col. 5, lines 2-4 & 32-36, and as shown in Figure 1; and the IoT device generates an authentication request to send to an authentication policy server (i.e., terminal device) to prove authentication, identity, and attestation with the IoT application service (i.e., hosted by the server device), wherein a signed certificate requesting certificate issuance is generated, col. 22, lines 6-10 & 21-23; col. 22, line 66 through col. 23, line 5; and as shown in Figure 8), and which includes device information on the communication device (IoT device), an attestation nonce, and an electronic signature generated using a private key for attestation as held in advance in the communication device (IoT device) for the device information and the attestation nonce (device information includes attestation data about the IoT device attributes and additionally includes a RoT ID that is an immutable root-of-trust ID, a nonce (i.e., attestation nonce), and an electronic signature generated using a private key that only the IoT device (i.e., communication device) has in advance, col. 15, lines 3-6 & 42-47; col. 22, lines 21-23 & 45-46: col. 23, line 66 through col. 24, line 5; and col. 23, lines 16-19);
execute verification of the electronic signature included in the received certificate signing request, using a public key for attestation, which is paired with the private key for attestation (the signed certificate request is then verified by the authentication policy server by validation of the attestation data included in the certificate signing request, along with a public key system that is paired with an IoT device (i.e., communication device) private key, col. 22, line 66 through col. 23, line 9 and col. 23, lines 12-29); and
issue the certificate in response to the verification result (once the Provisioning server (i.e., Certificate Authority) verifies the identity of the requesting IoT device (i.e., communication device), a certificate is then issued, col. 23, lines 36-48).
As per claim 14, it is disclosed of a method executed by a communication system comprising a communication device (IoT device), a terminal device (Authentication policy server), and a certificate authority, the method comprising:
sending, to the terminal device (Authentication policy server), a certificate signing request which requests issuance of a certificate used for the communication device (IoT device) to communicate with a server device (IoT device (i.e., communication device) is checked to determine whether access is to be granted to the IoT gateway which contains an IoT Application server (i.e., server device), col. 5, lines 2-4 & 32-36, and as shown in Figure 1; and the IoT device generates an authentication request to send to an authentication policy server (i.e., terminal device) to prove authentication, identity, and attestation with the IoT application service (i.e., hosted by the server device), wherein a signed certificate requesting certificate issuance is generated, col. 22, lines 6-10 & 21-23; col. 22, line 66 through col. 23, line 5; and as shown in Figure 8), and which includes device information on the communication device, an attestation nonce, and an electronic signature generated using a private key for attestation as held in advance in the communication device (IoT device) for the device information and the attestation nonce (device information includes attestation data about the IoT device attributes and additionally includes a RoT ID that is an immutable root-of-trust ID, a nonce (i.e., attestation nonce), and an electronic signature generated using a private key that only the IoT device (i.e., communication device) has in advance, col. 15, lines 3-6 & 42-47; col. 22, lines 21-23 & 45-46: col. 23, line 66 through col. 24, line 5; and col. 23, lines 16-19);
sending the certificate signing request sent from the communication device, from the communication device to the certificate authority (the certificate signing request is provided to the Provisioning server acting as a Certificate Authority by issuing certificates to an authenticated IoT device (i.e., communication device) request, col. 23, lines 7-9, 29-32, 36-38, & 45-48);
executing verification of the electronic signature included in the certificate signing request, using a public key for attestation, which is paired with the private key for attestation (the signed certificate request is then verified by the authentication policy server by validation of the attestation data included in the certificate signing request, along with a public key system that is paired with an IoT device (i.e., communication device) private key, col. 22, line 66 through col. 23, line 9 and col. 23, lines 12-29); and
issuing, at the certificate authority, the certificate in response to the verification result (once the Provisioning server (i.e., Certificate Authority) verifies the identity of the requesting IoT device (i.e., communication device), a certificate is then issued, col. 23, lines 36-48).
As per claim 15, it is taught of a method executed by a terminal device (Authentication policy server) communicably connected with a communication device (IoT device) and a certificate authority (Provisioning server acts as a Certificate Authority by issuing certificates, col. 23, lines 45-48), the method comprising:
receiving, from the communication device (IoT device), a certificate signing request requesting issuance of a certificate used for the communication device (IoT device) to communicate with a server device (IoT device (i.e., communication device) is checked to determine whether access is to be granted to the IoT gateway which contains an IoT Application server (i.e., server device), col. 5, lines 2-4 & 32-36, and as shown in Figure 1; and the IoT device generates an authentication request to send to an authentication policy server (i.e., terminal device) to prove authentication, identity, and attestation with the IoT application service (i.e., hosted by the server device), wherein a signed certificate requesting certificate issuance is generated, col. 22, lines 6-10 & 21-23; col. 22, line 66 through col. 23, line 5; and as shown in Figure 8); and
sending the received certificate signing request to the certificate authority (the certificate signing request is provided to the Provisioning server acting as a Certificate Authority by issuing certificates to an authenticated IoT device (i.e., communication device) request, col. 23, lines 7-9, 29-32, 36-38, & 45-48), wherein the certificate signing request includes device information on the communication device, an attestation nonce, and an electronic signature generated using a private key for attestation as held in advance in the communication device for the device information and the attestation nonce (device information includes attestation data about the IoT device attributes and additionally includes a RoT ID that is an immutable root-of-trust ID, a nonce (i.e., attestation nonce), and an electronic signature generated using a private key that only the IoT device (i.e., communication device) has in advance, col. 15, lines 3-6 & 42-47; col. 22, lines 21-23 & 45-46: col. 23, line 66 through col. 24, line 5; and col. 23, lines 16-19),
verification of the electronic signature included in the certificate signing request is executed using a public key for attestation, which is paired with the private key for attestation (the signed certificate request is then verified by the authentication policy server by validation of the attestation data included in the certificate signing request, along with a public key system that is paired with an IoT device (i.e., communication device) private key, col. 22, line 66 through col. 23, line 9 and col. 23, lines 12-29), and
the certificate is issued by the certificate authority in response to the verification result (once the Provisioning server (i.e., Certificate Authority) verifies the identity of the requesting IoT device (i.e., communication device), a certificate is then issued, col. 23, lines 36-48).
As per claim 16, it is disclosed of a method executed by a communication device communicably connected with a terminal device (Authentication policy server), the method comprising:
sending, to the terminal device (Authentication policy server), a certificate signing request which requests issuance of a certificate used for communication with a server device (IoT device (i.e., communication device) is checked to determine whether access is to be granted to the IoT gateway which contains an IoT Application server (i.e., server device), col. 5, lines 2-4 & 32-36, and as shown in Figure 1; and the IoT device generates an authentication request to send to an authentication policy server (i.e., terminal device) to prove authentication, identity, and attestation with the IoT application service (i.e., hosted by the server device), wherein a signed certificate requesting certificate issuance is generated, col. 22, lines 6-10 & 21-23; col. 22, line 66 through col. 23, line 5; and as shown in Figure 8), and which includes device information on the communication device (IoT device), an attestation nonce, and an electronic signature generated using a private key for attestation as held in advance in the communication device for the device information and the attestation nonce (device information includes attestation data about the IoT device attributes and additionally includes a RoT ID that is an immutable root-of-trust ID, a nonce (i.e., attestation nonce), and an electronic signature generated using a private key that only the IoT device (i.e., communication device) has in advance, col. 15, lines 3-6 & 42-47; col. 22, lines 21-23 & 45-46: col. 23, line 66 through col. 24, line 5; and col. 23, lines 16-19), wherein
verification of the electronic signature included in the certificate signing request is executed using a public key for attestation, which is paired with the private key for attestation (the signed certificate request is then verified by the authentication policy server by validation of the attestation data included in the certificate signing request, along with a public key system that is paired with an IoT device (i.e., communication device) private key, col. 22, line 66 through col. 23, line 9 and col. 23, lines 12-29), and
the certificate is issued by the certificate authority (Provisioning server acts as a Certificate Authority by issuing certificates, col. 23, lines 45-48) in response to the verification result (once the Provisioning server (i.e., Certificate Authority) verifies the identity of the requesting IoT device (i.e., communication device), a certificate is then issued, col. 23, lines 36-48).
As per claim 17, it is taught of a method executed by a certificate authority (Provisioning server acts as a Certificate Authority by issuing certificates, col. 23, lines 45-48) communicably connected with a terminal device (Authentication policy server), the method comprising:
receiving, from the terminal device (Authentication policy server), a certificate signing request which requests issuance of a certificate used for communication with a server device (IoT device (i.e., communication device) is checked to determine whether access is to be granted to the IoT gateway which contains an IoT Application server (i.e., server device), col. 5, lines 2-4 & 32-36, and as shown in Figure 1; and the IoT device generates an authentication request to send to an authentication policy server (i.e., terminal device) to prove authentication, identity, and attestation with the IoT application service (i.e., hosted by the server device), wherein a signed certificate requesting certificate issuance is generated, col. 22, lines 6-10 & 21-23; col. 22, line 66 through col. 23, line 5; and as shown in Figure 8), and which includes device information on the communication device (IoT device), an attestation nonce, and an electronic signature generated using a private key for attestation as held in advance in the communication device (IoT device) for the device information and the attestation nonce (device information includes attestation data about the IoT device attributes and additionally includes a RoT ID that is an immutable root-of-trust ID, a nonce (i.e., attestation nonce), and an electronic signature generated using a private key that only the IoT device (i.e., communication device) has in advance, col. 15, lines 3-6 & 42-47; col. 22, lines 21-23 & 45-46: col. 23, line 66 through col. 24, line 5; and col. 23, lines 16-19);
executing verification of the electronic signature included in the certificate signing request, using a public key for attestation, which is paired with the private key for attestation (the signed certificate request is then verified by the authentication policy server by validation of the attestation data included in the certificate signing request, along with a public key system that is paired with an IoT device (i.e., communication device) private key, col. 22, line 66 through col. 23, line 9 and col. 23, lines 12-29); and
issuing the certificate in response to the verification result (once the Provisioning server (i.e., Certificate Authority) verifies the identity of the requesting IoT device (i.e., communication device), a certificate is then issued, col. 23, lines 36-48).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Pochuev et al, U.S. Patent 11,777,926 in view
As per claim 3, it is taught by Pochuev wherein verifying whether the attestation nonce included in the certificate signing request sent from the terminal device (the signed certificate request is then verified by the authentication policy server (i.e., terminal device) by validation of the attestation data and nonce included in the certificate signing request, along with a public key system that is paired with an IoT device (i.e., communication device) private key, col. 22, line 66 through col. 23, line 9 and col. 23, lines 12-29), Pochuev fails to disclose of validation of the attestation nonce is within a validity period.
Li et al, U.S. Patent 12,200,496 discloses validation of the attestation nonce is within a validity period (a wireless device (i.e., communication device) requests an attestation certificate from a device certificate server (i.e., terminal device) within a certain time period, wherein the request includes a randomly generated value (i.e., nonce), col. 9, lines 61-66).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to have been motivated to applying expiration conditions to ensure secure processing conditions take place. Li et al discloses whereby the random time period and update window ensure loading on the device certificate server is kept below a threshold loading level, col. 10, lines 46-49. Although the teachings of Pochuev et al fail to disclose of the validation of attestation nonces within a validity period, Li et al offers as means of reducing the load on a certificate server by preset threshold values.
Conclusion
The relevant art made of record and not relied upon is considered pertinent to applicant's disclosure.
Allen et al, U.S. Patent 11,424,939 is relied upon for disclosing of a TPM also includes an attestation identity key certificate. Alternatively, another computing device, such as the attestation endpoint, may hold the attestation identity key certificate on behalf of the TPM. The certificate provides proof that the attestation identity key is a signing key restricted to the TPM and usable to verify the integrity of the host. In some implementations, the attestation identity key certificate is issued by a trusted certification authority (CA) and includes a certificate chain to establish a chain of trust. In general, CAs may represent entities, processes, and tools that create digital certificates that securely bind the names of entities to public keys. A CA's signature on a certificate allows any tampering with the contents of the certificate to be easily detected. As long as the CA's signature on a certificate can be verified, the certificate has integrity. In some implementations, the attestation identity key certificate identifies the TPM, the host associated with the TPM, includes a public portion of the attestation identity key (e.g., a public attestation identity key), such as a certified public key, owned by the TPM, provides a validity duration of the certificate, and includes a summary of operations for which the public portion of the attestation identity key is to be used, see column 3, lines 18-39.
Sinha et al, U.S. Patent 10,819,696 is relied upon for disclosing of a computing device can use the relying party system by providing proof to the relying party system that the trusted secure component has been issued an attestation certificate by the attestation service. Given the attestation certificate and the public/private key pair selected for the computing device, this proof can be provided to the relying party system in a variety of different manners. For example, the relying party system can provide a nonce to the trusted secure component and the trusted secure component digitally signs the nonce using the private key of the public/private key pair received from the attestation service, see column 6, lines 38-49.
Beekman et al, US 2022/0247576 is relied upon for disclosing of a second node attestation manager located on the second node may send a remote attestation request to a first node attestation manager on the first node. The remote attestation request may be sent, for example, in response to a request from the first node to join a cluster of which the second node is a member, in which case the application data in the first node application enclave may include information identifying the first node. Each node can generate its own public/private key pair. The hash of the node's public key can be used as or included in the node's application data, and included in the local attestation and remote attestation. A remote attestation request received by the first node can include a nonce value. When a remote attestation request (with a nonce) is received by the first node, the first node can (a) sign the nonce signed with the first node's private key, and (b) return the offline attestation certificate to the second node (e.g., as part of sending the remote attestation to the second node). The second node can (c) verify that the nonce value it sent to the first node has been signed by the private key of the first node using the public key the second node retrieves from the offline attestation certificate and (b) verify that the offline attestation certificate can be trusted. This verification thus verifies the identity of the first node, see paragraph 0059.
Robison et al, US 2021/0266184 is relied upon for disclosing of a signing system extracts information from log files and combines a system ID and component identifier(s) into an initial Platform Attribute (PA) certificate. After assembling and signing the initial PA certificate, the signing system may store an initial PA certificate and the certificate signing keys used to sign the initial PA certificate, see paragraph 0058.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER REVAK whose telephone number is (571)272-3794. The examiner can normally be reached 5:30am - 3:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Catherine Thiaw can be reached at 571-270-1138. 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.
/CHRISTOPHER A REVAK/Primary Examiner, Art Unit 2407
Prosecution Insights