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 .
This Office Action is in response to the Amendment filed on 03/17/2026.
In the instant Amendment, claims 1, 8, and 11-14 have been amended; and claims 1 and 8 are independent claims. Claims 1-15 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Applicants’ arguments in the instant Amendment, filed on 03/17/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant’s arguments: “the combined references do not teach or suggest form[ing] a certificate chain comprising the challenge value and a unique identifier of the first electronic device, the unique identifier being usable for verifying another certificate chain to be generated by the first electronic device when stored by the second electronic device.” as recite in amended claims 1 and 8.”
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Jain discloses form a certificate chain comprising the challenge value and a unique identifier of the first electronic device, the unique identifier being usable for verifying another certificate chain to be generated by the first electronic device when stored by the second electronic device (Jain: par. 0054 FIG. 8 illustrates the sections that make up an exemplary device certificate challenge used in the process of device certificate individualization; par. 0061 the DEVICE_UNIQUEID section of the device certificate challenge is shown at 808. This section contains the unique device id; par. 0053 the server validates the incoming challenge and creates the unique device certificate "Unique Dev-cert" at block 705 based on the challenge [] at block 708 the device stores the device certificate that has been created; par. 0066 when server receives the challenge 901, the server, identified by the supplied URL 904, verifies the authenticity of the challenge by verifying the device challenge's digital signature 902). More specifically, Jain discloses the AUTHORIZATION_ROOT Certificate 501 is a section contained in the device certificate template. This section contains the certificate authority's root certificate information. The certificate authority's root certificate is typically the highest level of authorization, and is issued by the certificate authority. Other certificates that make up the chain of trust to allow content access may be based upon the authorization root certificate. In general, the root certificate contains an ID (Identifying whom are you certifying) and a public key which is being certified. This certificate is signed by certificate authority's private key. The private key is typically stored in a secure vault controlled by the certificate authority [par. 0046] and a chain of trust structure 1200 present in an embodiment of a device certificate template. In the chain of trust structure an authorization root certificate 1201 generates numerous Authorization certificates or DACs 1202, 1203, 1204 for individual OEMs. The DACS also may include a security level. Each horizontal level may be thought of as a link in the chain of trust as a path is traversed from top to bottom. Each link typically has a certificate associated with it to establish the validity of the link and couple it to the previous and following link. For example blocks 1201, 1202, 1205, and 1208 may be thought of as links going from the authorization root link 1201 to the device certificate 1208. A device certificate template is typically formed by incorporating each link in the chain of trust in a section of fields that form the template [par. 0081]. Therefore the examiner finds this argument not persuasive.
The amended claims 1 and 8 have been addressed in rejection below.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 06/28/2024 and 05/15/2026, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-6, 8 and 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over THOM et al. (“Thom,” US 2018/0375852) in view of Jain et al. (“Jain,” US 2012/0137127).
Regarding claim 1: Thom discloses a first electronic device comprising:
a wireless communication circuit configured to communicate with a second electronic device (Thom: fig. 8 item 830 transceiver);
a memory storing instructions (Thom: fig. 8 item 804 memory); and
a processor operatively connected to the wireless communication circuit and the memory (Thom: fig. 8 item 802 processor), and configured to execute the instructions,
wherein the instructions, when executed by the processor, cause the first electronic device to:
receive, through the wireless communication circuit, a certificate chain request that is transmitted from the second electronic device based on receiving a user input of a request regarding a security function through the first electronic device or the second electronic device (Thom: par. 0059 a transmitting operation 702 transmits a communication to the device. The communication includes a certificate request. A receiving operation 704 receives a compound certificate from the device. The compound certificate includes a representation of a state of the device; par. 0048 the certificate chain may lead the external device 404 to a trusted associate of the device manufacturer 402, which may be a certificate authority (CA) employed by the device manufacturer 402; par. 0028 investigates the code measurements (e.g., device state) to determine whether the operating system, firmware, application versions are trustable. If the versions are trustable, then the external device is permitted to communicate (e.g., through a SSL, TLS, or DTLS) connection with the device 104 or initiate other cryptographic communications).
Thom does not explicitly disclose wherein the certificate chain request comprises a challenge value, form a certificate chain comprising the challenge value and a unique identifier of the first electronic device, the unique identifier being usable for verifying another certificate chain to be generated by the first electronic device when stored by the second electronic device and transmit the certificate chain to the second electronic device through the wireless communication circuit to cause the second electronic device to verify validity of the certificate chain.
However, Jain discloses wherein the certificate chain request comprises a challenge value (Jain: par. 0051 FIG. 7 is a block diagram showing the process of device certificate individualization to create an exemplary device certificate. The process utilizes a challenge and response exchange between the device and the service provider),
form a certificate chain comprising the challenge value and a unique identifier of the first electronic device (Jain: par. 0054 FIG. 8 illustrates the sections that make up an exemplary device certificate challenge used in the process of device certificate individualization; par. 0061 the DEVICE_UNIQUEID section of the device certificate challenge is shown at 808. This section contains the unique device id), the unique identifier being usable for verifying another certificate chain to be generated by the first electronic device when stored by the second electronic device (Jain: par. 0053 the server validates the incoming challenge and creates the unique device certificate "Unique Dev-cert" at block 705 based on the challenge [] at block 708 the device stores the device certificate that has been created; par. 0066 when server receives the challenge 901, the server, identified by the supplied URL 904, verifies the authenticity of the challenge by verifying the device challenge's digital signature 902), and
transmit the certificate chain to the second electronic device through the wireless communication circuit to cause the second electronic device to verify validity of the certificate chain (Jain: par. 0053 at block 704 this unique information from the challenge is sent to a server [] the server validates the incoming challenge and creates the unique device certificate "Unique Dev-cert" at block 705 based on the challenge. A response including the device certificate that has been created is returned to the device ("Dev-cert response") at block 706. At block 707 the device validates the received response).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Jain with the system/method of Thom to include transmit the certificate chain to the second electronic device through the wireless communication circuit to cause the second electronic device to verify validity of the certificate chain. One would have been motivated to provide a method of creating a device certificate through an individualization process that the device certificate may be used for verifying access rights to consumer electronic devices through the use of device certificates (Jain: par. 0005).
Regarding claim 2: Thom in view Jain discloses the first electronic device of claim 1.
Thom further discloses wherein the memory comprises a first secure memory (Thom: par. 0022 a secure location within the device (e.g., a trusted platform module (TPM) 122)), and
wherein the first secure memory stores:
a second attestation key corresponding to a unique attestation key of the first electronic device (Thom: par. 0022 the manufacturer certificate 110 is associated with a private key 116 that may be stored in a secure location within the device (e.g., a trusted platform module (TPM) 122)), and
a second certificate corresponding to a pair certificate of the second attestation key (Thom: par. 0022 the private key 116 is used to sign any certificates that are chained to the manufacturer certificate 110 (e.g., the device certificate 112)).
Regarding claim 3: Thom in view Jain discloses the first electronic device of claim 2.
Thom further discloses wherein the second certificate is signed with a first attestation key corresponding to a root key based on manufacturing of the first electronic device (Thom: par. 0023 the device certificate 112 includes a root of trust to generate different keys for different operations. The root of trust may be signed by the manufacturer certificate 110), and
wherein the second certificate is stored in the first secure memory (Thom: par. 0056 a storing operation 602 stores a manufacturer certificate in a secure memory of the device).
Regarding claim 4: Thom in view Jain discloses the first electronic device of claim 3.
Thom further discloses form a third attestation key and a third certificate corresponding to a pair certificate of the third attestation key based on receiving the certificate chain request (Thom: par. 0015 attestation services or servers employed by or associated with the manufacturer may be utilized to determine whether a device is executing trusted software or firmware; par. 0022 the private key of the device manufacturer 102 is used to sign the manufacturer certificate 110, and the public key of the device manufacturer 102 is used to verify the manufacturer certificate 110).
Jain further discloses the challenge value and the unique identifier in the third certificate, and form the certificate chain by signing the third certificate with the second attestation key (Jain: par. 0061 the DEVICE_UNIQUEID section of the device certificate challenge is shown at 808. This section contains the unique device id; par. 0048 a GROUP Certificate Public key which is in tum a basis of verifying the DEVICE certificate section. The corresponding private key is hidden on the device. The device certificate section is signed using this private key).
The motivation is the same that of claim 1 above.
Regarding claim 5: Thom in view Jain discloses the first electronic device of claim 4.
Thom further discloses wherein the request regarding the security function comprises at least one of a request for activation of the security function, a request for deactivation of the security function, a request for connection with a host device, a request for disconnection from the host device, or a request for software initialization of the second electronic device (Thom: par. 0028 investigates the code measurements (e.g., device state) to determine whether the operating system, firmware, application versions are trustable. If the versions are trustable, then the external device is permitted to communicate (e.g., through a SSL, TLS, or DTLS) connection with the device 104).
Regarding claim 6: Thom in view Jain discloses the first electronic device of claim 4.
Jain further discloses wherein the certificate chain comprises a first certificate corresponding to a pair certificate of the first attestation key, a first public key of the first certificate, the second certificate, a second public key of the second certificate, and the third certificate (Jain: par. 0081 a chain of trust structure 1200 present in an embodiment of a device certificate template; par. 0047 the data section contains [] a Public key to sign Group certificate. This data section is signed using the certificate authority's private key. The corresponding Public key is in the Authorization Root Certificate).
The motivation is the same that of claim 1 above.
Regarding claim 8: Thom discloses a second electronic device comprising:
a wireless communication circuit configured to communicate with a first electronic device (Thom: fig. 8 item 830 transceiver);
a memory storing instructions (Thom: fig. 8 item 804 memory); and
a processor operatively connected to the wireless communication circuit and the memory (Thom: fig. 8 item 802 processor),
wherein the instructions, when executed by the processor, cause the second device to:
transmit, through the wireless communication circuit, a certificate chain request based on receiving a user input of a request regarding a security function through the first electronic device or the second electronic device (Thom: par. 0059 a transmitting operation 702 transmits a communication to the device. The communication includes a certificate request. A receiving operation 704 receives a compound certificate from the device. The compound certificate includes a representation of a state of the device; par. 0048 the certificate chain may lead the external device 404 to a trusted associate of the device manufacturer 402, which may be a certificate authority (CA) employed by the device manufacturer 402; par. 0028 investigates the code measurements (e.g., device state) to determine whether the operating system, firmware, application versions are trustable. If the versions are trustable, then the external device is permitted to communicate (e.g., through a SSL, TLS, or DTLS) connection with the device 104 or initiate other cryptographic communications),
verify validity of a certificate chain received from the first electronic device (Thom: par. 0059 a verifying operation 706 verifies the certificate chain. The verifying operation 706 may include verifying a device certificate and the manufacturer certificate),
activate the security function based on the validity of the certificate chain being verified (Thom: par. 0042 the external device 304 determines whether the generated compound certificate 324 should be trusted. If the generated compound certificate 324 is trustable, the external device 304 and the device 310 establish a secure communication channel using the TLS/SSL handshake process), and
receive a first certificate chain received from a host device (Thom: par. 0059 a verifying operation 706 verifies the certificate chain. The verifying operation 706 may include verifying a device certificate and the manufacturer certificate).
Thom does not explicitly disclose the certificate chain request comprising a challenge value, store the certificate chain and a unique identifier of the first electronic device included in the certificate chain in a second secure memory of the memory, and determine whether an electronic device identifier included in the first certificate chain and the unique identifier match to verify the validity of the first certificate chain.
However, Jain discloses the certificate chain request comprising a challenge value (Jain: par. 0051 FIG. 7 is a block diagram showing the process of device certificate individualization to create an exemplary device certificate. The process utilizes a challenge and response exchange between the device and the service provider), and
store the certificate chain and a unique identifier of the first electronic device included in the certificate chain in a second secure memory of the memory (Jain: par. 0053 the server validates the incoming challenge and creates the unique device certificate "Unique Dev-cert" at block 705 based on the challenge [] at block 708 the device stores the device certificate that has been created), and
determine whether an electronic device identifier included in the first certificate chain and the unique identifier match to verify the validity of the first certificate chain (Jain: par. 0053 the server validates the incoming challenge and creates the unique device certificate "Unique Dev-cert" at block 705 based on the challenge [] at block 708 the device stores the device certificate that has been created; par. 0066 when server receives the challenge 901, the server, identified by the supplied URL 904, verifies the authenticity of the challenge by verifying the device challenge's digital signature 902).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Jain with the system/method of Thom to include store the certificate chain and a unique identifier of the first electronic device included in the certificate chain in a second secure memory of the memory. One would have been motivated to provide a method of creating a device certificate through an individualization process that the device certificate may be used for verifying access rights to consumer electronic devices through the use of device certificates (Jain: par. 0005).
Regarding claim 12: Thom in view Jain discloses the second electronic device of claim 8.
Thom further discloses transmit the certificate chain request to the host device based on a user request for requiring security and the security function being activated (Thom: par. 0059 the communication includes a certificate request; par. 0048 the certificate chain may lead the external device 404 to a trusted associate of the device manufacturer 402, which may be a certificate authority (CA) employed by the device manufacturer 402; par. 0028 investigates the code measurements (e.g., device state) to determine whether the operating system, firmware, application versions are trustable. If the versions are trustable, then the external device is permitted to communicate (e.g., through a SSL, TLS, or DTLS) connection with the device 104 or initiate other cryptographic communications).
Regarding claim 13: Thom in view Jain discloses the second electronic device of claim 12.
Thom further discloses wherein the instructions, when executed by the processor, cause the second device to:
verify validity of a certificate included in the first certificate chain received from the host device with a public key included in the first certificate chain, to verify validity of the first certificate chain (Thom: par. 0059 a verifying operation 706 verifies the certificate chain. The verifying operation 706 may include verifying a device certificate and the manufacturer certificate).
The motivation is the same that of claim 1 above.
Regarding claim 14: Thom in view Jain discloses the second electronic device of claim 13.
Thom further discloses wherein the instructions, when executed by the processor, cause the second electronic device to:
determine that the first certificate chain is valid based on the electronic device identifier and the unique identifier matching (Thom: par. 0059 a verifying operation 706 verifies the certificate chain. The verifying operation 706 may include verifying a device certificate and the manufacturer certificate [] a determining operation 708 determines whether the certificate chain is verified (e.g., whether the state is a trusted state)); and
activate the security function based on the first certificate chain being valid (Thom: par. 0059 if the certificate chain is verified, then a caching operation 710 caches the valid certificate chain [] an establishing operation 712 establishes a secure communication channel with the device).
Regarding claim 15: Claim 15 is similar in scope to claim 5, and is therefore rejected under similar rationale.
Claims 7 and 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over THOM et al. (“Thom,” US 2018/0375852) in view of Jain et al. (“Jain,” US 2012/0137127) and Holtzman et al. (“Holtzman,” US 2008/0010450).
Regarding claim 7: Thom in view Jain discloses the first electronic device of claim 6.
Thom in view Jain does not explicitly disclose wherein the certificate chain is transmitted to the second electronic device to cause the second electronic device to verify validity of the second certificate based on the first public key and verify validity of the third certificate based on the second public key.
However, Holtzman discloses wherein the certificate chain is transmitted to the second electronic device to cause the second electronic device to verify validity of the second certificate based on the first public key and verify validity of the third certificate based on the second public key (Holtzman: par. 0263 the three certificate chains A1, B1 and C1 above illustrate three possible host certificate chains that may be used to prove that the public key of the host is genuine. In reference to the certificate chain A1 [] in FIG. 20, the public key in the host 1 CA (level 2) certificate 504 is signed (i.e. by encrypting a digest of the public key) by the private key of the host root CA, whose public key is in the Host root CA certificate 502. The host public key in the host certificate 506 is in turn signed by the private key of the host 1 CA (level 2), whose public key is provided in the host 1 CA (level 2) certificate 504).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Holtzman with the system/method of Thom and Jain to include the certificate chain is transmitted to the second electronic device to cause the second electronic device to verify validity of the second certificate based on the first public key. One would have been motivated to authenticate using credential tied to the access rights to gain access to protected content or area in system (Holtzman: par. 0071).
Regarding claim 9: Thom in view Jain discloses the second electronic device of claim 8.
Thome further discloses wherein the certificate chain comprises: a second certificate signed with a first attestation key corresponding to a root key based on manufacturing of the first electronic device (Thom: par. 0022 the private key of the device manufacturer 102 is used to sign the manufacturer certificate 110, and the public key of the device manufacturer 102 is used to verify the manufacturer certificate 110. This private key signature acts as a root of trust for the device manufacturer 102).
Thom in view of Jain does not explicitly disclose a first certificate that is a pair certificate of the first attestation key and a third certificate signed with a second attestation key that is a pair attestation key of the second certificate and corresponds to a unique attestation key of the first electronic device.
However, Holtzman discloses a first certificate that is a pair certificate of the first attestation key (Holtzman: par. 0302 the public-private key pair in the certificate); and
a third certificate signed with a second attestation key that is a pair attestation key of the second certificate and corresponds to a unique attestation key of the first electronic device (Holtzman: par. 0270 the SSA device may be manufactured by 1 through n different manufacturers, each with their own device CA certificate. Therefore, the public key in the device certificate for a particular device will be signed by the private key of its manufacturer, and the public key of the manufacture is in turn signed by the private key of the device root CA).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Holtzman with the system/method of Thom and Jain to include certificate signed with a second attestation key that is a pair attestation key of the second certificate and corresponds to a unique attestation key of the first electronic device. One would have been motivated to authenticate using credential tied to the access rights to gain access to protected content or area in system (Holtzman: par. 0071).
Regarding claim 10: Thom in view Jain and Holtzman discloses the second electronic device of claim 9.
Jain further discloses wherein the certificate chain comprises a first public key of the first certificate, and a second public key of the second certificate (Jain: par. 0043 in establishing a route of trust, that is reflected in the device certificate template, an OEM typically generates a public and private key pair; par. 0081 FIG.12 is an illustration of a chain of trust structure 1200 present in an embodiment of a device certificate template. In the chain of trust structure an authorization root certificate 1201 generates numerous Authorization certificates or DACs 1202, 1203, 1204 for individual OEMs), and wherein the third certificate comprises the challenge value and the unique identifier (Jain: par. 0054 FIG. 8 illustrates the sections that make up an exemplary device certificate challenge used in the process of device certificate individualization; par. 0061 the DEVICE_UNIQUEID section of the device certificate challenge is shown at 808. This section contains the unique device id).
The motivation is the same that of claim 8 above.
Regarding claim 11: Thom in view Jain and Holtzman discloses the second electronic device of claim 10.
Holtzman further discloses wherein the instructions, when executed by the processor, cause the second electronic device to:
verify validity of the second certificate with the first public key and verify validity of the third certificate with the second public key to verify the validity of the certificate chain (Holtzman: par. 0263 the three certificate chains A1, B1 and C1 above illustrate three possible host certificate chains that may be used to prove that the public key of the host is genuine. In reference to the certificate chain A1 [] in FIG. 20, the public key in the host 1 CA (level 2) certificate 504 is signed (i.e. by encrypting a digest of the public key) by the private key of the host root CA, whose public key is in the Host root CA certificate 502. The host public key in the host certificate 506 is in turn signed by the private key of the host 1 CA (level 2), whose public key is provided in the host 1 CA (level 2) certificate 504), or
determine whether the challenge value included in the third certificate and the challenge value included in the certificate chain request match to verify the validity of the certificate chain.
The motivation is the same that of claim 9 above.
Conclusion
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 Fahimeh Mohammadi whose telephone number is (571)270-7857. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
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, Luu Pham can be reached at 5712705002. 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.
/FAHIMEH MOHAMMADI/ Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights