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 1/22/2026.
Claims
Claims 1, 12, and 22 have been amended.
Claims 1-22 are currently pending in the application.
Response to Arguments
112
The examiner withdraws the previous 112(b) rejections due to the claim amendments.
101
The applicant argues that claims 12-22 do not recite an abstract idea but are rather directed to address a problem arising from computer-related technology (see applicant’s arguments/remarks pages 6 and 7. However the examiner respectfully disagrees. Claim 12 recites the abstract idea of receiving a service request and then sending the service request to a certain entity based on the type of the service request. This is an abstract idea that can be performed by humans outside of the technology.
Further the applicant argues that Claim 12 is integrated into a practical application because the claimed features are inextricably intertwined with and necessarily rooted in computer technology (See applicant’s arguments/remarks pages 7 and 8). However the examiner respectfully disagrees. The abstract idea, as recited above, can be performed outside of computer technology. Further, the improvement to technology must be provided by one or more additional elements in the claim or by the additional elements in combination with the recited judicial exception. The recited additional elements in the claim include the HSM and HSM instances which is nothing more than using a computer as a tool to perform the abstract idea and generally linking the abstract idea to a particular technological environment.
The examiner has considered all of the applicant’s arguments but maintains the 101 rejection.
103
The applicant argues that Grubin/Seaborn fail to disclose the limitations of claim 1 because modifying the teachings of Grubin with that of Seaborn results in multiple HSMs, where each HSM has multiple segments to accommodate separate administrator accounts (See applicant’s arguments/remarks pages 8-11). However the examiner respectfully disagrees. Grubin discloses that multiple physical HSMs can be used and that each physical HSM is used based on the request received. Seaborn is used to disclose that a single HSM can be used to generate multiple virtual HSM instances that are logically separated on the physical HSM. Just because Seaborn discloses that there are multiple physical HSM, each with their own multiple instances of virtual HSM, this does not teach away from disclosing that the physical HSM can contain multiple instances of virtual HSMs. One of ordinary skill in the art would find it obvious to use the multiple virtual HSMs on a single physical HSM (as disclosed by Seaborn) instead of the multiple physical HSMs in Grubin in order to offer easier scalability and cost effectiveness.
Further, the applicant argues that Seaborn discloses multiple segments formed within a single HSM, but fails to teach or suggest that the instances of the HSM are logically separated in the claimed fashion (see applicant’s arguments/remarks page 12). However the examiner respectfully disagrees. Seaborn discloses in section [0016] that multiple segments called Virtual HSMs (VHSMs) are created from one HSM. A cloud administrator account may allocate HSM resources such as storage to an administrator account. The resources allocated to an administrator account and the corresponding access control rules for that account are referred to as a segment or partition of the HSM, or as a VHSM 108. Since each VHSM is referred to as a partition of the HSM, it teaches that the various VHSMs are logically separated from each other since partitions refer to logically distinct sections. Therefore it teaches the limitation as written.
The examiner has considered all of the applicant’s arguments but maintains the 103 rejection.
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] 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 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.
The specification in section [0023] 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 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.
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 and second HSM instances, and the first HSM instance and second HSM instance being physically on the HSM, and wherein the first HSM instance is logically separated from the second HSM instance is generally linking the use of the judicial exception to a particular technological environment (e.g. secure computer/network) 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 the use of application running on a host, HSM, first and second HSM instances, and the first HSM instance and second HSM instance being physically on the HSM, and wherein the first HSM instance is logically separated from the second HSM instance is generally linking the use of the judicial exception to a particular technological environment (e.g. secure computer/network) 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, 7, 9-12, 18, 21, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over US 20190238333 A1 (“Grubin”) and WO 2015069460 A1 (“Seaborn”).
Per claim 1, Grubin teaches:
a first HSM instance configured to process 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) (Section [0071], [0072], [0075] and Fig. 1);
a second HSM instance configured to process 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) (Section [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, Grubin does not specifically teach:
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 Seaborn, in analogous art of HSM, discloses:
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. In an embodiment, multiple segments called Virtual HSMs (VHSMs) 108 (i.e., VHSMs 108a-108g and 108a-l) are created from one HSM 106 (e.g., VHSMs 108a-108d with respect to HSM 106a, VHSMs 108e-108g with respect to HSM 106b, and VHSM 108a-l with respect to HSM 106n), where each segment may be administered by a separate administrator account. A cloud administrator account may allocate HSM resources such as storage to an administrator account. The resources allocated to an administrator account and the corresponding access control rules for that account are referred to as a segment or partition of the HSM, or as a VHSM 108) (Section [0016], [0017], and Fig. 3A).
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, as taught by Seaborn, in order to achieve the predictable result of easily scaling HSM resources while lowering costs (See Seaborn paragraphs [0001] and [0002]).
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) (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) (Section [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) (Section [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) (Section [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, and wherein the first HSM instance is logically separated from the second HSM instance.
However Seaborn, in analogous art of HSM, discloses:
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. In an embodiment, multiple segments called Virtual HSMs (VHSMs) 108 (i.e., VHSMs 108a-108g and 108a-l) are created from one HSM 106 (e.g., VHSMs 108a-108d with respect to HSM 106a, VHSMs 108e-108g with respect to HSM 106b, and VHSM 108a-l with respect to HSM 106n), where each segment may be administered by a separate administrator account. A cloud administrator account may allocate HSM resources such as storage to an administrator account. The resources allocated to an administrator account and the corresponding access control rules for that account are referred to as a segment or partition of the HSM, or as a VHSM 108) (Section [0016], [0017], and Fig. 3A).
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, as taught by Seaborn, in order to achieve the predictable result of easily scaling HSM resources while lowering costs (See Seaborn paragraphs [0001] and [0002]).
Per claims 7 and 18, Grubin/Seaborn disclose all the limitations of claims 1 and 12 above. Seaborn 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. In an embodiment, multiple segments called Virtual HSMs (VHSMs) 108 (i.e., VHSMs 108a-108g and 108a-l) are created from one HSM 106 (e.g., VHSMs 108a-108d with respect to HSM 106a, VHSMs 108e-108g with respect to HSM 106b, and VHSM 108a-l with respect to HSM 106n), where each segment may be administered by a separate administrator account) (Section [0016], [0017], and Fig. 3A).
The motivation to combine Seaborn with Grubin is disclosed above with reference to claims 1, 12, and 22.
Per claim 9, Grubin/Seaborn 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/Seaborn 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/Seaborn 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 2-6, 8, and 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over Grubin/Seaborn, as applied to claims 1 and 12 above, in further view of US 20200320489 A1 (“Vagare”).
Per claims 2 and 13, Grubin/Seaborn disclose all the limitations of claims 1 and 12 above. However Grubin/Seaborn do not specifically disclose:
wherein the first HSM instance is configured to only process the first type of service request.
However Vagare, in analogous art of HSM operations, discloses:
wherein the first HSM instance is configured to only process the first type of service request (e.g. At 906, the method includes performing, by the at least one HSM of the one or more HSMs, the cryptographic operation, and sending a response for the performed cryptographic operation to the microservice core engine. In an example embodiment, one of the HSMs may include multiple partitions such that each HSM partition is dedicated to support one of the application servers/applications to offload their cryptographic operations) (Section [0035] and [0097]).
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/Seaborn to be dedicated to performing cryptographic operations for one specific entity, as taught by Vagare, in order to achieve the predictable result of more easily load balancing resources based on how much a specific entity requires cryptographic operations.
Per claims 3 and 14, Grubin/Seaborn disclose all the limitations of claims 1 and 12 above. However Grubin/Seaborn do not specifically disclose:
wherein the second HSM instance is configured to only process the second type of service request.
However Vagare, in analogous art of HSM operations, discloses:
wherein the second HSM instance is configured to only process the second type of service request (e.g. At 906, the method includes performing, by the at least one HSM of the one or more HSMs, the cryptographic operation, and sending a response for the performed cryptographic operation to the microservice core engine. In an example embodiment, one of the HSMs may include multiple partitions such that each HSM partition is dedicated to support one of the application servers/applications to offload their cryptographic operations) (Section [0035] and [0097]).
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/Seaborn to be dedicated to performing cryptographic operations for one specific entity, as taught by Vagare, in order to achieve the predictable result of more easily load balancing resources based on how much a specific entity requires cryptographic operations.
Per claims 4 and 15, Grubin/Seaborn disclose all the limitations of claims 1 and 12 above. However Grubin/Seaborn 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/Seaborn 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/Seaborn disclose all the limitations of claims 1 and 12 above. However Grubin/Seaborn 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/Seaborn 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/Seaborn/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/Seaborn 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/Seaborn disclose all the limitations of claim 1 above. However Grubin/Seaborn 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/Seaborn 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/Seaborn, as applied to claim 12 above, in further view of US 20220393857 A1 (“Anand”).
Per claim 19, Grubin/Seaborn disclose all the limitations of claim 12 above. However Grubin/Seaborn 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/Seaborn 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/Seaborn disclose all the limitations of claim 12 above. However Grubin/Seaborn 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/Seaborn is disclosed above with reference to claim 19.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry of a general nature or relating to the status of this application or concerning this communication or earlier communications from the Examiner should be directed to TIMOTHY SAX whose telephone number is 571-272-2935. The Examiner can normally be reached on M-F 8-4:30. If attempts to reach the examiner by telephone are unsuccessful, the Examiner’s supervisor, Patrick McAtee can be reached at (571) 272-7575.
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.
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.
/TPS/
Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698