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 .
Allowable Subject Matter
Claims 7-10, 17-18, and 20 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Terminal Disclaimer
The terminal disclaimer filed on 03/11/2026 disclaiming the terminal portion of any patent granted on this application which would extend beyond the expiration date of U.S. Patent No. 11294582 has been reviewed and is accepted. The terminal disclaimer has been recorded.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 11, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Henry et al. (U.S. Patent No. 6971005, hereinafter “Henry”) in view of Jauhiainen et al. (U.S. Patent Application Publication No. 2014/0359268, hereinafter “Jauhiainen”).
Claims 1 and 11:
Henry discloses a device, comprising:
a logic circuit configured to secure access to a function of the device based on validation of whether a requester for the function is in possession of a first cryptographic key (Column 12, Lines 13-16 and 19-24; After receiving the VSA information update request message, at 706 the VSA server searches for a VSA management record that matches the VSA username encompassed in the request message. If a management record is found at 708, the VSA server retrieves the hashed VSA password from the matched VSA management record, calculates the decryption key K1 from “hash(hashed VSA password||X)” and verifies the message authentication code “hash(Q||K1)”); and
a non-volatile storage configured to store the first cryptographic key and an authentication key (See citation above. The VSA server searches for a VSA management record that matches the VSA username encompassed in the request message. If a management record is found at 708, the VSA server retrieves the hashed VSA password from the matched VSA management record and calculates the decryption key K1 from “hash(hashed VSA password||X)”);
wherein the logic circuit is configured to, in response to a command having a message authentication code (Column 11, Line 65 – Column 12, Line 6; The VSA client constructs a VSA update request message Q by generating a random sequence X; calculating an encryption key K1 from “hash(hash(VSA password)||X)”; and using the formula “Q=VSA username||X||EK1 (Synchronization time||Request content)”. At 704, the VSA client sends the update request message Q and a message authentication code “hash (Q||K1)” to the VSA server to enable the VSA server to detect unauthorized modifications):
determine validity of the message authentication code based on the authentication key (Column 12, Lines 23-24; Verifies the message authentication code “hash(Q||K1)”);
generate a response code based at least in part on data provided via the command (Column 12, Lines 29-30 and 33-39; If the integrity of the message is verified, the VSA server, at 718, constructs a VSA information update response message A by generating a random sequence Y, calculating an encryption key K2 from “hash(hash(VSA password)||Y)”, and using the formula “A=Response Code||Y||EK2 (Synchronization time||Response content)”. The response code is either “Success” or “denial”); and
provide the response code as a response to the command (Column 12, Lines 38-41; The response code is either “success” or “denial” and is transmitted in clear text such that some access control point between the mobile host and the VSA server can make use of this information).
Henry does not appear to disclose:
generate, based at least in part on the response code, a second cryptographic key to replace the first cryptographic key;
provide the response code as a response to the command to enable separate generation of the second cryptographic key outside of the device.
Jauhiainen discloses a method of securely changing the root key of a chip comprising:
generating, based at least in part on the response code, a second cryptographic key to replace the first cryptographic key (§ 0057, Lines 17-20; Provision RKPUB2 on the memory space OTPROM2 and sets the RKPUB1_D. At this point, the root key is changed from RKPUB2 and the original root key RKPUB1 is disabled);
providing the response code as a response to the command to enable separate generation of the second cryptographic key outside of the device (§ 0057, Lines 1-5; Provisioning of RKPUB2 may in some embodiments be started automatically by the main firmware (SW3) but it can also be started by triggering it with a manufacturing tool such as for example using the USB port at interface 7 of Fig. 1) (§ 0057, Lines 12-16; The disable field RKPUB1_D is not set, meaning that RKPUB2 has not yet been provisioned (since in this example once RKPUB2 is provisioned then RKPUB1 will be disabled via this field)).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to extend Henry’s update request to Jauhiainen’s method, in order to securely program a new root key in a chip (Jauhiainen, § 0032, Lines 1-3).
The method of claim 11 is implemented by the device of claim 1 and is therefore rejected with the same rationale.
Claim 19:
Henry discloses a device, comprising:
a logic circuit configured to secure access to a function of the device based on validation of whether a requester for the function is in possession of a first cryptographic key (Column 12, Lines 13-16 and 19-24; After receiving the VSA information update request message, at 706 the VSA server searches for a VSA management record that matches the VSA username encompassed in the request message. If a management record is found at 708, the VSA server retrieves the hashed VSA password from the matched VSA management record, calculates the decryption key K1 from “hash(hashed VSA password||X)” and verifies the message authentication code “hash(Q||K1)”); and
a non-volatile storage configured to store the first cryptographic key (See citation above. The VSA server searches for a VSA management record that matches the VSA username encompassed in the request message. If a management record is found at 708, the VSA server retrieves the hashed VSA password from the matched VSA management record and calculates the decryption key K1 from “hash(hashed VSA password||X)”);
wherein the logic circuit is configured to, in response to a command (Column 11, Line 65 – Column 12, Line 6; The VSA client constructs a VSA update request message Q by generating a random sequence X; calculating an encryption key K1 from “hash(hash(VSA password)||X)”; and using the formula “Q=VSA username||X||EK1 (Synchronization time||Request content)”. At 704, the VSA client sends the update request message Q and a message authentication code “hash (Q||K1)” to the VSA server to enable the VSA server to detect unauthorized modifications):
generate a response code based at least in part on data provided via the command (Column 12, Lines 29-30 and 33-39; If the integrity of the message is verified, the VSA server, at 718, constructs a VSA information update response message A by generating a random sequence Y, calculating an encryption key K2 from “hash(hash(VSA password)||Y)”, and using the formula “A=Response Code||Y||EK2 (Synchronization time||Response content)”);
provide the response code and an identification of the device in a response to the command (Column 12, Lines 38-44; The response code is either “success” or “denial” and is transmitted in clear text such that some access control point between the mobile host and the VSA server can make use of this information. At 720, the response message A, which identifies the VSA server because it is constructed by the VSA server, and a message authentication code “hash(A||K2)” are communicated back to the VSA client/mobile host).
Henry does not appear to disclose:
generate, based at least in part on the response code and the first cryptographic key, a second cryptographic key to replace the first cryptographic key; and
provide the response code and an identification of the device in a response to the command to enable separate generation of the second cryptographic key outside of the device.
Jauhiainen discloses a method of securely changing the root key of a chip comprising:
generate, based at least in part on the response code and the first cryptographic key, a second cryptographic key to replace the first cryptographic key (§ 0057, Lines 17-20; Provision RKPUB2 on the memory space OTPROM2 and sets the RKPUB1_D. At this point, the root key is changed from RKPUB2 and the original root key RKPUB1 is disabled);
provide the response code in a response to the command to enable separate generation of the second cryptographic key outside of the device (§ 0057, Lines 1-5; Provisioning of RKPUB2 may in some embodiments be started automatically by the main firmware (SW3) but it can also be started by triggering it with a manufacturing tool such as for example using the USB port at interface 7 of Fig. 1) (§ 0057, Lines 12-16; The disable field RKPUB1_D is not set, meaning that RKPUB2 has not yet been provisioned (since in this example once RKPUB2 is provisioned then RKPUB1 will be disabled via this field)).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to extend Henry’s update request to Jauhiainen’s method, in order to securely program a new root key in a chip (Jauhiainen, § 0032, Lines 1-3).
Claim(s) 2-3 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Henry et al. (U.S. Patent No. 6971005, hereinafter “Henry”) in view of Jauhiainen et al. (U.S. Patent Application Publication No. 2014/0359268, hereinafter “Jauhiainen”); further in view of Wiseman et al. (U.S. Patent Application Publication No. 2004/0193888, hereinafter “Wiseman”).
Claim 2:
Henry in view of Jauhiainen discloses the device of claim 1, further comprising providing a random value for generation of the response code (Henry, Column 12, Lines 33-38; The VSA server constructs a VSA information update response message A by generating a random sequence Y, calculating an encryption key K2 from “hash(hash(VSA password)||Y)”, and using the formula “A=Response Code||Y||EK2 (Synchronization time||Response content)”).
Henry in view of Jauhiainen does not appear to disclose a monotonic counter configured to provide a random value for generation of the response code.
Wiseman discloses a nonce is a number (e.g., a number generated in a random number generator or monotonic counter) that avoids replay attacks (§ 0021, Lines 3-6).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Henry and Jauhiainen’s random sequence by using a monotonic counter to provide it, as taught by Wiseman, in order to assures that the signed value was produced in response to the current request, rather than produced at an earlier time (Wiseman, § 0021, Lines 6-8).
Claims 3 and 13:
Henry in view of Jauhiainen and further in view of Wiseman further discloses wherein the second cryptographic key is generated based at least in part on the first cryptographic key (Jauhiainen, §0032, Lines 1-4; Embodiments of these teachings enable a device manufacturer to securely program a new root key in a chip, after the chip manufacturer has conventionally programmed its own root key).
Claim 12:
Henry in view of Jauhiainen discloses the method of claim 11, further comprising providing a value for the generating of the response code (Henry, Column 12, Lines 33-38; The VSA server constructs a VSA information update response message A by generating a random sequence Y, calculating an encryption key K2 from “hash(hash(VSA password)||Y)”, and using the formula “A=Response Code||Y||EK2 (Synchronization time||Response content)”).
Henry in view of Jauhiainen does not appear to disclose a monotonic counter configured in the device to provide a value for the generating of the response code.
Wiseman discloses a nonce is a number (e.g., a number generated in a random number generator or monotonic counter) that avoids replay attacks (§ 0021, Lines 3-6).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Henry and Jauhiainen’s random sequence by using a monotonic counter to provide it, as taught by Wiseman, in order to assures that the signed value was produced in response to the current request, rather than produced at an earlier time (Wiseman, § 0021, Lines 6-8).
Claim(s) 4-6 and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Henry et al. (U.S. Patent No. 6971005, hereinafter “Henry”) in view of Jauhiainen et al. (U.S. Patent Application Publication No. 2014/0359268, hereinafter “Jauhiainen”); further in view of Wiseman et al. (U.S. Patent Application Publication No. 2004/0193888, hereinafter “Wiseman”); further in view of Smeets (U.S. Patent Application Publication No. 2014/0101311, hereinafter “Smeets”).
Claims 4 and 14:
Henry in view of Jauhiainen and further in view of Wiseman discloses the device as recited in claims 1-3 and the method as recited in claims 11-13.
Henry in view of Jauhiainen and further in view of Wiseman does not appear to disclose wherein the second cryptographic key is generated further based on an external nonce established via communications between the device and an external system that is configured to perform the separate generation of the second cryptographic key outside of the device.
Smeets discloses a cryptographic key is generated further based on an external nonce established via communications between the device and an external system that is configured to perform the separate generation of the second cryptographic key outside of the device (§ 0121, Lines 4-7; Instead of being generated by the external observer, the nonce N and/or the secret key Ks may be generated by the platform observer and communicated to the external observer).
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Henry, Jauhiainen, and Wiseman’s new root key by using an external nonce to generate it, as taught by Smeets, in order to promote interchangeability (Smeets, § 0121, Lines 2-3).
Claims 5 and 15:
Henry in view of Jauhiainen and further in view of Wiseman and Smeets further discloses wherein the response includes an unique identification that is associated with the first cryptographic key in the external system during manufacturing of the device (Jauhiainen, § 0032, Lines 3-6; The root key is typically provided to the chip manufacturer by the device manufacturer or other customer purchasing the chip) (Jauhiainen, § 0051, Lines 6-9; During chip manufacturing, SW1 is provisioned on the ROM 2c and the chip manufacturer’s root key RKPUB1 2d1 is provisioned on the OTPROM1 2d).
Claims 6 and 16:
Henry in view of Jauhiainen and further in view of Wiseman and Smeets further discloses wherein the second cryptographic key is generated further based on a customer identification (Jauhiainen, § 0032, Lines 1-3; Embodiments of these teachings enable a device manufacturer to securely program a new root key in a chip) associated with the authentication key (Jauhiainen, § 0059, Lines 3-5; These teachings can also be employed where the key pair is symmetric, that is, where the root key and the signing key are the same values).
Response to Arguments
Applicant’s arguments, see pages 6-7, filed 03/11/2026, with respect to the nonstatutory double patenting rejection have been fully considered and are persuasive. The nonstatutory double patenting rejection of claims 1, 2, 11, 12, 19, and 20 has been withdrawn.
Applicant's arguments filed 03/11/2026 have been fully considered but they are not persuasive. Applicant argues on pages 7-10 that (1) Henry’s response code is a status indicator, not a value used to generate a replacement cryptographic key based on the response code (and not provided to enable separate off-device generation of that replacement key) and is instead a non-cryptographic status value used in a network information update protocol and (2) Jauhiainen does not describe generating a replacement cryptographic key based at least in part on the response code nor does it describe providing a response code to enable separate generation of the second cryptographic key outside of the device. The examiner disagrees. Regarding (1) and (2), Henry’s response code is generated based at least in part on data provided via the command and is provided as a response to the command. Just because Henry’s response code is a status indicator does not mean it cannot be used to trigger generation of a cryptographic key. The response code merely triggering the generation of the cryptographic key would satisfy “based at least in part on the response code” (which the combination of Henry and Jauhiainen discloses). Jauhiainen’s method discloses generating a replacement key for an existing key is started automatically (a response code) or started by triggering it with an manufacturing tool (to enable separate generation outside the device). Henry’s update request has been modified or extended to include Jauhiainen’s key replacement method (which is an update) in order to securely program a new root key in a chip. It is important to note that the “provide” and “providing” steps in claims 1, 11, and 19 do not require that the second cryptographic key is generated outside of the device. The requirement is that the response code is provided as a response to the command, but the actual step of generating the second cryptographic key outside of the device is not claimed. Stated another way, the provided response code is capable of enabling the separate generation of the second cryptographic key outside of the device.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
U.S. Patent No. 9893885 (Miller et al.) – Derive a first cryptographic key using a first reduced set of information, detect a trigger event, and in response to the trigger event, derive a second cryptographic key using a second reduced set of information.
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 NAM T TRAN whose telephone number is (408)918-7553. The examiner can normally be reached Monday-Friday 7AM-3PM EST.
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, Emmanuel Moise can be reached at 571-272-3865. 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.
/NAM T TRAN/Primary Examiner, Art Unit 2455
Prosecution Insights