DETAILED ACTION
This action is in response to the claims filed 12/3/2025. Claims 1-20 are pending. Claims 1-5, 16-17 and 20 have been amended.
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 .
Response to Amendment
In response to the amendment filed 12/3/2025: Applicant has amended the specification, and the corresponding objections have been withdrawn. Applicant has amended the claims, and the objections and corresponding 35 U.S.C. § 101 rejections have been withdrawn.
Applicant has amended the claims altering the scope of the invention in a manner that necessitated further search and consideration during which the previously indicated allowable subject matter was discovered to no longer be allowable, the corresponding rejections have been altered to address the amended language.
Response to Arguments
Applicant's arguments filed 12/3/2025 have been fully considered but they are not persuasive.
Applicant argues with regards to claims 1, 17 and 20:
“Independent claims 1, 17, and 20 and dependent claims 2-4, 6-16, and 18-19 are rejected as allegedly being obvious over Ylonen (entitled "The Secure Shell (SSH) Transport Layer Protocol") in combination with Chivukula (U.S. Patent Pub. No. 2021/0326459) and/or Mannengal (U.S. Patent. Pub. No. 2023/0370334). Independent claims 1, 17, and 20 are amended to include that the computing of the unique HMAC device is performed by the secure device and that the unique HMAC device is recomputed by the secure device after the secure device receives the signed HMAC from the trusted device. Such a distinction over the prior art references of record is important because these steps allow for increased security by not requiring storage of the unique HMAC by the secure device while also not allowing the computation of the unique HMAC to be performed by any device except for the secure device. During the Examiner Interview, Examiner Shepperd indicated that the amendments provided herein overcome the rejection under § 103 and place the claims in condition for allowance pending further searching. Thus, independent claims 1, 17, and 20 and dependent claims 2-16 and 18-19 are nonobvious and in condition for allowance.”
Examiner respectfully disagrees. Examiner has relied upon the new reference Griffin et al. (US 11,373,172 B1), in combination with Ylonen and Chivukula to show the amended language that has the initial computing, removal and recomputing of an HMAC by a single device (see below rejection). Griffin shows in Fig. 2 the initial computation of a “wallet password” which is an HMAC value calculate using an HMAC key. Fig. 2 further shows the wallet password’s subsequent usage and destruction at the same device. In Fig. 3 Griffin, shows where the same “wallet password” value is computed again at the same device followed by its usage and destruction/deletion. As such, the combination of Ylonen, Chivukula and Griffin teach the limitations of claims 1, 17 and 20.
All other arguments presented by Applicant either repeat or rely upon the issues addressed above, and are also not persuasive for the reasons given above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-13 and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ylonen, T. “RFC 4253 – The Secure Shell (SSH) Transport Layer Protocol”, published Jan. 31, 2006, provided in the IDS filed 7/2/2025, in view of Chivukula et al. (US 2021/0326459 A1), published Oct. 21, 2021, in view of Griffin et al. (US 11,373,172 B1), issued Jun. 28, 2022.
As to claims 1, 17 and 20 Ylonen discloses a method (Ylonen [Abstract]), a secure device (Ylonen §8¶2 client in client/server key exchange – requires processors and memory on both devices) and non-transitory computer readable storage medium (Ylonen §8¶2 client in client/server key exchange – requires processors and memory on both devices), hereinafter referred to as a method, for temporarily enabling functionality of a secure device (Ylonen [Abstract]) comprising: storing public keys for respective trusted devices of at least one trusted device (Ylonen §8¶2 “K_S is S’s public host key” S is server; §8 step 3 used at client – requires storing at client); storing device-unique data that is unique for the secure device (Ylonen §8¶2 “V_C is C’s identification string” C is client; §8 step 3 used at client – requires storing at client); generating a unique hashed-based message authentication code (HMAC) key (Ylonen §8 step 3 “C then computes K = f^x mod p” K is HMAC key; §6.4 HMAC key from key exchange); computing, by the secure device and based on the HMAC key and the device-unique data, a unique HMAC (Ylonen §8 step 3 “C then computes” … “H = hash (V_C || V_S || I_C || I_S || K_S || e || f || K)” H is hash using key K making is an HMAC code); S computes “H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K)” and “signature s on H with its private host key” – same signed HMAC code; §8 step 2 “S sends (K_S || f || s) to C” - S sends signature to C); decrypting the signed HMAC using the public key for the trusted device (Ylonen §8 step 3 “C then” … “and verifies the signature s on H” – requires decryption using S public_key as C cannot recreate signature as it does not have the private key of S); requires decryption using S public_key then comparison with H computed on C); and enabling functionality of the secure device based on a result of the comparison (Ylonen §10 after key exchange (having verification of the HMAC) client is able to request service from server). Ylonen fails to explicitly disclose transmitting the unique HMAC to a trusted device of the at least one trusted device; and recomputing, by the secure device, the unique HMAC based on the HMAC key and the device-unique data. Chivukula describes providing secure access to accessory device resources. With this in mind, Chivukula discloses transmitting the unique HMAC to a trusted device of the at least one trusted device (Chivukula Fig. 12 items 1216-1222; [0121]-[0123] host connects with dock, requests access, is sent a nonce value, signs nonce with host private key and returns the signed nonce to dock for verification, if verification passes the host is granted access to Use_Ports API, otherwise the host is denied; [0112] as part of verification, host is required to provide an identifier that is a HMAC code of the dock serial number). It would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to combine the HMAC verification/signing of Chivukula with the key exchange of Ylonen, such that the requesting party is sent a challenge with an HMAC of device identifying information for verification, as it would advantageously prevent exploitation of resources by a malicious user (Chivukula [0031]). Chivukula and Ylonen fail to explicitly disclose recomputing, by the secure device, the unique HMAC based on the HMAC key and the device-unique data. Griffin describes a method for generating and accessing a digital wallet locked with a wallet password. With this in mind, Griffin discloses recomputing, by a secure device, a unique HMAC based on a HMAC key and a device-unique data (Griffin Fig. 3 item 316; col. 12 ll. 20-67 hardware security module regenerates wallet password by generating an HMAC of an ID and HMAC key; Fig. 2 items 254 and 264 showing initial generation of HMAC/wallet password and its destruction). It would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to combine the HMAC regeneration of Griffin with the HMAC verification/signing of Chivukula and Ylonen, such that the HMAC is destroyed after use and regenerated based on need, as it would advantageously avoid security vulnerabilities associated with permanently storing the data (Griffin col. 10 l. 53 – col. 11 l. 9).
As to claim 2, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 1, including wherein the method further comprises: storing the unique HMAC after the unique HMAC is computed (Ylonen §8 step 3 – computation of H for comparison requires storage of H); and retrieving the unique HMAC before the unique HMAC is compared (Ylonen §8 step 3 – comparison requires accessing data).
As to claim 3, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 1, including wherein the HMAC key disappears for the secure device after being generated and used for computing the HMAC (Griffin Fig. 2 item 214 Destroy HK; Griffin col. 10 ll. 60-62 destroy HMAC key).
As to claim 4, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 1, including wherein the method further comprises: storing the HMAC key after the unique HMAC is generated (Ylonen §8 step 3 K used for computing H requires storage).
As to claim 5, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 1, including wherein the unique HMAC disappears for the secure device after being computed the first time and transmitted (Griffin Fig. 2 items 254 and 264 showing initial generation of HMAC/wallet password and its destruction after use; Chivukula [0112] as part of verification, host is required to provide an identifier that is a HMAC code of the dock serial number) and after being computed the second time and compared (Griffin Fig. 3 showing regeneration of wallet password and deletion of wallet password by cryptographic module; col. 12 ll. 20-67 hardware security module regenerates wallet password; Ylonen §8 step 3 “C then” … “and verifies the signature s on H” – requires decryption using S public_key then comparison with H computed on C).
As to claim 6 and 18, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claims 1 and 17, respectively, including wherein the functionality is enabled temporarily and expires based on an enablement condition (Ylonen §9¶3 keys changed after gig of transmitted data or hour of connection time (i.e. key must be re-exchanged)).
As to claim 7, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 6, including wherein the enablement condition is a function of a predetermined time period (Ylonen §9¶3 keys changed after hour of connection time (i.e. key must be re-exchanged)), receipt of a predetermined number of enablement requests to enable the functionality of the secure device (optional – not required), a predetermined number of power cycles of the secure device (optional – not required), a predetermined number of times the functionality is enabled or used (optional – not required), and/or a predetermined number of times of receiving the signed HMAC from the at least one trusted device (optional – not required).
As to claim 8, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 6, including wherein the enablement condition is configurable (Ylonen §9¶3 keys RECOMMENDED to be changed after hour of connection time (i.e. key must be re-exchanged) – recommended indicates this is configurable).
As to claim 9, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 1, including the method further comprising: deleting the HMAC key responsive to an HMAC key expiration condition (Ylonen §9¶3 keys changed after hour of connection time (i.e. key must be re-exchanged); §9¶2 “All keys and initialization vectors are recomputed after the exchange” – indicating the keys are replaced); and generating a new unique HMAC key (Ylonen §9¶3 keys changed after hour of connection time (i.e. key must be re-exchanged); §9¶2 “All keys and initialization vectors are recomputed after the exchange” – indicating the keys are replaced).
As to claim 10, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 9, including wherein the expiration condition is a function of a predetermined time period (Ylonen §9¶3 keys changed after hour of connection time (i.e. key must be re-exchanged)), receipt of a predetermined number of enablement requests to enable the functionality of the secure device (optional – not required), a predetermined number of power cycles of the secure device (optional – not required), a predetermined number of times the functionality is enabled or used (optional – not required), and/or a predetermined number of times of receiving the signed HMAC from the at least one trusted device (optional – not required).
As to claim 11, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 9, including wherein the expiration condition is configurable (Ylonen §9¶3 keys RECOMMENDED to be changed after hour of connection time (i.e. key must be re-exchanged) – recommended indicates this is configurable).
As to claim 12, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 1, including wherein before enabling the functionality, the secure device operates with a first level of functionality (Chivukula [0123] Use_Ports API call – for host to use dock), and after enabling the functionality, the secure device operates with a second level of functionality that is different from the first level of functionality (Chivukula [0097]&[0105] Modified Policies API call and Delete-_Policies API call; [0101] for host to modify & delete polices related to admin authority).
As to claim 13, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 1, including wherein the second level of functionality provides additional or fewer functions relative to the first level of functionality (Chivukula [0097]&[0105] Modified Policies API call and Delete-_Policies API call; [0101] for host to modify & delete polices related to admin authority), and only one of the first and second levels of functionality allows the secure device to perform one or more of diagnostics associated with the secure device (optional – not required), in-depth troubleshooting associated with the secure device (optional – not required), in-depth testing of the secure device (optional – not required), changing protected settings of the secure device (Chivukula [0097]&[0105] Modified Policies API call and Delete-_Policies API call; [0101] for host to modify & delete polices related to admin authority), recovering the secure device from a reduced state of functionality to a normal state of functionality (optional – not required), performing a firmware downgrade or upgrade (optional – not required), and restoring the secure device from a disabled state to an enabled state (optional – not required).
As to claim 16, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 1, including wherein the device-unique data is programmed or set in the secure device when the secure device is manufactured and is stored by the secure device in a trusted non-volatile location (Chivukula [0112] identifier obtained from dock HMAC of serial number and secret manufacturer key, stored in non-volatile memory and non-query able by external devices).
As to claim 19, Ylonen, Chivukula and Griffin disclose the invention as claimed as described in claim 17, including wherein the at least one processing device, upon execution of the plurality of programmable instructions, is further configured to: delete the HMAC key responsive to an HMAC key expiration condition (Ylonen §9 Key Re-Exchange “All keys and initialization vectors are recomputed after the exchange” – replacing K with new K; §9¶3 keys changed after gig of transmitted data or hour of connection time (i.e. key must be re-exchanged)); and generate a new unique HMAC key (Ylonen §9 Key Re-Exchange “All keys and initialization vectors are recomputed after the exchange” – replacing K with new K).
Claims 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Ylonen, T. “RFC 4253 – The Secure Shell (SSH) Transport Layer Protocol”, published Jan. 31, 2006, provided in the IDS filed 7/2/2025, in view of Chivukula et al. (US 2021/0326459 A1), published Oct. 21, 2021, in view of Mannengal et al. (US 2023/0370334 A1), published Nov. 16, 2023, in view of Griffin et al. (US 11,373,172 B1), issued Jun. 28, 2022.
As to claim 14, Ylonen, Chivukula and Griffin substantially disclose the invention as claimed as described in claim 1, failing, to explicitly disclose wherein the secure device is an industrial device that is configured to operate in an industrial environment. Mannengal describes networked device discovery and management. With this in mind, Mannengal discloses wherein the secure device is an industrial device that is configured to operate in an industrial environment (Mannengal [0301] used for industrial control). It would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to combine the networked device management of Mannengal with the functionality enabling system of Ylonen, Chivukula and Griffin, such that the secure device that is being enabled is an industrial device, or air-gapped device as in Mannengal, as it would advantageously allow for better management of devices (Mannengal [0002]).
As to claim 15, Ylonen, Chivukula and Griffin substantially disclose the invention as claimed as described in claim 1, failing, however, to explicitly disclose wherein the secure device is an air-gapped device. Mannengal discloses wherein the secure device is an air-gapped device (Mannengal [0301] intermittently air-gapped devices). It would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains to combine the networked device management of Mannengal with the functionality enabling system of Ylonen, Chivukula and Griffin, such that the secure device that is being enabled is an industrial device, or air-gapped device as in Mannengal, as it would advantageously allow for better management of devices (Mannengal [0002]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 ERIC W SHEPPERD whose telephone number is (571)270-5654. The examiner can normally be reached Monday - Thursday, Alt. Friday, 7:30AM - 5:00PM, 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, Rupal Dharia can be reached at (571)272-3880. 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.
/ERIC W SHEPPERD/Primary Examiner, Art Unit 2492
ERIC W. SHEPPERD
Primary Examiner
Art Unit 2492