Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on September 17, 2025 has been entered.
Response to Arguments
Based on the applicant’s amendment to claims 1, 4, 13 and 15 the objection of claim 1, 4, 13 and 15 has been withdrawn.
Applicant’s arguments, see pages 1-3, filed on September 17, 2025, with respect to the rejection(s) of claim(s) 1-4 and 13-15 under under 35 U.S.C. 103 as being unpatentable over SHIN US 20200195447 A1 in view Tremlet et al. (US 20170005811 A1—hereinafter—"Tremlet”) have been fully considered and are persuasive. Furthermore, the rejection(s) of claims 5-12 under 35 U.S.C. 103 as being unpatentable over SHIN US 20200195447 A1 in view Tremlet et al. (US 20170005811 A1—hereinafter—"Tremlet”) in further view of Dewan US 20190305973 A1 been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of SHEN et al. (US 20190228164 A1—hereinafter—" SHEN”).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4 and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over SHIN US 20200195447 A1 view of SHEN et al. (US 20190228164 A1—hereinafter—" SHEN”) and in further view Tremlet et al. (US 20170005811 A1—hereinafter—"Tremlet”).
As per claim 1:
SHIN discloses a method for managing a Physically Unclonable Function (PUF) chip public key, a chip including at least one PUF type element and at least one hardcoded key, the method comprising:
a) receiving, by said chip, from an entity, a request for getting a signed PUF chip public key certificate ([0043] A PUF initialization may be performed. PUF_INIT_VALUE may be input from outside and transmitted to a KDF as a factor. In this example, the PUF_INIT_VALUE may be an external set value (or SEED value) for performing the KDF of the PUF chip 110. [0036] The PUF may be characterized in that a replication is not possible due to a characteristic of the randomly occurring semiconductor microstructure. Since the difference in microstructure is used as a key value, the key value may not be stored in a device and thus, protected from being hacked. Also, a non-repudiation function may be enhanced through a digital signature structure using the unique key value so as to be applied to a device authentication. [0037] Such PUF value may be expressed by n bytes and used to generate a new key value based on a key derivation function (KDF). [0038] Referring to FIG. 1, the client device 100 may include the PUF chip 110);
b) generating, by said chip, as a PUF chip private key, based on the request, a private key relating to the at least one PUF element, and ([0039] The PUF chip 110 may include at least one PUF value. The PUF key may be present in the PUF chip 110. By using the PUF key, a public key and a private key may be generated in a KDF);
determining, by said chip, as a PUF chip public key, a public key relating to the at least one PUF element ([0040] When using the PUF key, the public key may be extracted externally to the PUF chip 110, but the private key is not extracted. Thus, a signature value may be obtained using a signature function in the PUF chip 110. Through this, a leakage of the private key may be prevented, which may enhance a security. [0047] In other words, based on the PUF_INIT_VALUE and a PUF_KEY which is a unique key value in the PUF chip 110, a private key PUF_PRV_KEY and a public key PUF_PUB_KEY occurring based on the PUF value may be generated);
c) generating by said chip, as a PUF chip public key certificate, a certificate relating to the PUF chip public key ([0039] Also, in the PUF chip 110, at least one certificate may be stored in an internal memory storage. [0048] Also, the generated public key may be transmitted external to the PUF chip 110. In response to the PUF_PUB_KEY being transmitted to an outside, CERT or a certificate signing request (CSR) may be generated. Here, the CERT may indicate a certificate and the CSR may indicate a certificate signing request value);
d) signing by said chip the generated PUF chip public key certificate using the hardcoded key; and sending, from the chip to the entity, as a request response, the signed PUF chip public key certificate ([0049-0054]: PUF Signing Process: Since the PUF_PRV_KEY is present in the PUF chip 110 and not exposed to an outside, the corresponding function may be performed through signature value calculation. First, a message may be input from an outside. The message may be, for example, a hashed value or a non-hashed value. In addition, a signature value may be calculated using the PUF_PRV_KEY. SIGN(PUF_PRV_KEY, CSR_TBS) ==>PUF_SIGNATURE In other words, signing may be performed based on the PUF_PRV_KEY and the CSR_TBS, so that PUF_SIGNATURE is generated as a result. Here, the PUF_SIGNATURE may indicate a signature value calculated using the PUF_PRV_KEY and the CSR_TBS may indicate a signing target value (to be signed) of the CSR. Also, the calculated signature value may be transmitted to an outside of the PUF chip 110. Such signature may be used when creating a signature value to be input to the CSR during provisioning, or used when writing a signature value of “Client Certificate Verify” during HANDSHAKE. Provisioning in which a certificate is issued may be performed through CSR generation or through TBS content direct signing, and related description will be made with reference to the accompanying drawings).
SHIN does not explicitly disclose said hardcoded key read by said chip from at least one Registered Transfer Level RTL, type element. SHEN, in analogous art however, discloses said hardcoded key read by said chip from at least one Registered Transfer Level RTL, type element ([0013] An integrated circuit comprising, in hardware: a register-transfer level “RTL” key, wherein the RTL key is a pre-determined cryptographic key fabricated in the integrated circuit; and wherein the integrated circuit is configured to sign sensitive information using a signature based on the RTL key. [0015] The RTL key may be a predetermined cryptographic key unique to a hardware description language definition of the integrated circuit. The integrated circuit comprises an integrated universal integrated circuit card (iUICC) and wherein the integrated circuit is configured to export the signed public keys to enable secure provision of personalisation data to the iUICC. [0016] The RTL key may be an AES key. The hardware key generation value may have been generated from an entropy source. The entropy source may be at least one of a Physical Unclonable Function “PUF” or a True Random Number Generation “TRNG” seed. The public key may be signed by the RTL key using AES-CMAC. [0054] The integrated circuit is fabricated to include a number of different functions, and may be a system-on-chip (SoC). The SoC may contain a number of different functions, including one or more of radio circuitry, processing unit, and an iUICC. As mentioned previously, the integrated circuit may be fabricated according to a design implemented in a hardware description language. The hardware description language may include a predefined cryptographic key referred to herein as a register-transfer level key or RTL key. This RTL key is embedded in the hardware of the integrated circuit when it is fabricated. As such the RTL key is effectively hard-coded into the integrated circuit. The RTL key may be a cryptographic key such as an AES key. The RTL key value may be pre-defined only for a subset of integrated circuits that are manufactured. For example, the RTL key may differ between batches or may differ between designs. For example, a design revision or model change for an integrated circuit may trigger a change in the value of the key used as the RTL key). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of PUF chip disclosed by SHIN to include said hardcoded key read by said chip from at least one Registered Transfer Level RTL, type element. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to pride a mechanism for enhanced provision of sensitive, device-specific, such as a cryptographic key, from an integrated circuit in a secure manner as suggested by SHEN in ([004-0006]).
SHIN and SHEN do not explicitly disclose the generated certificate is as a PUF chip public key certificate. Tremlet, in analogous art however, discloses the generated certificate is as a PUF chip public key certificate ([0030] At step 214, a certificate that is associated with the public key is generated. In embodiments, once the authentication IC issues the public key, in order to ensure that the key is genuine and not issued by some unauthorized entity, the public key certificate is generated for Q, for example, by a certification authority during the manufacturing process (e.g., during production testing of the IC). The public key certificate may be a record that comprises data fields of a predetermined format. For example, one of the data fields may hold a value that is representative of the public key Q. [0031] In embodiments, generation of the public key certificate in step 214 comprises signing the certificate with a system private key. The system private key may be a number that is generated external to the IC during device manufacturing. In one embodiment, the system private key is a certification authority private key. [0032] Finally, at step 216, the signed public key certificate for Q may be stored in a non-volatile memory of the authentication IC. [0049] In embodiments, once the circuit 400 issues device public key 412, in order to ensure that key 412 is genuine and not issued by some unauthorized entity, processor 410 generates public key certificate 414 for public key 412. It is noted that processor 410 may be remotely located and operated by an external entity, such as a tester. In embodiments, processor 410 generates a certificate that is based on a result from PUF 402 and is stored in non-volatile memory 420. The public key certificate may be a record that comprises data fields of a predetermined format. For example, one of the data fields may hold a value that is representative of the public key. [0050] In embodiments, processor 410 externally signs the certificate with a system private key, e.g., a certification authority private key that is an externally generated number, for example, during a device manufacturing process, such as during production testing of circuit 400, thereby, preventing that the system private key is imported into the authentication device.) Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of PUF chip disclosed by SHIN and SHEN to include the generated certificate is as a PUF chip public key certificate. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to reliably authenticate asymmetric cryptography-based ICs based on Physically Unclonable Functions (PUFs) that are immune to reverse engineering and to enhance level of security in IC architectures without the need to connect to a remote certification authority, thereby, eliminating shortfalls associated with online authentication as suggested by Tremlet ([0026-0030]).
As per claim 2:
SHIN and SHEN in view of Tremlet discloses the method according to claim 1, wherein, said hardcoded key being a hardcoded private key, said method further comprises verifying, by said entity, the signature using a predetermined public key relating to said hardcoded private key, and extracting, if the signature is successfully verified, from said PUF chip public key certificate, said PUF chip public key (SHIN [0103] Previsioning through TBS content direct signing may generate a certificate by performing signing using a private key of the CA device 520 instead of generating a CSR unlike the above-described provisioning through CSR generation. Since the CA device 520 does not reveal the private key of the CA device 520, the signing may be performed in the CA device 520 in which the private key of the CA device 520 is securely stored).
As per claim 3:
SHIN and SHEN in view of Tremlet discloses the method according to any previous claim 1, wherein said signed PUF chip public key certificate is not stored in said chip (SHIN [0048] Also, the generated public key may be transmitted external to the PUF chip 110. In response to the PUF_PUB_KEY being transmitted to an outside, CERT or a certificate signing request (CSR) may be generated. Here, the CERT may indicate a certificate and the CSR may indicate a certificate signing request value).
As per claim 4:
SHIN and SHEN in view of Tremlet discloses the method according to claim 1, wherein to carry out the step e) of signing the PUF chip public key certificate based on said hardcoded key, said chip derives said PUF private key using an identifier relating to an application and said chip signs said PUF chip public key certificate using the derived PUF private key (SHIN [0037-0039] Such PUF value may be expressed by n bytes and used to generate a new key value based on a key derivation function (KDF). Referring to FIG. 1, the client device 100 may include the PUF chip 110. The PUF chip 110 may include at least one PUF value. The PUF key may be present in the PUF chip 110. By using the PUF key, a public key and a private key may be generated in a KDF. The private key may be designed not to be exposed to an outside of the PUF chip 110 and designed such that digital signing is performed in the PUF chip. Also, in the PUF chip 110, at least one certificate may be stored in an internal memory storage).
As per claim 13:
Claims 13 is directed a system for managing a Physically Unclonable Function, PUF, chip public key, the system comprising an entity and a chip, the chip including at least one PUF type element and at least one hardcoded key, the entity is configured to send, to the chip, a request for getting a signed PUF chip public key certificate; the chip is configured to perform features having substantially similar corresponding limitations of claim 1 and therefore claim 13 is rejected with the same given above to reject claim 1.
As per claim 14:
SHIN and SHEN in view of Tremlet discloses the system according to claim 13, wherein the entity includes a server ([0128] FIG. 8 illustrates a client device 100 and a server 810. The client device 100 and the server 810 may be devices transmitting and receiving data through TLS communication.)
As per claim 15:
Claims 13 is directed a chip for managing a Physically Unclonable Function, PUF, chip public key, the chip including at least one PUF type element and at least one hardcoded key, the chip is configured to perform features having substantially similar corresponding limitations of claim 1 and therefore claim 14 is rejected with the same given above to reject claim 1.
Claims 6-12 are rejected under 35 U.S.C. 103 as being unpatentable over SHIN US 20200195447 A1 view of SHEN et al. (US 20190228164 A1—hereinafter—" SHEN”) and in further view Tremlet et al. (US 20170005811 A1—hereinafter—"Tremlet”) in further view of Dewan US 20190305973 A1.
As per claim 6:
SHIN and SHEN in view of Tremlet do not explicitly disclose wherein said at least one RTL type element includes at least one element of a group including: at least one fuse; and at least one tie cell. Dewan, in analogous art however, discloses wherein said at least one RTL type element includes at least one element of a group including: at least one fuse; and at least one tie cell (Dewan [0022] The key pair may be stored in fuses of the device. The manufacturer the provides a certificate for the public-private key pair). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of PUF chip disclosed by SHIN and SHEN in view of Tremlet to include wherein said at least one RTL type element includes at least one element of a group including: at least one fuse; and at least one tie cell. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide asymmetric attestation with an enhanced feature that is physically unclonable function (PUF) configured that generates a response to a challenge as suggested by Dewan ([0012-0013]).
As per claim 7:
SHIN and SHEN in view of Tremlet in further view of Dewan discloses the method according to claim 1, wherein, to determine said PUF chip public key, said chip generates the PUF chip public key using said PUF chip private key and a cryptographic algorithm (Dewan [0023] The PRNG generates a set of random numbers and the first two prime numbers are used to generate Rivest, Shamir, and Adelman (RSA) keys (K.sub.pub and K.sub.priv). The key derivation block subsequently releases the K.sub.pub to the SoC and the software).
As per claim 8:
SHIN and SHEN in view of Tremlet in further view of Dewan discloses the method according to claim 7, wherein said cryptographic algorithm includes a Rivest-Shamir-Adleman, RSA, type algorithm (Dewan [0030] The key pair 216 may be according to the public key encryption algorithm developed by Rivest, Shamir, and Adelman (RSA). The RSA key pair includes two keys, one a public key and the other a private key).
As per claim 9:
SHIN and SHEN in view of Tremlet in further view of Dewan discloses the method according to claim 7, wherein said cryptographic algorithm includes a Elliptic Curve Cryptography, ECC, type algorithm (Tremlet [0029, 0045 and 0048] In embodiments, based on the inherent property of asymmetric cryptographic algorithms, such as an Elliptic Curve Digital Signature Algorithm (ECDSA), the generated number must be a non-zero integer to produce a valid public key.
As per claim 10:
SHIN and SHEN in view of Tremlet in further view of Dewan discloses the method according to claim 7, wherein said hardcoded key is specific to said chip (SHIN [0046] ==>PUF_PRV_KEY, PUF_PUB_KEY [0047] In other words, based on the PUF_INIT_VALUE and a PUF_KEY which is a unique key value in the PUF chip 110, a private key PUF_PRV_KEY and a public key PUF_PUB_KEY occurring based on the PUF value may be generated).
As per claim 11:
SHIN and SHEN in view of Tremlet in further view of Dewan discloses the method according to claim 7, wherein said hardcoded key is specific to a set of chips including said chip (Dewan [0048] In some examples, the processor 602 may be a system-on-chip (SoC) with a multi-core processor architecture. The processor 602 may provide a challenge to various attestation blocks 624 of embedded components within the device 600. In embodiments, the processor itself may be authenticated by an attestation block 624A. The attestation block 624A may be an attestation engine 104 as described in FIGS. 1-4B).
As per claim 12:
SHIN and SHEN in view of Tremlet in further view of Dewan discloses the method according to claim 7, wherein said entity stores said PUF chip public key certificate (SHIN [0109] Sixth, the certificate may be stored. For example, the certificate may be stored in the PUF chip 110. Depending on an example, the certificate may be stored external to the PUF chip 110).
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6: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, LINGLAN EDWARDS can be reached on (571) 270-5440. 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.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408