DETAILED ACTION
Response to Arguments
Applicant's arguments ("REMARKS") filed 01 June 2026 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 currently pending.
Re: Claim Rejections Under 35 U.S.C. §103
Applicant’s arguments, indicated on pp.9-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”), Anand et al., US 2022/0393857 A1 (hereinafter, “Anand ‘857”), and Camus et al., US 2006/0050885 A1 (hereinafter, “Camus ‘885”) 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, Anand ‘857, and Camus ‘885 do not disclose communicating with a first and a second hardware security system “using different sessions”, wherein each hardware security system returns a “session handle” that is used when requesting cryptographic operations, as amended in the independent claims.
Rubin ‘802’s fleet architecture has no need for separate sessions with “session handles”, as amended in the independent claims, because the HSMs of the fleet already share common infrastructure and compatible interfaces.
Anand ‘857 and Camus ‘885 do not cure the deficiencies of Rubin ‘802.
Rubin ‘802 is silent as to HSMs having different APIs, and the claimed invention addresses a specific problem not taught by the prior art.
In Response to Argument A
Applicant argues that Rubin ‘802, Anand ‘857, and Camus ‘885 do not disclose “… communicating, by a network traffic manager apparatus, with a first hardware security system and a second hardware security system using different sessions, wherein the first hardware security system returns a first session handle and the second hardware security system returns a second session handle, and wherein the first session handle and the second session handle are used when requesting cryptographic operations to be performed by the first hardware security system and the second hardware security system …”, as amended in the independent claims.
The Applicant’s argument is partially persuasive.
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 newly cited portions of Camus ‘885 and Khattar, US 8,543,830 B1 (hereinafter, “Khattar ‘830”).
Camus ‘885 continues to be relied upon, and is further relied upon at ¶¶58 and 60, for the establishment of different sessions with each of a plurality of hardware cryptographic resources by way of the respective interfaces of those resources. Camus ‘885 discloses that a platform is equipped with several sources of cryptographic resources ‘… each having a specific API 4 for accessing the CRs … may be of the same nature (for example PKCS#11, CAPI, PC/SC, etc.) or of different natures …’ (Camus ‘885, ¶58), and that a bridge ‘… sets up communication sessions with each of the CR sources 3 via their respective access interfaces 4 … maintains these active sessions …’, relaying instructions to those sources over the maintained sessions (Camus ‘885, ¶¶60-62, 91).
Khattar ‘830, on the other hand, discloses the newly recited “session handle” mechanism. In Khattar ‘830, a custom provider (a custom PKCS #11 JCE provider) calls a create session function, which in turn calls a security token-specific create session function that establishes a session with the hardware security module (HSM) 202 via a native protocol. Khattar ‘830 then discloses that ‘… [t]he HSM 202 returns a session handle …’ that identifies a location of corresponding cryptographic information, such as a private key (Khattar ‘830, Col.7 lines 22-33). Khattar ‘830 further discloses that this returned session handle is thereafter used to request operations of the HSM. For example, Khattar ‘830 discloses ‘… Using the session handle, the custom provider 210 queries the HSM 202 for an appropriate private key object … uses the private key object to authenticate data (e.g., sign electronic documents) …’ (Khattar ‘830, Col.7 lines 36-40; Fig.3).
Additionally, Khattar ‘830 discloses that the session handle is a value that identifies a particular session, that threads of execution access sessions using the session handles, and that the sessions represent connections between the application and the security token (Khattar ‘830, Col.4 lines 8-27). Khattar ‘830 further discloses that sessions may be opened on multiple security tokens (Khattar ‘830, Col.5 lines 13-14), and that a different security token, such as another hardware security module, may be connected and a new session established (Khattar ‘830, Col.7 lines 63-66).
Thus, for the reasons stated above, combination of Rubin ‘802 in view of Anand ‘857, Camus ‘885, and Khattar ‘830 discloses all limitations of the amended independent claims.
See Claim Rejections – 35 USC §103 below for further details.
In Response to Argument B
Applicant argues that Rubin ‘802’s HSMs communicate via an HSM management hub using a fleet management agent that relays information through a driver on a client computer system, that Rubin ‘802’s cryptographic material is cryptographically protected with a fleet key and transferred using shared protocols such as TLS, and that Rubin ‘802’s architecture ‘… has no need for separate sessions with session handles because all HSMs in the fleet already share common infrastructure and compatible interfaces …’.
The Examiner respectfully disagrees. The Applicant’s argument is not persuasive.
Applicant’s assertion that Rubin ‘802’s architecture has ‘… no need for separate sessions …’ is not supported by the paragraph of Rubin ‘802 that Applicant cites to on pp.9-10 of the REMARKS. Rubin ‘802 at ¶36 discloses a fleet information store 126 that includes ‘… information that describes how to communicate with each member of the HSM fleet …’. Rubin ‘802 at ¶36 further discloses that, as an alternative to hub-relayed communication, fleet-member HSMs may communicate in a peer-to-peer fashion, and that cryptographic information may be exchanged ‘… using a secure transport protocol such as TLS that relies on a negotiated shared secret specific to the connection …’. A negotiated shared secret that is specific to a given connection is, by definition, per-connection session state. Thus, Rubin ‘802 expressly discloses individualized communication with each member of the fleet.
In Response to Argument C
Applicant argues that Anand ‘857 and Camus ‘885 do not cure the asserted deficiency of Rubin ‘802. Applicant states that Anand ‘857 only discloses HSM middleware that translates client service requests to vendor-specific HSM languages, and that Camus ‘885 only discloses APIs such as PKCS#11 and CAPI for accessing cryptographic hardware, and asserts that neither reference discloses communicating with HSMs using different sessions where each HSM returns a session handle.
The Applicant’s argument is partially persuasive.
Camus ‘885 at ¶60 discloses that the bridge 6 sets up communication sessions with each of the cryptographic resource sources 3 by way of their respective access interfaces 4, maintains those sessions active, and relays instructions to those sources over the maintained sessions. Camus ‘885 at ¶91 further discloses that the bridge ‘… manages a PKCS#11 session with each CR source 3 …’. Camus ‘885 at ¶58 discloses that these sources each have a specific API and that such APIs ‘… may be of the same nature … or of different natures …’. Camus ‘885 accordingly discloses a distinct session established with each of a plurality of cryptographic resources using the respective interface of each such resource. Camus ‘885’s bridge 6 is between the application and a plurality of sources having different interfaces, maintains a separate session with each source, and relays cryptographic operations to each source so that the sources do not need to communicate with each other (Camus ‘885, ¶¶58-62, 91).
With respect to the Applicant’s argument that no cited reference discloses that a hardware security system returns a session handle that is used when requesting cryptographic operations, that argument is addressed by Khattar ‘830, as discussed in In Response to Argument A above.
In Response to Argument D
Applicant argues that Rubin ‘802 is silent on HSMs having different APIs configured to perform tasks using the original key, and that the claimed invention addresses a specific problem not taught by the prior art. On pp.11-12 of the REMARKS, Applicant cites ¶¶3, 24, and 43 of the Specification, and asserts that the session handles enable the network traffic manager apparatus to independently request cryptographic operations from each hardware security system ‘… regardless of whether the hardware security systems share common infrastructure or compatible interfaces …’.
The Examiner respectfully disagrees. The Applicant’s argument is not persuasive.
With respect to the assertion that Rubin ‘802 is silent on HSMs having different APIs, that argument is moot. As stated in the previous Office Action, Rubin ‘802 is not relied upon to disclose that the first and second hardware security systems have APIs. Anand ‘857 is relied upon to disclose that different vendor HSMs have different ‘vendor-specific HSM languages’ (Anand ‘857, ¶¶3-4, 40, 42). Anand ‘857 expressly discloses that different vendor HSMs employ different vendor-specific HSM languages and that a system must translate requests into the appropriate language for each HSM to enable a client to request from ‘… any number of HSMs …’ (Anand ‘857, ¶40). Camus ‘885 is relied upon to disclose that the interfaces for accessing cryptographic hardware are application programming interfaces (APIs), such as PKCS#11 and CAPI, and that such APIs are configured to perform cryptographic tasks using keys. Cryptographic resources from different suppliers present interfaces that may be of different natures (Camus ‘885, ¶¶21-23, 58).
Furthermore, Applicant’s arguments are inconsistent with the scope with the claims. The amended independent claims recite that the apparatus communicates using different sessions, that each hardware security system returns a session handle, and that the session handles are used when requesting cryptographic operations. The claims do not recite that the sessions are authenticated, that the apparatus requests operations independently of each hardware security system, or that the migration is performed regardless of whether the hardware security systems share common infrastructure or compatible interfaces. Arguments directed to features that are not recited in the claims cannot serve to distinguish over the prior art. See MPEP §2145(VI); In re Self, 671 F.2d 1344 (CCPA 1982).
The new grounds of rejection entered with respect to claims 1-20 are necessitated by Applicant's amendments to independent claims 1, 6, 11, and 16. 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”), and further in view of Khattar, US 8,543,830 B1 (hereinafter, “Khattar ‘830”).
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:
receive an encrypted symmetric key from the 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 the 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, and wherein the first hardware security system has a first (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]);
send 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]);
receive 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; send 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
complete 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: “… communicating, by a network traffic manager apparatus, with a first hardware security system and a second hardware security system using different sessions, wherein the first hardware security system returns a first session handle and the second hardware security system returns a second session handle, and wherein the first session handle and the second session handle are used when requesting cryptographic operations to be performed by the first hardware security system and the second hardware security system, the network traffic manager apparatus using the first session handle and the second session handle to: … wherein the generated public key is transmitted to the first hardware security system prior to the encryption, and 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 … complete 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]) ...
... complete 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: “… communicating, by a network traffic manager apparatus, with a first hardware security system and a second hardware security system using different sessions, wherein the first hardware security system returns a first session handle and the second hardware security system returns a second session handle, and wherein the first session handle and the second session handle are used when requesting cryptographic operations to be performed by the first hardware security system and the second hardware security system, the network traffic manager apparatus using the first session handle and the second session handle to: … 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:
… communicating, by a network traffic manager apparatus, with a first hardware security system and a second hardware security system using different sessions (a computer platform 1 equipped with several sources 3 of cryptographic resources (CR), each source 3 having a specific API 4 for accessing the CRs, where the APIs 4 may be of the same nature (for example PKCS#11, CAPI, PC/SC) or of different natures; a bridge 6, placed between the mutualization API 5 and the APIs 4 for accessing the CR sources 3, sets up communication sessions with each of the CR sources 3 via their respective access interfaces 4 and maintains these active sessions, and relays the instructions from the mutualization API 5 to the CR sources 3 and retrieves the responses one by one from the CR sources 3; the bridge 6 manages a PKCS#11 session with each CR source 3 [Camus ‘885, ¶¶58-60, 91; Fig.1]), …
... 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; several sources 3 of cryptographic resources each have a specific API 4 for accessing the CRs, where the APIs 4 may be of the same nature or of different natures [Camus ‘885, ¶¶21-23, 58]) ...
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; and further to modify the HSM hub 102 of Rubin ‘802 such that communication sessions are set up and maintained with each of the first and second HSMs via their respective APIs, as disclosed in Camus ‘885. 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, 59-60).
As stated above, Rubin ‘802 in view of Anand ‘857, and further in view of Camus ‘885 does not explicitly disclose the limitation: “... communicating, by a network traffic manager apparatus, with a first hardware security system and a second hardware security system using different sessions, wherein the first hardware security system returns a first session handle and the second hardware security system returns a second session handle, and wherein the first session handle and the second session handle are used when requesting cryptographic operations to be performed by the first hardware security system and the second hardware security system, the network traffic manager apparatus using the first session handle and the second session handle to: ...”.
Khattar ‘830, however, discloses:
… communicating, by a network traffic manager apparatus, with a first hardware security system and a second hardware security system using different sessions, wherein the first hardware security system returns a first session handle and the second hardware security system returns a second session handle, and wherein the first session handle and the second session handle are used when requesting cryptographic operations to be performed by the first hardware security system and the second hardware security system, the network traffic manager apparatus using the first session handle and the second session handle to: (a custom provider 210, such as a custom PKCS #11 JCE provider, calls a custom create session function defined in a bridge 302, which in turn calls a security token-specific create session function that establishes a session with a hardware security module (HSM) 202 via a native protocol, where the HSM 202 returns a session handle that identifies a location of corresponding cryptographic information, such as a private key, and where the session handle is stored as dynamic session data; using the session handle, the custom provider 210 queries the HSM 202 for a private key object, and the private key object is used to authenticate data, such as signing electronic documents; a session handle is a value that identifies a particular session, where each thread of execution created by the application 106 may access each session associated with the slot 116 via the session handles, and where the sessions 118 represent logical connections with the application 106; the application 106 may open the sessions 118 on multiple security tokens, and where a different security token, such as another hardware security module, may be connected such that a new session is established therewith [Khattar ‘830, Col.4 lines 8-27, Col.5 lines 13-14, Col.7 lines 22-33, Col.7 lines 36-40, Col.7 lines 63-66; Fig.3]) …
Rubin ‘802 (modified by Anand ‘857 and Camus ‘885) and Khattar ‘830 are analogous art because they are from the same field of endeavor, namely that of managing sessions for performing 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) and Khattar ‘830 before them, to modify the method in Rubin ‘802 (modified by Anand ‘857 and Camus ‘885) to include the teachings of Khattar ‘830, namely to implement the communication sessions established with each of the first and second HSMs of Camus ‘885 such that each HSM returns a session handle identifying the respective session, and such that the returned session handles are thereafter used when requesting cryptographic operations to be performed by the respective HSM, as disclosed in Khattar ‘830. A motivation for doing so would be to enable an application to identify and reference each of a plurality of concurrent sessions with hardware security modules, such that the cryptographic information associated with each session may be located and used to perform cryptographic operations without restarting the application (see Khattar ‘830, Col.3 lines 18-29, Col.7 lines 22-40).
As per claim 2: Rubin ‘802 in view of Anand ‘857, and further in view of Camus ‘885, and further in view of Khattar ‘830 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, and further in view of Khattar ‘830 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, and further in view of Khattar ‘830 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, and further in view of Khattar ‘830 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. 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 extension fee 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 date of this final 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-Friday 8:00am-4:30pm 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
/KAVEH ABRISHAMKAR/Primary Examiner, Art Unit 2494
Prosecution Insights