DETAILED ACTION
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 30 December 2025 has been entered.
Response to Arguments
Applicant’s arguments ("REMARKS") filed 30 December 2025 have been fully considered, and they are partially persuasive as to the previous grounds of rejection.
Claims 1, 6, 11, and 16 were amended. Claims 1, 6, 11, and 16 are independent. Claims 1-20 are pending.
Re: Claim Rejections Under 35 U.S.C. §103
Applicant’s amendment and arguments, indicated on pp.8-12 of the REMARKS, in response to the rejection of the claims under 35 U.S.C. §103 with respect to Rubin et al., US 2017/0222802 A1 (hereinafter, “Rubin ‘802”) and Stapleton, US 12,034,836 B1 (hereinafter, “Stapleton ‘836”) have been fully considered, and they are partially persuasive as to the previous grounds of rejection. In particular, with respect to the independent claims, Applicant argues that:
Rubin ‘802 and Stapleton ‘836 do not disclose hardware security systems (HSMs) with different application programming interfaces (APIs)
Rubin ‘802’s HSMs are interoperable within a fleet
Stapleton ‘836 creates new keys rather than migrating existing keys
No motivation to combine Rubin ‘802 and Stapleton ‘836
The claimed invention addresses a specific problem not taught by the prior art
In response to Argument A
Applicant argues that Rubin ‘802 and Stapleton ‘836 do not disclose or suggest hardware security systems having different APIs that are configured to perform tasks using the original key, as recited in the amended independent claims. Specifically, Applicant contends that neither reference teaches “… wherein the first hardware security system has a first application programming interface (API) and the second hardware security system has a second application programming interface (API) different from the first API...wherein the first API and second API are configured to perform tasks using the original key ...”, as amended in the independent claims.
This argument is persuasive. The previously cited combination of Rubin ‘802 and Stapleton ‘836 does not explicitly teach HSMs having different APIs configured to perform tasks using the original key. Stapleton ‘836 was previously relied upon to teach HSMs from different vendors or service providers, but did not explicitly teach the “API” terminology now recited in the amended claims. Accordingly, Stapleton ‘836 is no longer relied upon in the current rejection. Applicant’s arguments and amendments have necessitated new ground(s) of rejection presented in this Office Action. A new ground of rejection has been asserted over Anand et al., US 2022/0393857 A1 (hereinafter, “Anand ‘857”) and Camus et al., US 2006/0050885 A1 (hereinafter, “Camus ‘885”).
Anand ‘857 teaches that different vendor HSMs have different ‘vendor-specific HSM languages’ (i.e., interfaces) (Anand ‘857, ¶¶3-4, 40). Camus ‘885, on the other hand, explicitly teaches that interfaces for accessing cryptographic hardware implemented as ‘APIs’ (e.g., PKCS#11 and CAPI), and that these APIs are configured to perform cryptographic tasks using keys, including generation and storage of keys, electronic signature, and encryption and decryption of data (Camus ‘885, ¶¶21-23).
The combination of Rubin ‘802 in view of Anand ‘857 and Camus ‘885 addresses all limitations of the amended claims, as set forth in detail in Claim Rejections – 35 USC §103 below.
In response to Argument B
Applicant argues that Rubin ‘802 discloses HSMs as part of a fleet that share a common fleet key and communicate using shared protocols. Applicant asserts that Rubin ‘802’s architecture requires HSMs within the fleet to be interoperable, and that Rubin ‘802 is silent on HSMs having different APIs configured to perform tasks using the original key.
This argument is partially persuasive. Rubin ‘802, as cited in the prior Office Action, does not explicitly teach HSMs having different APIs. Rubin ‘802 focuses on HSMs operating within a fleet that share common keys and protocols, but does not explicitly address the scenario where HSMs have different APIs.
Rubin ‘802, however, discloses the key migration mechanism recited in the claims. Specifically, Rubin ‘802’s wrap/unwrap process using asymmetric encryption (Rubin ‘802, ¶¶65-68) teaches a secure method for migrating cryptographic keys from a first HSM to a second HSM without exposing the key in cleartext. Rubin ‘802 at ¶68 discloses that ‘… [t]he fleet key is provided from the first HSM to the second HSM in a protected format so that the fleet key is not revealed outside the context of the HSMs ...’. This wrap/unwrap mechanism uses public-key cryptography and is not inherently limited to HSMs with identical interfaces.
To address the amended claim limitations regarding HSMs with different APIs, newly cited references Anand ‘857 and Camus ‘885 are relied upon. Anand ‘857 explicitly teaches that different vendor HSMs have different ‘vendor-specific HSM languages’ and that enterprises commonly use HSMs from multiple vendors (Anand ‘857, ¶40): ‘… HSM middlewares include a database of HSM vendor HSM products and languages associated with each product ... By recognizing vendor-specific HSM language and translating the client service request to the appropriate HSM language, client service requests for HSM services may be HSM vendor agnostic, enabling a client instance to request from any number of HSMs ...’. Camus ‘885, on the other hand, discloses that these interfaces for accessing cryptographic hardware are explicitly implemented as ‘APIs’ (Camus ‘885, ¶¶22-23).
The motivation to combine and detailed claim mappings are set forth in Claim Rejections – 35 USC §103 below.
In response to Argument C
Applicant argues that Stapleton ‘836’s solution to the interoperability problem is to derive new shared keys using a key derivation function, not to migrate existing keys between HSMs.
This argument is persuasive. Additionally, with Applicant’s amendment removing the “different vendor” language from the independent claims and adding explicit “API” terminology, Stapleton ‘836 is no longer relied upon in the current rejection. The current rejection relies on Rubin ‘802 in view of Anand ‘857 and Camus ‘885. See Claim Rejections – 35 USC §103 below for further details.
In response to Argument D
Applicant argues that one of ordinary skill in the art would not have been motivated to combine Rubin ‘802 with Stapleton ‘836. Applicant contends that Rubin ‘802’s HSMs are already interoperable and do not face interoperability problems, while Stapleton ‘836 solves interoperability by creating new keys rather than migrating existing ones.
This argument is now moot. As discussed above, Stapleton ‘836 is no longer relied upon in the current rejection. The current rejection relies on Rubin ‘802 in view of Anand ‘857 and Camus ‘885.
The motivation to combine Rubin ‘802, Anand ‘857, and Camus ‘885 is set forth in Claim Rejections – 35 USC §103 below and is based on the recognition that enterprises commonly use HSMs from multiple vendors with different interfaces (Anand ‘857, ¶40) (Camus ‘885, ¶¶22-23), and that Rubin ‘802’s wrap/unwrap mechanism provides a secure method for transferring keys between HSMs that does not depend on the HSMs having identical interfaces. Combining these teachings would enable secure key migration across heterogeneous HSM environments, providing flexibility and avoiding vendor lock-in (Anand ‘857, ¶40).
In response to Argument E
Applicant argues that the claimed invention addresses a specific problem not taught by the prior art. Applicant asserts that the specification explicitly recognizes that different HSM vendors have different APIs, which causes a challenge to migrating security hardware keys between different HSMs, and that the present technology ensures that the original key is migrated securely between HSMs with different APIs without exposing it in an unprotected format.
This argument is partially persuasive. The previously cited combination of Rubin ‘802 and Stapleton ‘836 did not explicitly address the problem of migrating keys between HSMs with different “APIs” as now recited in the amended claims. Rubin ‘802, however, teaches a secure method for migrating keys between HSMs using a wrap/unwrap mechanism (Rubin ‘802, ¶¶65-68) that does not expose the key in cleartext. This mechanism addresses the solution aspect of securely migrating keys between HSMs.
Anand ‘857, on the other hand, explicitly recognizes that different vendor HSMs have different ‘vendor-specific HSM languages’ and that a system must translate requests to the appropriate language for each HSM (Anand ‘857, ¶40). Anand ‘857’s system is designed to handle ‘… any number of HSMs …’ from different vendors, demonstrating that the problem of HSMs having different interfaces was known in the art.
Similarly, Camus ‘885 explicitly recognizes that different cryptographic hardware suppliers offer different APIs (Camus ‘885, ¶¶22-23): ‘… The majority of cryptographic hardware suppliers offer a PKCS#11 module for accessing their products …The major suppliers of cryptographic hardware usually offer a CSP for accessing their product …’. This demonstrates that it was well known in the art that cryptographic hardware from different suppliers uses different APIs (e.g., PKCS#11 vs. CAPI).
Thus, the combination of Rubin ‘802, Anand ‘857, and Camus ‘885 teaches all elements of the amended claims. See Claim Rejections – 35 USC §103 below for further details.
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 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Rubin et al., US 2017/0222802 A1 (hereinafter, “Rubin ‘802”), in view of Anand et al., US 2022/0393857 A1 (hereinafter, “Anand ‘857”), and further in view of Camus et al., US 2006/0050885 A1 (hereinafter, “Camus ‘885”).
As per claim 1: Rubin ‘802 discloses:
A method for migrating a key (a method for distributing cryptographic information, where the cryptographic information may be a key [Rubin ‘802, ¶¶Abstract, 44, 47]), the method implemented by one or more network traffic management apparatuses, server devices, or client devices (the method implemented by a hardware security module (HSM) hub 102 and servers over a network 110 [Rubin ‘802, ¶¶25, 32, 107-108; Fig.1, Fig.18]), the method comprising:
receiving an encrypted symmetric key from a first hardware security system (receiving an encrypted fleet key 812 from a first HSM 802 (HSM1), where the fleet key 812 may be a symmetric key [Rubin ‘802, ¶¶33, 65-68; Figs.8-9]), wherein the encrypted symmetric key was generated by encrypting, using a public key generated from a second hardware system (the encrypted fleet key 812 was encrypted by the first HSM1 802 using a public key 818 generated by the second HSM 804 (HSM2), where the public key 818 of HSM2 804 is transmitted to HSM1 802 prior to encryption of the fleet key 812; for example, the fleet key may be transmitted from a source HSM to the destination HSM by generating a public-private key pair on the destination HSM, providing the public key to the source HSM, and encrypting the fleet key on the source HSM using the public key, and then sending the encrypted fleet key from the source HSM to the destination HSM [Rubin ‘802, ¶¶45, 65-68; Fig.9]), a symmetric key generated by the first hardware security system (the fleet key is generated by the first HSM; the fleet key 218 is generated by an HSM within the fleet and distributed to the remaining fleet members by encrypting the fleet key with an asymmetric cryptographic key generated by each of the remaining fleet members [Rubin ‘802, ¶¶27, 38, 45]), wherein the generated public key is transmitted to the first hardware security system prior to the encryption (public key 818 generated by the second HSM 804 (HSM2), where the public key 818 of HSM2 804 is transmitted to HSM1 802 prior to encryption of the fleet key 812 [Rubin ‘802,¶¶45, 66, 68; Fig.9]),
sending the received encrypted symmetric key to the second hardware security system (the HSM hub 102 transmitting the received encrypted fleet key 812 to HSM2 804 [Rubin ‘802, ¶¶25, 45, 66-68; Figs.8-9]);
receiving an encrypted original key from the first hardware security system after sending the encrypted symmetric key to the second hardware security system (receiving encrypted cryptographic information from HSM1 802 after transmitting the encrypted fleet key 812 to HSM2 804, where the cryptographic information may be a key, and where the key may be an application key, shared secret key, or a domain key [Rubin ‘802, ¶¶25, 27, 33, 65-66; Fig.1, Figs.8-9]), wherein an original key was encrypted using the symmetric key; sending the received encrypted original key to the second hardware security system (the cryptographic information was encrypted using the fleet key 812 and transmitted to HSM2 804 [Rubin ‘802, ¶¶Abstract, 25, 33, 51, 65-66; Fig.1, Fig.8]); and
completing a migration of the original key from the first hardware security system (completing the distribution of the cryptographic information from HSM1 802 to HSM2 804 when HSM2 804 decrypts the encrypted cryptographic information using the transmitted encrypted fleet key 812 [Rubin ‘802, ¶¶Abstract, 25, 33, 37, 66, 68; Fig.1, Fig.8]),
As stated above, Rubin ‘802 does not explicitly disclose the limitation: “… wherein the first hardware security system has a first application programming interface (API) and the second hardware security system has a second application programming interface (API) different from the first API … completing a migration of the original key from the first hardware security system with the first API to the second hardware security system with the second API … wherein the first API and second API are configured to perform tasks using the original key.”
Anand ‘857, however, discloses:
... wherein the first hardware security system has a first and the second hardware security system has a second different from the first (a unified HSM and key management service, where HSM middlewares include a database of HSM vendor HSM products and languages associated with each product, and where the HSM middleware determines a vendor-specific HSM language associated with the requested HSM and translates the client service request to the appropriate HSM language, thereby enabling client service requests for HSM services to be HSM vendor agnostic, enabling a client instance to request from any number of HSMs [Anand ‘857, ¶¶Abstract, 3, 40; Fig.3]) ...
... completing a migration of the original key from the first hardware security system with the first to the second hardware security system with the second (the first HSM having a first vendor-specific HSM language and the second HSM having a second vendor-specific HSM language different from the first, where different vendor HSMs have different vendor-specific HSM languages [Anand ‘857, ¶¶40, 42]) ...
... wherein the first (an encryption operation at an HSM may be to utilize a customer root key (CRK) stored at the HSM to encrypt one or more service keys, where an encryption operation may include encryption, decryption, wrapping, unwrapping, signing [Anand ‘857, ¶42]) ...
Rubin ‘802 and Anand ‘857 are analogous art because they are from the same field of endeavor, namely that of managing cryptographic keys using hardware security modules. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Rubin ‘802 and Anand ‘857 before them, to modify the method in Rubin ‘802 to include the teachings of Anand ‘857, namely to modify the communicating HSMs within the HSM fleet of Rubin ‘802, such that the first HSM has a first vendor-specific HSM language and the second HSM has a second vendor-specific HSM language different from the first, as disclosed in Anand ‘857, where the vendor-specific HSM languages are configured to perform cryptographic tasks using keys. A motivation for doing so would be to enable HSM vendor-agnostic requests such that both vendor and location lock-in are avoided, enabling clients to use an HSM provided by any vendor (see Anand ‘857, ¶40).
As stated above, Rubin ‘802 in view of Anand ‘857 does not explicitly disclose the limitation: “... wherein the first hardware security system has a first application programming interface (API) and the second hardware security system has a second application programming interface (API) different from the first API ... with the first API ... with the second API ... wherein the first API and second API ...”.
Camus ‘885, however, discloses:
... wherein the first hardware security system has a first application programming interface (API) and the second hardware security system has a second application programming interface (API) different from the first API ... with the first API ... with the second API ... wherein the first API and second API (PKCS#11 is a public standard that describes an application programming interface (API) allowing low level cryptographic operations such as the generation and storage of keys, the electronic signature, the encryption and decryption of data, where the majority of cryptographic hardware suppliers offer a PKCS#11 module for accessing their products; CAPI (“Crypto API”) is an API developed by Microsoft Corporation, where the major suppliers of cryptographic hardware usually offer a CSP for accessing their product [Camus ‘885, ¶¶21-23]) ...
Rubin ‘802 (modified by Anand ‘857) and Camus ‘885 are analogous art because they are from the same field of endeavor, namely that of managing cryptographic operations using hardware security modules. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Rubin ‘802 (modified by Anand ‘857) and Camus ‘885 before them, to modify the method in Rubin ‘802 (modified by Anand ‘857) to include the teachings of Camus ‘885, namely to clarify that the vendor-specific HSM languages of Anand ‘857 are application programming interfaces (APIs), such as PKCS#11 and CAPI, as disclosed in Camus ‘885, where these APIs are configured to perform cryptographic tasks including the generation and storage of keys, electronic signature, and encryption and decryption of data. A motivation for doing so would be to provide a level of abstraction relative to the cryptographic hardware, enabling applications to access cryptographic resources through standardized interfaces offered by cryptographic hardware suppliers (see Camus ‘885, ¶¶21-22).
As per claim 2: Rubin ‘802 in view of Anand ‘857, and further in view of Camus ‘885 discloses all limitations of claim 1, as stated above, from which claim 2 is dependent upon. Furthermore, Rubin ‘802 discloses:
further comprising sending a decryption request to the second hardware security system to decrypt the encrypted symmetric key sent to the second hardware security system (the HSM hub 102 requesting HSM2 804 to decrypt the encrypted fleet key 812 sent to HSM2 804 [Rubin ‘802, ¶¶25, 27, 35, 66-67; Fig.1, Fig.9]) using a private key corresponding to the generated public key prior to the decrypting of the sent encrypted original key (the encrypted fleet key 812 is decrypted with the private key 816 corresponding to public key 818 used to encrypt the fleet key 812 [Rubin ‘802, ¶¶66, 68, 122; Figs.8-9]).
As per claim 3: Rubin ‘802 in view of Anand ‘857, and further in view of Camus ‘885 discloses all limitations of claims 1-2, as stated above, from which claim 3 is dependent upon. Furthermore, Rubin ‘802 discloses:
wherein the public key and the private key are generated by the second hardware security system to migrate the original key from the first hardware security system to the second hardware security system (the public key 818 and private key 816 are generated by HSM2 804, where the public and private keys are used in the process to securely transmit cryptographic information from HSM1 802 to HSM2 804 [Rubin ‘802, ¶¶25, 27, 65, 68, 122; Fig.1, Fig.8]).
As per claim 4: Rubin ‘802 in view of Anand ‘857, and further in view of Camus ‘885 discloses all limitations of claims 1-2, as stated above, from which claim 4 is dependent upon. Furthermore, Rubin ‘802 discloses:
wherein the private key is not sent to the first hardware security system to migrate the original key from the first hardware security system to the second hardware security system (only the public key 818, of the public-private key pair of HSM2 804, is sent to HSM1 802, where the public key 818 is used in the process to securely transmit cryptographic information from HSM1 802 to HSM2 804 [Rubin ‘802, ¶¶27, 65-68, 122; Fig.1, Fig.8]).
As per claim 5: Rubin ‘802 in view of Anand ‘857, and further in view of Camus ‘885 discloses all limitations of claim 1, as stated above, from which claim 5 is dependent upon. Furthermore, Rubin ‘802 discloses:
wherein the original key is a cryptographic key, a stored password, or a secret value (the cryptographic information may be a cryptographic key such as an application key, a shared secret key, or a domain key [Rubin ‘802, ¶¶29-30, 44, 47]).
As per claims 6-10: Claims 6-10 define a non-transitory computer readable medium that recites substantially similar subject matter as the method of claims 1-5, respectively. Specifically, claims 6-10 are directed to a non-transitory computer readable medium having stored thereon instructions for migrating a key comprising executable code which when executed by processors, causes the processors to perform the method claims 1-5, respectively. Thus, the rejection of claims 1-5 is equally applicable to claims 6-10, respectively.
As per claims 11-15: Claims 11-15 define an apparatus that recites substantially similar subject matter as the method of claims 1-5, respectively. Specifically, claims 11-15 are directed to a network traffic manager apparatus, comprising memory comprising programmed instructions stored in the memory and processors configured to be capable of executing the programmed instructions stored in the memory to perform the method claims 1-5, respectively. Thus, the rejection of claims 1-5 is equally applicable to claims 11-15, respectively.
As per claims 16-20: Claims 16-20 define a system that recites substantially similar subject matter as the method of claims 1-5, respectively. Specifically, claims 16-20 are directed to a network traffic management system, comprising traffic management apparatuses, server devices, or client devices, the network traffic management system comprising memory comprising programmed instructions stored thereon and processors configured to be capable of executing the stored programmed instructions to perform the method claims 1-5, respectively. Thus, the rejection of claims 1-5 is equally applicable to claims 16-20, respectively.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Stapleton, US 12,034,836 B1: deriving, by a first HSM, a first cryptographic key based on an initial key and a first set of seed bits. The method also includes receiving a message comprising a second cryptographic key from a key exchange management device, wherein the second cryptographic key is associated with a second HSM.
Berger et al., US 20070226786 A1: securely migrating an instance of a virtual Trusted Platform Module from one physical platform to another. A virtual Trusted Platform Module instance's state is downloaded from a source virtual Trusted Platform Module and is encrypted using a hybrid of public and symmetric key cryptography.
Grubin et al., US 10764047 B2: an HSM cluster client resynchronizes the HSM cluster by acquiring a list of keys and key versions stored on each HSM, and generating an update map. Using the update map, the HSM client obtains, form various HSM in the HSM cluster, the latest versions of the out-of-date keys in an encrypted form.
Rubin et al., US 11784811 B2: storage of cryptographic information maintained on a fleet of HSMs may be provided by dividing the cryptographic information into a number of stripes which are distributed and stored on individual HSMs. Parity information is generated which allows one or more stripes to be regenerated.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN L KONG whose telephone number is (571)272-2646. The examiner can normally be reached Monday-Thursday 9:00am-7: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, JUNG (JAY) KIM can be reached on (571)272-3804. 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.
/ALAN L KONG/Examiner, Art Unit 2494
/THEODORE C PARSONS/Primary Examiner, Art Unit 2494