DETAILED ACTION
The present application is being examined under the first inventor to file provisions of the AIA . 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.
This Office Action is in response Applicant communication filed on 7/2/2026.
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 7/2/2026 has been entered.
Claims
Claims 1-3, 12-14, and 22 have been amended.
Claims 1-22 are currently pending in the application.
Response to Arguments
101
The applicant argues that claim 12 is analogous to Enfish, where a specific self-referential table improved the way a computer stores and retrieves data (Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016)), and in Ancora, where storing license verification data in a specific memory location improved computer security (Ancora Techs., Inc. v. HTC Am., Inc., 908 F.3d 1343 (Fed. Cir. 2018)). In both cases, the Federal Circuit held such claims were not directed to an abstract idea but to a specific improvement in computer functionality. Specifically the applicant argues that the alleged abstract concept is integrated into a particular HSM architecture that solves cost and security problems specific to HSMs as described in the instant application, and thus is at least a practical application. Further the applicant argues that claim 12 addresses a problem that is inextricably intertwined with and necessarily rooted in computer technology as well as makes an improvement to computer-related technology (see applicants arguments/remarks pages 6 and 7).
However the examiner respectfully disagrees. The Enfish and Ancora cases were specific to their claims and the time those cases were filed. The limitations of claims 12 and 22 recite the abstract idea of receiving a request and then sending the request to a certain entity based on the type of request. This abstract idea can be performed outside of computers/HSMs, for example, sorting mail or trash/recycling. Using an HSM to perform the abstract idea is merely using a computer as a tool to perform the abstract idea. Further, using the abstract idea to send requests to particular instances of HSMs is generally linking the use of the abstract idea to a particular technological environment or field of use. Therefore claims 12 and 22 do not integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
The examiner has considered all of the applicant’s arguments but maintains the 101 rejection for claims 12-22.
103
In Applicant’s arguments with respect to claim 1 have been considered but are moot because new references have been added as necessitated by the applicant’s amendments to the claims.
Claim Objections
Claim 12 is objected to because of the following informalities:
In claim 12, “sending the service request to a first HSM instance of the HSM in response to determining that the service request is the first type of service request” (emphasis added) contains an extra space between “sending” and “the”.
Claim Interpretation
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. Such claim limitation(s) is/are: “means for receiving…”, “means for determining…”, and “means for sending…” in claim 22. Further, claim 8 recites “a handler configured to process a request…” and claim 9 recites “each handler is configured to process a request…”.
Because these claim limitation(s) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
The specification in section [0019] and Fig. 1 discloses the structure for “means for receiving…” to be a driver/network interface 130. The American Heritage Dictionary of the English Language defines a network interface as “a device, such as a cable, network card, monitor, or keyboard, that enables interaction or communication between a computer and another entity” and “Collins English Dictionary defines a network interface as “an electrical circuit linking one device, esp a computer, with another”.
The specification in section [0023], [0024], and Fig. 1 discloses the “means for determining…” as a request/response handler for each HSM instance. The request/response handler uses a service request identifier to determine the type of service request and then relays it to an HSM instance that processes that type of service request. The request/response handler is part of the HSM in Fig. 1 and the HSM has the corresponding structure as recited in specification section [0026] e.g. HSM 190 may include multiple modules including interface 210, processor 220, secure memory/key store 230, tamper protection controller 240, random number generator 250, and a firmware 260.
The specification in section [0023], [0024], and Fig. 1 discloses the “means for sending…” as a request/response handler for each HSM instance. The request/response handler uses a service request identifier to determine the type of service request and then relays it to an HSM instance that processes that type of service request. The request/response handler is part of the HSM in Fig. 1 and the HSM has the corresponding structure as recited in specification section [0026] e.g. HSM 190 may include multiple modules including interface 210, processor 220, secure memory/key store 230, tamper protection controller 240, random number generator 250, and a firmware 260.
Further, the specification in section [0023] and Fig. 1 discloses “a handler configured to process a request…” and “each handler is configured to process a request…” as a request/response handler for each HSM instance. The request/response handler uses a service request identifier to determine the type of operation request and then sends it to an HSM that processes that type of operation request. The request/response handler is part of the HSM in Fig. 1 and the HSM has the corresponding structure as recited in specification section [0026] e.g. HSM 190 may include multiple modules including interface 210, processor 220, secure memory/key store 230, tamper protection controller 240, random number generator 250, and a firmware 260.
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 § 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 12-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 12-21 are directed to a method and claim 22 is directed to a system. Therefore, these claims fall within the four statutory categories of invention.
Claim 12 recites receiving a service request and sending the service request to a certain entity based on the type of the service request. Specifically, the claim recites “receiving a service request…; determining whether the service request is a first type of service request or a second type of service request; sending the service request to a first… instance… in response to determining that the service request is the first type of service request; sending the service request to a second… instance… in response to determining that the service request is the second type of service request”, which is grouped within the “mental processes” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test because the claims involve receiving a service request and sending the service request to a certain entity based on the type of the service request which falls under the category of concepts performed in the human mind (including an observation, evaluation, judgment, opinion). Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; MPEP § 2106.04(a)). Claim 22 is directed to a system that performs the same functions of claim 12. Therefore Claim 22 is also directed to the abstract idea of receiving a service request and sending the service request to a certain entity based on the type of the service request.
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test, the additional element(s) of claims 12 and 22, such as the use of an application running on a host, HSM, first HSM instance, and second HSM instance, merely using a computer as a tool to perform an abstract idea. Specifically, the application running on a host, HSM, first HSM instance, and second HSM instance perform the steps or functions of receiving a service request and sending the service request to a certain entity based on the type of the service request. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to the acts required to carry out the abstract idea. Further, the limitation “wherein the first HSM instance and the second HSM instance are physically on the HSM, wherein the first HSM instance is logically separate from the second HSM instance, and wherein the first HSM instance is configured to process, for an application, only the first type of service requests and the second HSM instance is configured to process, for the application, only the second type of service requests” is describing the HSM and generally linking the use of the judicial exception to a particular technological environment (e.g. HSM computer environment) or field of use. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP § 2106.05(a)), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP § 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (MPEP § 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
Claims 12 and 22 does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP § 2106.05), the additional element(s) of using an application running on a host, HSM, first HSM instance, and second HSM instance to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of receiving a service request and sending the service request to a certain entity based on the type of the service request. As discussed above, taking the claim elements separately, the application running on a host, HSM, first HSM instance, and second HSM instance perform(s) the steps or functions of the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of receiving a service request and sending the service request to a certain entity based on the type of the service request. Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Further, the limitation “wherein the first HSM instance and the second HSM instance are physically on the HSM, wherein the first HSM instance is logically separate from the second HSM instance, and wherein the first HSM instance is configured to process, for an application, only the first type of service requests and the second HSM instance is configured to process, for the application, only the second type of service requests” is describing the HSM and generally linking the use of the judicial exception (e.g. receiving a service request and sending the service request to a certain entity based on the type of the service request) to a particular technological environment (e.g. HSM computer environment) or field of use. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of receiving a service request and sending the service request to a certain entity based on the type of the service request. Therefore, the use of these additional elements does no more than generally link the use of the judicial exception to a particular technological environment or field of use (MPEP 2106.05(h). Therefore, the claim is not patent eligible.
The dependent claims 13-21 further describe the abstract idea. Claims 13 and 14 recite that first HSM instance and the second HSM instance are configured to only process a specific type of service request. The use of an HSM to process a specific type of service request is merely using a computer as a tool to perform an abstract idea; claims 15 and 16 recite non-function descriptive material of the types of services; claim 17 recites non-functional descriptive material of the cryptographical operation; claim 18 further describes the HSM as including a first partition and a second partition; claims 19 and 20 recite the abstract idea of parsing the received service request to determine the type of service request based on an opcode of the received service request; claim 21 broadly recites performing key management and cryptographical operations associated with the service request. This is an abstract idea which can be performed by a human with pen and paper.
The dependent claims 13-21 do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible.
Rejections under 35 § U.S.C. 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all
obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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-3, 7, 9-14, 18, 21, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190238333 A1 (“Grubin”) and US 20240184896 A1 (“Anumulapally”).
Per claim 1, Grubin teaches:
a first HSM instance configured to process, for an application, [only] a first type of service request (e.g. The HSM cluster client selects 604 a particular HSM in the HSM cluster to process the received request. The particular HSM may be selected based at least in part on the type of request submitted by the application, the current processing loads of the individual HSMs in the HSM cluster, the cryptographic processing capabilities of the individual HSMs in the HSM cluster, or preference information configured by an administrator) and (e.g. Using the HSM cluster API 312, the client application 308 may submit key-generation requests, key-deletion requests, key-modification requests, and key-use requests, to the HSM cluster. The requests are received by the HSM cluster API 312 and passed to the HSM cluster command service 314. The HSM cluster command service 314 uses client preferences 320 and HSM cluster data 322 to identify a target HSM for each request) (Section [0052], [0053], [0071], [0072], [0075] and Fig. 1);
a second HSM instance configured to process, for the application, [only] a second type of service request (e.g. The HSM cluster client selects 604 a particular HSM in the HSM cluster to process the received request. The particular HSM may be selected based at least in part on the type of request submitted by the application, the current processing loads of the individual HSMs in the HSM cluster, the cryptographic processing capabilities of the individual HSMs in the HSM cluster, or preference information configured by an administrator) and (e.g. Using the HSM cluster API 312, the client application 308 may submit key-generation requests, key-deletion requests, key-modification requests, and key-use requests, to the HSM cluster. The requests are received by the HSM cluster API 312 and passed to the HSM cluster command service 314. The HSM cluster command service 314 uses client preferences 320 and HSM cluster data 322 to identify a target HSM for each request) (Section [0052], [0053], [0071], [0072], [0075] and Fig. 1);
wherein the first type of service request is a service request that differs from the second type of service request (e.g. In some examples, the request is a request to encrypt information using a cryptographic key maintained by the HSM cluster. In other examples, the request is a request to decrypt information using a cryptographic key maintained by the HSM cluster. In yet another example, the request is a request to generate a cryptographic signature for a block of provided data. In yet another example, the request is a request to verify a cryptographic signature of a block of provided data) (Section [0071], [0072], [0075] and Fig. 1).
Although Grubin teaches multiple HSM instances that are selected based on the type of service request for an application, Grubin does not specifically teach:
…only a first type of service request;
…only a second type of service request;
wherein the first HSM instance and the second HSM instance are physically on the HSM, and wherein the first HSM instance is logically separated from the second HSM instance.
However Anumulapally, in analogous art of HSM, discloses:
…only a first type of service request (e.g. Here, the main processor 10 is virtualized to provide multiple virtual HSMs (vHSMs) each with their own HSM app 171 for handling cryptographic transactions 210 for multiple Crypto API Clients 156. A virtual HSM is a secure execution environment hosted on a physical HSM that provides specific cryptographic services. Each physical HSM would typically host multiple vHSMs depending on the available cryptographic capacity on the physical HSM. Each vHSM may provide specific services associated with a specific cryptographic application such as General Purpose Crypto or Payments Crypto application) (Section [0042]);
…only a second type of service request (e.g. Here, the main processor 10 is virtualized to provide multiple virtual HSMs (vHSMs) each with their own HSM app 171 for handling cryptographic transactions 210 for multiple Crypto API Clients 156. A virtual HSM is a secure execution environment hosted on a physical HSM that provides specific cryptographic services. Each physical HSM would typically host multiple vHSMs depending on the available cryptographic capacity on the physical HSM. Each vHSM may provide specific services associated with a specific cryptographic application such as General Purpose Crypto or Payments Crypto application) (Section [0042]);
wherein the first HSM instance and the second HSM instance are physically on the HSM, and wherein the first HSM instance is logically separated from the second HSM instance (e.g. Within the HSM 101 are two processors: a main processor 10, also referred to as a host, and a security processor 50, also referred to as a cryptographic co-processor. Here, the main processor 10 is virtualized to provide multiple virtual HSMs (vHSMs) each with their own HSM app 171 for handling cryptographic transactions 210 for multiple Crypto API Clients 156. A virtual HSM is a secure execution environment hosted on a physical HSM that provides specific cryptographic services. Each physical HSM would typically host multiple vHSMs depending on the available cryptographic capacity on the physical HSM. Each vHSM may provide specific services associated with a specific cryptographic application such as General Purpose Crypto or Payments Crypto application. Each vHSM is typically assigned/allocated specific set of CPU cores of the main processor) (Section [0039], [0042], and Figs. 3A and 3B).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the HSM instances of Grubin to use multiple virtual HSM instances on a single physical HSM that are dedicated to only specific types of service requests, as taught by Anumulapally, in order to achieve the predictable result of easily scaling HSM resources while lowering costs (See Anumulapally paragraphs [0002]-[0004]).
Per claims 12 and 22, Grubin teaches:
receiving a service request by a hardware security module (HSM), wherein the service request is originated from an application running on a host (e.g. an HSM cluster client receiving a request from an application to perform a cryptographic operation. The application and the HSM cluster client are hosted on a client computer system, and the application submits the request to the HSM cluster client via an application programming interface exposed by the HSM cluster client) (Section [0071], [0072], [0075] and Fig. 6);
determining whether the service request is a first type of service request or a second type of service request (e.g. In some examples, the request is a request to encrypt information using a cryptographic key maintained by the HSM cluster. In other examples, the request is a request to decrypt information using a cryptographic key maintained by the HSM cluster. In yet another example, the request is a request to generate a cryptographic signature for a block of provided data. In yet another example, the request is a request to verify a cryptographic signature of a block of provided data) and (e.g. The HSM cluster client selects 604 a particular HSM in the HSM cluster to process the received request. The particular HSM may be selected based at least in part on the type of request submitted by the application, the current processing loads of the individual HSMs in the HSM cluster, the cryptographic processing capabilities of the individual HSMs in the HSM cluster, or preference information configured by an administrator) and (e.g. Using the HSM cluster API 312, the client application 308 may submit key-generation requests, key-deletion requests, key-modification requests, and key-use requests, to the HSM cluster. The requests are received by the HSM cluster API 312 and passed to the HSM cluster command service 314. The HSM cluster command service 314 uses client preferences 320 and HSM cluster data 322 to identify a target HSM for each request) (Section [0052, [0053], [0071], [0072], [0075] and Fig. 6);
sending the service request to a first HSM instance of the HSM in response to determining that the service request is the first type of service request (e.g. The HSM cluster client selects 604 a particular HSM in the HSM cluster to process the received request. The particular HSM may be selected based at least in part on the type of request submitted by the application, the current processing loads of the individual HSMs in the HSM cluster, the cryptographic processing capabilities of the individual HSMs in the HSM cluster, or preference information configured by an administrator) and (e.g. Using the HSM cluster API 312, the client application 308 may submit key-generation requests, key-deletion requests, key-modification requests, and key-use requests, to the HSM cluster. The requests are received by the HSM cluster API 312 and passed to the HSM cluster command service 314. The HSM cluster command service 314 uses client preferences 320 and HSM cluster data 322 to identify a target HSM for each request) (Section [0052], [0053], [0071], [0072], [0075] and Fig. 6);
sending the service request to a second HSM instance of the HSM in response to determining that the service request is the second type of service request (e.g. The HSM cluster client selects 604 a particular HSM in the HSM cluster to process the received request. The particular HSM may be selected based at least in part on the type of request submitted by the application, the current processing loads of the individual HSMs in the HSM cluster, the cryptographic processing capabilities of the individual HSMs in the HSM cluster, or preference information configured by an administrator) and (e.g. Using the HSM cluster API 312, the client application 308 may submit key-generation requests, key-deletion requests, key-modification requests, and key-use requests, to the HSM cluster. The requests are received by the HSM cluster API 312 and passed to the HSM cluster command service 314. The HSM cluster command service 314 uses client preferences 320 and HSM cluster data 322 to identify a target HSM for each request) (Section [0052], [0053], [0071], [0072], [0075] and Fig. 6).
Although Grubin teaches multiple HSM instances that are selected based on the type of service request, Grubin does not specifically teach:
wherein the first HSM instance and the second HSM instance are physically on the HSM, wherein the first HSM instance is logically separated from the second HSM instance, and wherein the first HSM instance is configured to process, for an application, only the first type of service requests and the second HSM instance is configured to process, for the application, only the second type of service requests.
However Anumulapally, in analogous art of HSM, discloses:
wherein the first HSM instance and the second HSM instance are physically on the HSM, wherein the first HSM instance is logically separated from the second HSM instance, and wherein the first HSM instance is configured to process, for an application, only the first type of service requests and the second HSM instance is configured to process, for the application, only the second type of service requests (e.g. Within the HSM 101 are two processors: a main processor 10, also referred to as a host, and a security processor 50, also referred to as a cryptographic co-processor. Here, the main processor 10 is virtualized to provide multiple virtual HSMs (vHSMs) each with their own HSM app 171 for handling cryptographic transactions 210 for multiple Crypto API Clients 156. A virtual HSM is a secure execution environment hosted on a physical HSM that provides specific cryptographic services. Each physical HSM would typically host multiple vHSMs depending on the available cryptographic capacity on the physical HSM. Each vHSM may provide specific services associated with a specific cryptographic application such as General Purpose Crypto or Payments Crypto application. Each vHSM is typically assigned/allocated specific set of CPU cores of the main processor) (Section [0039], [0042], and Figs. 3A and 3B).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the HSM instances of Grubin to use multiple virtual HSM instances on a single physical HSM that are dedicated to only specific types of service requests, as taught by Anumulapally, in order to achieve the predictable result of easily scaling HSM resources while lowering costs (See Anumulapally paragraphs [0002]-[0004]).
Per claims 2 and 13, Grubin/Anumulapally disclose all the limitations of claims 1 and 12 above. Anumulapally further discloses:
wherein the first HSM instance is configured to process for one or more additional applications, only the first type of service request (e.g. FIG. 3A is a block diagram 300 of multiple tenants (vHSMs) running on one HSM to handle crypto commands from one or more Crypto API Clients 156 individually leveraging hardware prioritization by way of a Class of Service (CoS) attribute 201 in accordance with an embodiment. Multi-tenant HSM architectures are gaining popularity with robust performance at lower costs to handle multiple clients within the same HSM. In a cloud deployment, a single HSM may support multiple client applications, which is known as multi-tenancy) and (e.g. Within the HSM 101 are two processors: a main processor 10, also referred to as a host, and a security processor 50, also referred to as a cryptographic co-processor. Here, the main processor 10 is virtualized to provide multiple virtual HSMs (vHSMs) each with their own HSM app 171 for handling cryptographic transactions 210 for multiple Crypto API Clients 156. A virtual HSM is a secure execution environment hosted on a physical HSM that provides specific cryptographic services. Each physical HSM would typically host multiple vHSMs depending on the available cryptographic capacity on the physical HSM. Each vHSM may provide specific services associated with a specific cryptographic application such as General Purpose Crypto or Payments Crypto application. Each vHSM is typically assigned/allocated specific set of CPU cores of the main processor) (Section [0038], [0039], [0042], and Figs. 3A and 3B).
The motivation to combine Anumulapally with Grubin is disclosed above with reference to claims 1, 12, and 22.
Per claims 3 and 14, Grubin/Anumulapally disclose all the limitations of claims 1 and 12 above. Anumulapally further discloses:
wherein the second HSM instance is configured to process, for one or more additional applications, only the second type of service request (e.g. FIG. 3A is a block diagram 300 of multiple tenants (vHSMs) running on one HSM to handle crypto commands from one or more Crypto API Clients 156 individually leveraging hardware prioritization by way of a Class of Service (CoS) attribute 201 in accordance with an embodiment. Multi-tenant HSM architectures are gaining popularity with robust performance at lower costs to handle multiple clients within the same HSM. In a cloud deployment, a single HSM may support multiple client applications, which is known as multi-tenancy) and (e.g. Within the HSM 101 are two processors: a main processor 10, also referred to as a host, and a security processor 50, also referred to as a cryptographic co-processor. Here, the main processor 10 is virtualized to provide multiple virtual HSMs (vHSMs) each with their own HSM app 171 for handling cryptographic transactions 210 for multiple Crypto API Clients 156. A virtual HSM is a secure execution environment hosted on a physical HSM that provides specific cryptographic services. Each physical HSM would typically host multiple vHSMs depending on the available cryptographic capacity on the physical HSM. Each vHSM may provide specific services associated with a specific cryptographic application such as General Purpose Crypto or Payments Crypto application. Each vHSM is typically assigned/allocated specific set of CPU cores of the main processor) (Section [0038], [0039], [0042], and Figs. 3A and 3B).
The motivation to combine Anumulapally with Grubin is disclosed above with reference to claims 1, 12, and 22.
Per claims 7 and 18, Grubin/Anumulapally disclose all the limitations of claims 1 and 12 above. Anumulapally further discloses:
wherein the HSM includes a first partition associated with the first HSM instance and a second partition associated with the second HSM instance (e.g. One direct benefit of an HSM that supports multi-tenancy is that one may create a virtual HSM as a partition for each virtual HSM guest that processes cryptographic traffic) (Section [0038], [0039], and Figs. 3A and 3B).
The motivation to combine Anumulapally with Grubin is disclosed above with reference to claims 1, 12, and 22.
Per claim 9, Grubin/Anumulapally disclose all the limitations of claim 1 above. Grubin further discloses:
further comprising a first handler associated with the first HSM instance and a second handler associated with the second HSM instance, wherein each handler is configured to process a request received from an application and a response to be sent to the application, and wherein the first handler is physically separate from the second handler (e.g. The HSM cluster 102 includes a first HSM 112, a second HSM 114, and a third HSM 116. The first HSM 112 is connected to a first HSM cluster server 118, the second HSM 114 is connected to a second HSM cluster server 120, and the third HSM 116 is connected to a third HSM cluster server 122) (Section [0037] and Fig. 1).
Per claims 10 and 21, Grubin/Anumulapally disclose all the limitations of claims 1 and 12 above. Grubin further discloses:
performing key management and cryptographical operations associated with the service request (e.g. The HSM cluster service 210 receives cryptographic requests from applications via HSM cluster clients, and relays the cryptographic requests to the network HSM 202. The cryptographic requests may be requests to create a new cryptographic key, requests to store a new cryptographic key, requests to delete a cryptographic key, requests to modify a particular cryptographic key, or requests to perform a cryptographic operation using a cryptographic key stored on the network HSM 201) (Section [0044]).
Per claim 11, Grubin/Anumulapally disclose all the limitations of claim 1 above. Grubin further discloses:
further comprising a first key store/HSM service module associated with the first HSM instance and a second key store/HSM service module associated with the second HSM instance, wherein each key store/HSM service module is configured for key management and cryptographical operations, and wherein the first key store/HSM service module is physically separate from the second key store/HSM service module (e.g. The HSM 502 retains cryptographic keys in a key store 508. The key store 508 maintains the cryptographic keys in non-exportable protected storage. The HSM 502 includes an HSM cluster agent 510, a cryptoprocessor 512, a cryptographic accelerator 514, an authentication service 516, and an authorization service 518. At the request of the HSM cluster server 504, the crypto processor 512 performs cryptographic operations using the cryptographic keys maintained in the key store 508) (Section [0068] and Fig. 5).
Claims 4-6, 8, and 15-17 are rejected under 35 U.S.C. 103 as being unpatentable over Grubin/Anumulapally, as applied to claims 1 and 12 above, in further view of US 20200320489 A1 (“Vagare”).
Per claims 4 and 15, Grubin/Anumulapally disclose all the limitations of claims 1 and 12 above. However Grubin/Anumulapally do not specifically disclose:
wherein the first type of service is at least one or more of encryption, decryption, sign and verify, key generation, hashing, key wrapping, auditing, authentication, and tamper protection.
However Vagare, in analogous art of HSM operations, discloses:
wherein the first type of service is at least one or more of encryption, decryption, sign and verify, key generation, hashing, key wrapping, auditing, authentication, and tamper protection (e.g. Examples of the cryptographic operations include, such as but not limited to, a Personal Identification Number (PIN) verification, a Card Verification Value (CVV) verification, an Authorization Response Code (ARC) verification, an Authorization Response Cryptogram (ARPC) generation, an Authorization Request Cryptogram (ARQC) validation, a PIN translation and testing one or more complex cryptographic functionalities of the HSM as a tester tool) (Section [0032] and [0033]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the HSM operations of Grubin/Anumulapally to include various verification/authentication functions, as taught by Vagare, in order to achieve the predictable result of increasing security for multiple processes such as electronic payments.
Per claims 5 and 16, Grubin/Anumulapally disclose all the limitations of claims 1 and 12 above. However Grubin/Anumulapally do not specifically disclose:
wherein the second type of service is a cryptographical operation associated with payment.
However Vagare, in analogous art of HSM operations, discloses:
wherein the second type of service is a cryptographical operation associated with payment (e.g. Examples of the cryptographic operations include, such as but not limited to, a Personal Identification Number (PIN) verification, a Card Verification Value (CVV) verification, an Authorization Response Code (ARC) verification, an Authorization Response Cryptogram (ARPC) generation, an Authorization Request Cryptogram (ARQC) validation, a PIN translation and testing one or more complex cryptographic functionalities of the HSM as a tester tool) (Section [0032] and [0033]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the HSM operations of Grubin/Anumulapally to include various verification/authentication functions, as taught by Vagare, in order to achieve the predictable result of increasing security for multiple processes such as electronic payments.
Per claims 6 and 17, Grubin/Anumulapally/Vagare disclose all the limitations of claims 5 and 16 above. Vagare further discloses:
wherein the cryptographical operation is at least one or more of pin translation, euro master visa (EMV) operation, a code verification value (CVV) generation and verification, and a derive unique key per transaction (DUKPT) operation (e.g. Examples of the cryptographic operations include, such as but not limited to, a Personal Identification Number (PIN) verification, a Card Verification Value (CVV) verification, an Authorization Response Code (ARC) verification, an Authorization Response Cryptogram (ARPC) generation, an Authorization Request Cryptogram (ARQC) validation, a PIN translation and testing one or more complex cryptographic functionalities of the HSM as a tester tool) (Section [0032] and [0033]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the HSM operations of Grubin/Anumulapally to include various verification/authentication functions, as taught by Vagare, in order to achieve the predictable result of increasing security for multiple processes such as electronic payments.
Per claim 8, Grubin/Anumulapally disclose all the limitations of claim 1 above. However Grubin/Anumulapally do not specifically disclose:
further comprising a handler configured to process a request received from an application and a response to be sent to the application.
However Vagare, in analogous art of HSM operations, discloses:
further comprising a handler configured to process a request received from an application and a response to be sent to the application (e.g. In one embodiment, the server system is configured to generate a cryptographic operation command for the cryptographic operation. The cryptographic operation command is sent to a corresponding Hardware Security Module (HSM) communicatively connected to microservice core engine of the server system to perform the cryptographic operation. There may be present a plurality of HSMs or a cloud based HSM with one or more partitions of which all are allocated to each customer application, and are identified using the HSM LMK identifier received in the cryptographic service request. The cryptographic operation is performed by the dedicated HSM using the cryptographic keys either fetched from server system database or received from the application. The HSM is configured to send a response for the performed cryptographic operation to the server system. The server system, in turn, is configured to send the response for the performed cryptographic operation to the calling application) (Section [0035], [0057], [0060], and [0061]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the HSM operations of Grubin/Anumulapally to include a handler for the cryptographic operation requests and responses, as taught by Vagare, in order to achieve the predictable result of reducing computing requirements of the HSM so that they can focus their resources on only the cryptographic operations.
Claims 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Grubin/Anumulapally, as applied to claim 12 above, in further view of US 20220393857 A1 (“Anand”).
Per claim 19, Grubin/Anumulapally disclose all the limitations of claim 12 above. However Grubin/Anumulapally do not specifically disclose:
parsing the received service request to determine a type of service request based on a class portion of the received service request.
However Anand, in analogous art of HSM operations, discloses:
parsing the received service request to determine a type of service request based on a class portion of the received service request (e.g. The KMS logic parses the request to verify authorization for the request, identify the instance ID, and provide additional information to the request needed by hardware security module (HSM) middleware and hardware) (Section [0014] and [0040]).
It would have been obvious to one of ordinary skill in the art as of the effective filing date of the claimed invention to modify the HSM operation process of Grubin/Anumulapally to include the parsing of the operation request to determine a type, as taught by Anand, in order to achieve the predictable result of making it easier to identify the HSM instance that should perform the cryptographic operation.
Per claim 20, Grubin/Anumulapally disclose all the limitations of claim 12 above. However Grubin/Anumulapally do not specifically disclose:
parsing the received service request to determine a type of service requests based on an opcode of the received service request, wherein the opcode identifies cryptographical operation to be performed.
However Anand, in analogous art of HSM operations, discloses:
parsing the received service request to determine a type of service requests based on an opcode of the received service request, wherein the opcode identifies cryptographical operation to be performed (e.g. When a client service request is received, the HSM middleware receiving the request parses request metadata indicating a particular HSM requested by the client and associates the request with a translation module for converting the request to a language the HSM can receive and act upon) (Section [0014] and [0040]).
The motivation to combine Anand with Grubin/Anumulapally is disclosed above with reference to claim 19.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
WO 2015069460 A1 to Seaborn teaches a system and method that generates multiple vHSM instances on a single HSM to perform cryptographic functions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIMOTHY P SAX whose telephone number is (571) 272-2935. The examiner can normally be reached on M-F 8-4:30.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/TIMOTHY PAUL SAX/Examiner, Art Unit 3698
Prosecution Insights