DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the application filed on 11/01/2024.
Claims 1-20 are currently pending in this application.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted by applicant dated 1/27/2025 have been considered by the examiner.
Claim Objections
Claims 8-10 and 15-20 are objected to because of the following informalities: the claims do not recite the limitations of the referenced claims in full.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“a request acquisition unit, configured to acquire…” in claim 11;
“a crypto operation unit, configured to invoke…” in claim 11;
“a configuration information sending unit, configured to send…” in claim 12;
“a mirror acquisition unit, configured to acquire…” in claim 12;
“a mirror forwarding unit, configured to forward…” in claim 12;
“the first crypto module is configured to: acquire…” in claim 13;
“the second crypto module is configured to acquire…” in claim 13.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 11-13 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim limitation “a request acquisition unit, configured to acquire…” in claim 11, “a crypto operation unit, configured to invoke…” in claim 11, “a configuration information sending unit, configured to send…” in claim 12, “a mirror acquisition unit, configured to acquire…” in claim 12, “a mirror forwarding unit, configured to forward…” in claim 12, “the first crypto module is configured to: acquire…” in claim 13, and “the second crypto module is configured to acquire…” in claim 13 invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification fails to provide any software, hardware, or firmware which would disclose the structure of the claimed limitation. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 15 and 18-20 are rejected under 35 U.S.C. 101 because the claims do not fall within at least one of the four categories of patent eligible subject matter.
As per claims 15 and 18-20, the limitations recite a “storage medium” which may be interpreted as a signal or carrier wave. This does not fall under one of the four statutory categories. The examiner suggests amending the claims to recite a non-transitory storage medium.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, 4-5, 8-13, 15-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Rubin et al. US 9660970 hereinafter referred to as Rubin.
As per claim 1, Rubin discloses a crypto configuration method, applied to a crypto management device, wherein the crypto management device is configured to manage crypto modules of a plurality of servers, and the crypto configuration method comprises (Rubin [Abstract], [FIG. 1], [Col. 2, lines 56-67], [Col. 3, lines 1-5], [Col. 5, lines 1-14], [Col. 9, lines 36-52], [Col. 12, lines 57-67]: HSM management hub constitutes the crypto management device, see e.g., "HSM management hub coordinates the distribution and synchronization of cryptographic material across a fleet of connected hardware security modules (“HSMs”)… HSM management hub communicates with the members of the fleet, and facilitates the exchange and synchronization of cryptographic information between the HSMs… HSM management hub is able to facilitate the formation of HSM domains, distribute updated cryptographic information, and backup and restore HSM data"):
sending key configuration information to a first crypto module, wherein the key configuration information comprises at least a key for the first crypto module to perform a crypto service, and the first crypto module is any crypto module of any server (Rubin [FIG. 1], [FIG. 6], [FIG. 7, block 714], [Col. 7, lines 8-11], [Col. 14, lines 2-3]: provided key value constitutes key configuration information comprising at least a key, which the receiving HSM retains and subsequently uses to perform crypto operations and management hub distributes protected application key to the crypto modules for their use, see e.g., “The HSM management hub 102 provides the protected new fleet key to the remaining HSMs which decrypt and retain the new fleet key… the HSM management hub distributes the protected application key to the destination HSMs”);
acquiring a first key mirror of the first crypto module, wherein the first key mirror comprises the key (Rubin [FIG. 7], [Col. 13, lines 52-59]: protected application key returned to the HSM management hub constitutes the first key mirror comprising a key, see e.g., "At block 708 the first domain member HSM cryptographically protects the application key using the domain key stored on the first domain member HSM… At block 710, the first domain member HSM returns the protected application key to the HSM management hub");
and forwarding the first key mirror to a second crypto module such that the second crypto module acquires the key to perform a crypto operation with the key when the second crypto module is invoked by a corresponding server, wherein the second crypto module is another crypto module configured on a different server (Rubin [FIG. 7], [Col. 13, lines 60-67], [Col. 14, lines 1-7]: "HSM management hub identifies 712 the destination HSMs for the newly generated application key… At block 714 the HSM management hub distributes the protected application key to the destination HSMs… A second domain member HSM receives the protected application key from the HSM management hub and unpacks 716 the protected application key using the domain key. At block 718, the second domain member HSM is able to access the application key in a usable format").
As per claim 2, Rubin discloses the crypto configuration method according to claim 1, wherein the crypto modules of the plurality of servers managed by the crypto management device comprise a shared key (Rubin [FIG. 1, blocks 118, 120, 122], [Col. 2, lines 59-61], [Col. 4, lines 3-10], [Col. 4, lines 19-20], [Col. 5, lines 2-39]: each HSM in the fleet is provided with a copy of a fleet key which constitutes a shared key, see e.g., "Each HSM in the fleet is provided with a copy of a domain key for the fleet called a fleet key… shared fleet key may be established across the fleet of HSMs");
the acquiring the first key mirror of the first crypto module comprises encrypting, by the first crypto module, a corresponding key mirror with the shared key (Rubin [Abstract], [FIG. 1], [FIG. 7], [Col. 3, lines 33-41], [Col. 4, lines 19-20], [Col. 13, lines 57-59]: "an application key generated on a first HSM is encrypted with the fleet key on the first HSM. The encrypted application key can be provided to the HSM management hub… At block 710, the first domain member HSM returns the protected application key to the HSM management hub");
and the forwarding the first key mirror to the second crypto module such that the second crypto module acquires the key comprises: forwarding the first key mirror to the second crypto module such that the second crypto module decrypts the first key mirror with the shared key to acquire a key mirror corresponding to the first crypto module, and acquiring the key according to the key mirror corresponding to the first crypto module (Rubin [FIG. 1], [Col. 3, lines 37-41], [Col. 3, lines 59-62], [Col. 4, lines 8-10], [Col. 14, lines 4-15]: "A second domain member HSM receives the protected application key from the HSM management hub and unpacks 716 the protected application key using the domain key… second domain member HSM is able to access the application key in a usable format").
As per claim 4, Rubin discloses a crypto configuration method, applied to crypto modules of servers, wherein the crypto modules comprise a first crypto module and a second crypto module, the first crypto module is any crypto module of any server, the second crypto module is another crypto module configured on a different server, and the crypto configuration method comprises (Rubin [FIG. 3], [Col. 9, lines 33-61]: first HSM on client computer system and second HSM is network-connected, see e.g., "first HSM 304 is a directly connected HSM that is connected to a client computer system 311 via a USB or serial connection… second HSM 306 is a network connected HSM, and communicates with the HSM management hub 302 over the network 310… first HSM 304, the second HSM 306, and the third HSM 308 are members of an HSM fleet… Fleet-member HSMs may be network-connected HSMs that are connected directly to the network 310, or internal or direct-connected HSMs that are connected indirectly to the network 310 through a client computer system"):
acquiring, by the first crypto module, key configuration information sent by a crypto management device, wherein the key configuration information comprises at least a key for performing a crypto service (Rubin [FIG. 1], [FIG. 6], [FIG. 7, block 714], [Col. 7, lines 8-11], [Col. 14, lines 2-3]: provided key value constitutes key configuration information comprising at least a key, which the receiving HSM retains and subsequently uses to perform crypto operations and destination HSM acquiring an actual application key for use, see e.g., “The HSM management hub 102 provides the protected new fleet key to the remaining HSMs which decrypt and retain the new fleet key… the HSM management hub distributes the protected application key to the destination HSMs”);
sending, by the first crypto module, a first key mirror to the crypto management device such that the crypto management device forwards the first key mirror to the second crypto module, wherein the first key mirror comprises the key (Rubin [FIG. 7], [Col. 13, lines 49-61], [Col. 14, 4-7]: "At block 708 the first domain member HSM cryptographically protects the application key using the domain key stored on the first domain member HSM… At block 710, the first domain member HSM returns the protected application key to the HSM management hub… HSM management hub identifies 712 the destination HSMs for the newly generated application key… A second domain member HSM receives the protected application key from the HSM management hub and unpacks 716 the protected application key using the domain key");
and acquiring, by the second crypto module, the first key mirror, and acquiring the key according to the first key mirror to perform a crypto operation with the key when the second crypto module is invoked by a corresponding server (Rubin [FIG. 7], [Col. 14, lines 6-8]: "A second domain member HSM receives the protected application key from the HSM management hub and unpacks 716 the protected application key using the domain key… block 718, the second domain member HSM is able to access the application key in a usable format").
As per claim 5, Rubin discloses the crypto configuration method according to claim 4, wherein the crypto modules comprise a shared key (Rubin [FIG. 1, blocks 118, 120, 122], [Col. 2, lines 59-61], [Col. 4, lines 3-10], [Col. 4, lines 19-20], [Col. 5, lines 2-39]: each HSM in the fleet is provided with a copy of a fleet key which constitutes a shared key, see e.g., "Each HSM in the fleet is provided with a copy of a domain key for the fleet called a fleet key… shared fleet key may be established across the fleet of HSMs");
the sending, by the first crypto module, the first key mirror to the crypto management device comprises encrypting, by the first crypto module, a corresponding key mirror with the shared key (Rubin [Abstract], [FIG. 1], [FIG. 7], [Col. 3, lines 33-41], [Col. 4, lines 19-20], [Col. 13, lines 57-59]: "an application key generated on a first HSM is encrypted with the fleet key on the first HSM. The encrypted application key can be provided to the HSM management hub… At block 710, the first domain member HSM returns the protected application key to the HSM management hub");
and the acquiring, by the second crypto module, the key according to the first key mirror comprises (Rubin [FIG. 7], [Col. 14, lines 6-8]: "A second domain member HSM receives the protected application key from the HSM management hub and unpacks 716 the protected application key using the domain key… block 718, the second domain member HSM is able to access the application key in a usable format"):
decrypting, by the second crypto module, the first key mirror with the shared key to acquire a key mirror corresponding to the first crypto module (Rubin [FIG. 7], [Col. 14, lines 6-8]: "A second domain member HSM receives the protected application key from the HSM management hub and unpacks 716 the protected application key using the domain key… block 718, the second domain member HSM is able to access the application key in a usable format");
and acquiring, by the second crypto module, the key according to the key mirror corresponding to the first crypto module (Rubin [FIG. 7], [Col. 14, lines 6-8]: "A second domain member HSM receives the protected application key from the HSM management hub and unpacks 716 the protected application key using the domain key… block 718, the second domain member HSM is able to access the application key in a usable format").
As per claim 8, Rubin discloses a crypto service method, applied to a crypto module of a server, comprising (Rubin [FIG. 1-3], [Col. 6, lines 40-41], [Col. 7, lines 61-65], [Col. 9, lines 36-40]: "a client computer system is connected to the first HSM 104… HSM 202 that is connected to a network 204 via a client computer system 203… HSM 202 may be a directly connected HSM connected to the client computer system 203 via a USB or serial connection… first HSM 304 is a directly connected HSM that is connected to a client computer system 311 via a USB or serial connection"):
acquiring a crypto service request from a crypto application, wherein the crypto application and the crypto module are on a same server (Rubin [Fig. 1-3], [Col. 6, lines 40-41], [Col. 6, lines 47-49]: a client computer system is connected to the first HSM 104… The application requests that the HSM perform cryptographic operations using the new cryptographic key”);
and invoking a key to perform a crypto operation according to the crypto service request to provide a crypto service for the crypto application, wherein the key is configured using the crypto configuration method according to claim 1 (Rubin [Fig. 1-3], [Col. 6, lines 40-41], [Col. 6, lines 47-49], [Col. 6, lines 49-52]: HSM using the key to perform crypto operation on the applications behalf, see e.g., “The application requests that the HSM perform cryptographic operations using the new cryptographic key… the application may use the new cryptographic key to cryptographically protect application data that is stored or shared with other applications”).
As per claim 9, Rubin discloses a crypto management device, comprising at least one memory and at least one processor, wherein the memory is configured to store one or more computer- executable instructions, and the processor is configured to invoke the one or more computer- executable instructions to perform the crypto configuration method according to claim 1 (Rubin [FIG. 18], [Col. 23, lines 51-53], [Col. 24, lines 66-67], [Col. 25, lines 1-10]: "Servers, as used herein, may be implemented in various ways, such as hardware devices or virtual computer systems… Each server typically will include an operating system that provides executable program instructions for the general administration and operation of that server and typically will include a computer-readable storage medium (e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, when executed by a processor of the server, allow the server to perform its intended functions”).
As per claim 10, Rubin discloses a server, comprising at least one memory and at least one processor, wherein the memory is configured to store one or more computer-executable instructions, and the processor is configured to invoke the one or more computer-executable instructions to perform the crypto configuration method according to claim 4 (Rubin [FIG. 18], [Col. 24, lines 66-67], [Col. 25, lines 1-10]: "Each server typically will include an operating system that provides executable program instructions for the general administration and operation of that server and typically will include a computer-readable storage medium (e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, when executed by a processor of the server, allow the server to perform its intended functions").
As per claim 11, the claim discloses a system corresponding to the method claim 8 above, and they are rejected, at least for the same reasons.
As per claim 12, the claim discloses a system corresponding to the method claim 1 above, and they are rejected, at least for the same reasons.
As per claim 13, the claim discloses a system corresponding to the method claim 4 above, and they are rejected, at least for the same reasons.
As per claim 15, Rubin discloses storage medium, storing one or more computer-executable instructions, wherein the one or more computer-executable instructions, when executed, implement the crypto configuration method according to claim 1 (Rubin [Col. 25, lines 2-5]: "a computer-readable storage medium (e.g., a hard disk, random access memory, read only memory, etc.) storing instructions that, when executed by a processor of the server, allow the server to perform its intended functions").
As per claim 16, the claim discloses a method corresponding to the method claim 8 above, and they are rejected, at least for the same reasons.
As per claim 17, the claim discloses a method corresponding to the method claim 10 above, and they are rejected, at least for the same reasons.
As per claims 18-20, the claims disclose a method corresponding to the method claim 15 above, and they are rejected, at least for the same reasons.
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, 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 3, 6-7, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Rubin et al. US 9660970 hereinafter referred to as Rubin in view of Nordenstam et al. US 6711263 hereinafter referred to as Nordenstam.
As per claim 3, Rubin teaches the crypto configuration method according to claim 1, wherein the crypto modules of the plurality of servers managed by the crypto management device comprise an asymmetric encryption key pair and a first asymmetric encryption key pair of the first crypto module is different from a second asymmetric encryption key pair of the second crypto module (Rubin [FIG. 8], [Col. 14, lines 18-33]: "first HSM 802 retains a cryptographic data store 806. The cryptographic data store 806 includes a public-private cryptographic key pair associated with the first HSM 802… public-private cryptographic key pair includes a first HSM private key 808 and a first HSM public key 810… a public-private cryptographic key pair associated with the second HSM 804… a second HSM private key 816 and a second HSM public key 818").
Rubin does not explicitly disclose a signed public key obtained from an external certificate authority and before the acquiring the first key mirror of the first crypto module, the crypto configuration method further comprises: acquiring a public key certificate of the second crypto module signed by the external certificate authority, wherein the public key certificate of the second crypto module comprises a second public key in the second asymmetric encryption key pair; and forwarding the public key certificate of the second crypto module signed by the external certificate authority to the first crypto module such that the first crypto module verifies the validity of the public key certificate of the second crypto module with the signed public key obtained from the external certificate authority.
Nordenstem teaches a signed public key obtained from an external certificate authority (Nordenstam [Col 5, lines 40-41], [Col. 5, lines 47-51]: "signed by the issuing Certificate Authority… the public key of a trusted CA… has to be stored in the protecting circuit 10… public key of such a CA is used for verification of the certificates of other circuits") and before the acquiring the first key mirror of the first crypto module, the crypto configuration method further comprises: acquiring a public key certificate of the second crypto module signed by the external certificate authority, wherein the public key certificate of the second crypto module comprises a second public key in the second asymmetric encryption key pair (Nordenstam [Col. 6, lines 14-16], [Col. 6, lines 39-41], [Col. 6, lines 44-45]: "the protecting circuit 20 is associated with a certificate CERT 2, which holds the public key of the circuit… the distributing unit 1 requests the certificate of the protecting circuit 20 of the receiving unit 2… receiving unit 2 responds by transmitting the certificate CERT 2 to the distributing unit 1");
and forwarding the public key certificate of the second crypto module signed by the external certificate authority to the first crypto module such that the first crypto module verifies the validity of the public key certificate of the second crypto module with the signed public key obtained from the external certificate authority (Nordenstam [Col. 6, lines 49-52], [Col. 6, lines 64-67]: "The transmitted certificate CERT 2 is then transferred from the communication interface 15 to the protected logic 13, which evaluates the certificate… protected logic 13 has to verify that the requested certificate CERT 2 is authentic. This is handled by using the public key, of the trusted CA, stored in the persistent memory 11 of the protecting circuit 10").
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Rubin of a crypto management device forwarding key mirrors between crypto modules to synchronize keys with the teachings of Nordenstam to include acquiring a public key certificate of the second crypto module signed by an external certificate authority and forwarding it to verify the validity in order to improve security by preventing distribution of the key to an unauthenticated or unauthorized module.
As per claim 6, Rubin teaches the crypto configuration method according to claim 4, wherein the crypto modules comprise an asymmetric encryption key pair and a first asymmetric encryption key pair of the first crypto module is different from a second asymmetric encryption key pair of the second crypto module (Rubin [FIG. 8], [Col. 14, lines 18-33]: "first HSM 802 retains a cryptographic data store 806. The cryptographic data store 806 includes a public-private cryptographic key pair associated with the first HSM 802… public-private cryptographic key pair includes a first HSM private key 808 and a first HSM public key 810… a public-private cryptographic key pair associated with the second HSM 804… a second HSM private key 816 and a second HSM public key 818").
Rubin does not explicitly disclose a signed public key obtained from an external certificate authority and before the sending, by the first crypto module, the first key mirror to the crypto management device, the crypto configuration method further comprises: acquiring, by the first crypto module, a public key certificate of the second crypto module signed by the external certificate authority that is sent by the crypto management device, wherein the public key certificate of the second crypto module comprises a second public key in the second asymmetric encryption key pair; verifying, by the first crypto module, the validity of the public key certificate of the second crypto module with the signed public key obtained from the external certificate authority; and in response to the public key certificate being valid, acquiring, by the first crypto module, the second public key in the second asymmetric encryption key pair, and encrypting a corresponding key mirror with the second public key to obtain the first key mirror.
Nordenstem teaches a signed public key obtained from an external certificate authority (Nordenstam [Col 5, lines 40-41], [Col. 5, lines 47-51]: "signed by the issuing Certificate Authority… the public key of a trusted CA… has to be stored in the protecting circuit 10… public key of such a CA is used for verification of the certificates of other circuits") and before the sending, by the first crypto module, the first key mirror to the crypto management device, the crypto configuration method further comprises: acquiring, by the first crypto module, a public key certificate of the second crypto module signed by the external certificate authority that is sent by the crypto management device, wherein the public key certificate of the second crypto module comprises a second public key in the second asymmetric encryption key pair (Nordenstam [Col. 6, lines 14-16], [Col. 6, lines 39-41], [Col. 6, lines 44-45]: "the protecting circuit 20 is associated with a certificate CERT 2, which holds the public key of the circuit… the distributing unit 1 requests the certificate of the protecting circuit 20 of the receiving unit 2… receiving unit 2 responds by transmitting the certificate CERT 2 to the distributing unit 1");
verifying, by the first crypto module, the validity of the public key certificate of the second crypto module with the signed public key obtained from the external certificate authority (Nordenstam [Col. 6, lines 64-67]: "protected logic 13 has to verify that the requested certificate CERT 2 is authentic. This is handled by using the public key, of the trusted CA, stored in the persistent memory 11 of the protecting circuit 10");
and in response to the public key certificate being valid, acquiring, by the first crypto module, the second public key in the second asymmetric encryption key pair, and encrypting a corresponding key mirror with the second public key to obtain the first key mirror (Nordenstam [Col. 7, lines 18-22], [Col. 8, lines 12-16]: "Provided the requested certificate CERT 2 is verified as authentic, the protected logic 13 determines… whether the protecting circuit 20 represents a type of circuit that is acceptable for protecting the encryption key information K… If the protecting circuit 20 of the receiving unit 2 is determined to be acceptable, the cryptographic engine 12 encrypts the encryption key information K by the public key of the receiving unit's protecting circuit 20. The public key is obtained from the certificate CERT 2").
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Rubin of a crypto management device forwarding key mirrors between crypto modules to synchronize keys with the teachings of Nordenstam to include the first module verifying the second module’s public key signed by an external certificate authority and encrypting the key to the verified second public key in order to improve security by preventing distribution of the key to an unauthenticated or unauthorized module.
As per claim 7, Rubin in view of Nordenstam teaches the crypto configuration method according to claim 6, wherein the acquiring, by the second crypto module, the first key mirror, and acquiring the key according to the first key mirror comprises: acquiring, by the second crypto module, the first key mirror (Rubin [FIG. 8], [Col. 14, lines 38-42]: "first HSM 802 cryptographically protects the current fleet key 812 with the received second HSM public key 818… second HSM 804 receives the protected current fleet key");
decrypting, by the second crypto module, the first key mirror with a second private key in the second asymmetric encryption key pair to acquire a key mirror corresponding to the first crypto module (Rubin [FIG. 8], [Col. 14, lines 41-44]: "The second HSM 804 receives the protected current fleet key, and decrypts the protected current fleet key using the second HSM private key 816");
and acquiring, by the second crypto module, the key according to the key mirror corresponding to the first crypto module (Rubin [FIG. 8], [Col. 14, lines 44-45]: "decrypted fleet key is used to update the out-of-date fleet key 820").
As per claim 14, Rubin teaches the crypto service system according to claim 13.
Rubin does not explicitly disclose wherein the crypto module is configured with a signed public key, and the signed public key is configured based on a key file of an external certificate authority.
Nordenstam teaches wherein the crypto module is configured with a signed public key, and the signed public key is configured based on a key file of an external certificate authority (Nordenstam [Col 5, lines 40-41], [Col. 5, lines 47-51]: "signed by the issuing Certificate Authority… the public key of a trusted CA… has to be stored in the protecting circuit 10… public key of such a CA is used for verification of the certificates of other circuits").
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Rubin of crypto modules holding public keys for the management device coordinated key synchronization with the teachings of Nordenstam to include configuring with a signed public key and the signed public key is configured based on a key file of an external certificate authority in order to improve security by preventing unauthorized key transfers through verification of the keys.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CAROLINE HOANG-ANH NGUYEN whose telephone number is (571)272-8309. The examiner can normally be reached Monday-Thursday 7am-5pm.
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, Farid Homayounmehr can be reached at (571) 272-3739. 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.
/C.H.N./Examiner, Art Unit 2495
/HENRY TSANG/Primary Examiner, Art Unit 2495
Prosecution Insights