DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the amendment filed 09/24/2025.
Claims 1, 4-5, 7-8, 13, 19, 22-23, 25-26, 31, and 37-38 have been amended. Claims 1-38 are pending and have been examined on the merits (claims 1, 19, 38, and 38 being independent).
The amendment filed 09/24/2025 to the claims has been entered.
Response to Arguments
Applicant’s arguments and amendments filed 09/24/2025 have been fully considered.
This Office Action is a second Non-Final Action in reply to the amendment filed 09/24/2025.
Applicant’s argument and amendments are considered for the rejections under 35 U.S.C. 101, and are found persuasive (see Applicant’s arguments, pages 12-13). As such, the rejections under 35 U.S.C. 101 are withdrawn.
With regard to the rejections of claims 1-38 under 35 U.S.C. 103, Applicant’s arguments and amendments have been considered but are moot a new ground of rejection has been added. As noted in the citation above the prior art and it is addressed by the rejections under 35 USC 103.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: a “multipay HSM module” in claim 1.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim limitation “multipay HSM module” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. Since the specification fails to sufficiently disclose the module to perform the claimed function in view of what one of ordinary skill in the art would understand, the claim is indefinite under 112(b) (see MPEP 2181.II.B) because the metes and bounds of the limitation cannot be determined. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
Dependent claims (2-18) stand rejected also, under 35 U.S.C. 112(b) by virtue of their dependency on a rejected claim.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
In the rejections below, where claims are currently amended, this is indicated by underlining.
Claims 1-38 are rejected under 35 U.S.C. 103 as being unpatentable over Batra et al. (hereinafter Batra), US Publication Number 2021/0065142 A1 in view of Anumulapally et al. (hereinafter Anumulapally), US Publication Number 2022/0391856 A1 in further view of Kubler et al. (hereinafter Kubler), US Publication Number 2021/0398142 A1.
Regarding claim 1:
Batra discloses the following:
A system comprising: (Batra: See abstract)
a multiPayHSM module configured to transform an input request (reads on “transforming, at the particular payment gateway adapter, the payment request into a gateway specific format of the particular payment gateway to generate a transformed payment request”), sourced by an application, into a transformed request interpretable by a target payment hardware system module (HSM), the application integrated, currently, with a current payment HSM, the current payment HSM different from the target payment HSM (reads on “different payment gateway 140-1… 140-N”), the input request uninterpretable by the target payment HSM, (Batra: See paragraph [0056] “wherein the particular payment gateway adapter corresponds to a particular payment gateway of a plurality of payment gateways; transforming, at the particular payment gateway adapter, the payment request into a gateway specific format of the particular payment gateway to generate a transformed payment request”, and see also [0074])
the multiPayHSM module further configured to transmit (reads on “calling the payment gateway via the particular payment gateway adapter to send the transformed payment request to the payment gateway. The particular payment gateway, when executed by a second hardware-based processing system, is configurable to cause receiving the transformed payment request”) the transformed request to the target payment HSM for processing. (Batra: See paragraph [0056])
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043])
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 payment platform module that has a pluggable architecture for integrating each of the payment gateway adapters of the plurality of payment gateways with the cloud computing platform so that the clients and customers of clients are able to perform payment transactions using the payment gateways via the payments platform module of the cloud computing platform of Batra to include the payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications, as taught by Anumulapally, in order to obtain a high level of security for the payment transaction. (See Anumulapally [0004-0006])
Batra and Anumulapally do not explicitly disclose following, however Kubler further teaches:
the input request based on a current application-specific programming interface (API) of the current payment HSM, the current API different from a target API of the target HSM, (Kubler: See paragraphs [0067] “input data have been input at one device ( e.g., user device 150) and sent to another device (e.g., device 100). In some embodiments, the input data may be configured for a first application program interface (API) and/or may have been entered at the user device in response to the transmitted data. For example, input data may be received from a user device 150 in response to information related to a potentially anomalous transaction, which may have been displayed at the user device. In some embodiments, the input data may be configured in a first API format, such REST or SOAP, and process 400 may translate input data to a second API format.” and [0071] “process 400 may generate dispute data, which may be based on received input and/or may be configured for an API (which may be a second API with respect to a first API for which data was configured at another step in process 400).”, and see also [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 payment platform module that has a pluggable architecture for integrating each of the payment gateway adapters of the plurality of payment gateways with the cloud computing platform so that the clients and customers of clients are able to perform payment transactions using the payment gateways via the payments platform module of the cloud computing platform of Batra to include data that may be formatted or translated when being sent from one application programming interface (API) to another, to allow for seamless connection between systems, such as a user device application using one API and a dispute resolution system using another API, as taught by Kubler, in order to allow for seamless connection between systems for processing. (See Kubler [0002-0006])
Regarding claim 2:
Batra discloses the following:
The system of Claim 1, wherein the target payment HSM and the current payment HSM are cloud payment hardware system modules (HSMs) in a cloud environment and wherein the system is located in the cloud environment. (Batra: See paragraph [0036] “The cloud-based computing system can include a plurality of payment gateways that include a particular payment gateway, and a cloud computing platform. Each payment gateway is an application service provider that provides a payment gateway adapter configured for different payment gateway functionality. The payment gateway adapters include a particular payment gateway adapter provided by the particular payment gateway.”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 3:
Batra discloses the following:
The system of Claim 1, wherein the multiPayHSM module is coupled to a plurality of applications, wherein the multiPayHSM module is coupled to a plurality of payment hardware system modules (HSMs), wherein the plurality of applications includes the application, and wherein the plurality of payment HSMs includes the target payment HSM. (Batra: See paragraph [0036] “Each payment gateway is an application service provider that provides a payment gateway adapter configured for different payment gateway functionality. The payment gateway adapters include a particular payment gateway adapter provided by the particular payment gateway. The cloud computing platform can include a multitenant database system and a payments platform module. The multitenant database system is configurable to provide applications and services to a plurality of clients… The payments platform module has a pluggable architecture for integrating each of the payment gateway adapters of the plurality of payment gateways with the cloud computing platform so that the clients and customers of clients are able to perform payment transactions using the payment gateways via the payments platform module of the cloud computing platform.”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 4:
Batra discloses the following:
The system of Claim 1, wherein the application lacks support for the target API of the target payment HSM and wherein the application is configured to communicate with the current payment HSM via the current API of the current payment HSM. (Batra: See paragraph [0086] “The payments platform 126 exposes payment gate way client APIs 212 to clients 110. The payment gateway client APIs 212 are a unified set of APIs that clients 110 (e.g., ISVs/Partners) can use to build integration and interact with the various different payment gateways 140….This provides a huge advantage because clients 110 of the payments platform 126 do not have to understand and interact with multiple APIs for different payment gateways 140.”, and see also [0090])
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 5:
Batra discloses the following:
The system of Claim 1, wherein the transformed request is based on the target API of the target payment HSM. (Batra: See paragraph [0090] “The APEX® payment gateway adapter APIs 216 serve as bridge between the APEX® payment gateway integration layer 214 and the payment gateway adapter 130-X. The APEX® payment gateway integration layer 214 and the payment gateway adapter 130-X interact with each other using the APEX® payment gateway adapter APIs 216.”, and see also [0089])
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 6:
Batra discloses the following:
The system of Claim 1, wherein the multiPayHSM module is further configured to:
transform an input response into a transformed response interpretable by the application, wherein the input response is sourced by the target payment HSM responsive to the processing of the transformed request, and wherein the input response is uninterpretable by the application; and (Batra: See paragraph [0056] “forwarding the actual payment response to the particular payment gateway adapter; transforming, at the particular payment gateway adapter, the actual payment response into a specific format used by the payments platform to generate a transformed payment response”)
transmit the transformed response to the application for processing. (Batra: See paragraph [0056] “sending the transformed payment response from the payment gateway adapter to the payments platform; and persisting data from the transformed payment response in a payment record at the multitenant database system of the cloud computing platform.”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 7:
Batra discloses the following:
The system of Claim 6, wherein the transformed response is based on the current API of the current payment HSM and wherein the input response is based on the target API of the target payment HSM. (Batra: See paragraph [0086] “payment gateway client APIs 212 can include REST/SOAP/APEX® APIs that can be exposed to the clients 110 to call from flows, process builders, customer code, etc., whereas the APEX® payment gateway adapter APIs 216 are APEX® APIs. For instance, a client 110 can use a REST APIs for a sale call even though underneath the cover the payment provider supports SOAP APIs. This provides a huge advantage because clients 110 of the payments platform 126 do not have to understand and interact with multiple APIs for different payment gateways 140.”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 8:
Batra discloses the following:
The system of Claim 1, wherein the transformed request is based on the target API of the target payment HSM, wherein the multiPayHSM module includes at least one application-communications converter and at least one HSM-communications converter, and wherein: (Batra: See paragraph [0090] “The APEX® payment gateway adapter APIs 216 serve as bridge between the APEX® payment gateway integration layer 214 and the payment gateway adapter 130-X. The APEX® payment gateway integration layer 214 and the payment gateway adapter 130-X interact with each other using the APEX® payment gateway adapter APIs 216.”, and see also [0089])
an application-communications converter of the at least one application- communications converter is configured to convert the input request into API data produced in a common format by decoding the input request based on the current API; and (Batra: See paragraph [0089] “the payment gateway integration layer 214 can also initialize and load an APEX® adapter class based on the configuration provided in the payment request, convert the payment request to appropriate APEX® API specific format, execute the APEX® adapter, receive the APEX® response, and convert the APEX® response to gateway response and return the response.”)
a payment-HSM-communications converter of the at least one payment-HSM- communications converter is configured to produce the transformed request by encoding the API data produced in the common format and wherein the encoding is based on the target API. (Batra: See paragraph [0089] “the payment gateway integration layer 214 can also initialize and load an APEX® adapter class based on the configuration provided in the payment request, convert the payment request to appropriate APEX® API specific format, execute the APEX® adapter, receive the APEX® response, and convert the APEX® response to gateway response and return the response.”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 9:
Batra discloses the following:
The system of Claim 8, wherein the API data is API-request data, wherein the multiPayHSM module is further configured to transform an input response into a transformed response interpretable by the application, wherein the input response is sourced by the target payment HSM responsive to the processing of the transformed request, wherein the input response is uninterpretable by the application, wherein the multiPayHSM module is further configured to transmit the transformed response to the application for processing, and wherein: (Batra: See paragraph [0089] “the payment gateway integration layer 214 can also initialize an adapter specific environment, convert the payment request to appropriate adapter specific format, call the adapter, convert the adapter specific response to payment platform specific response (or "gateway response"), return the response, etc. For instance, in one implementation, the payment gateway integration layer 214 can also initialize and load an APEX® adapter class based on the configuration provided in the payment request, convert the payment request to appropriate APEX® API specific format, execute the APEX® adapter, receive the APEX® response, and convert the APEX® response to gateway response and return the response.”)
the HSM-communications converter is further configured to convert the input response into API-response data produced in the common format by decoding the input response based on the target API; and (Batra: See paragraph [0089] “the payment gateway integration layer 214 can also initialize and load an APEX® adapter class based on the configuration provided in the payment request, convert the payment request to appropriate APEX® API specific format, execute the APEX® adapter, receive the APEX® response, and convert the APEX® response to gateway response and return the response.”)
the application-communications converter is further configured to produce the transformed response by encoding the API-response data produced in the common format, wherein the encoding is based on the current API. (Batra: See paragraph [0089] “the payment gateway integration layer 214 can also initialize and load an APEX® adapter class based on the configuration provided in the payment request, convert the payment request to appropriate APEX® API specific format, execute the APEX® adapter, receive the APEX® response, and convert the APEX® response to gateway response and return the response.”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 10:
Batra discloses the following:
The system of Claim 1, wherein, in a setup phase, the application is configured to:
select the current payment HSM from a plurality of payment HSMs coupled to the multiPayHSM module, the current payment HSM selected as an integrated payment HSM that is supported by the application, currently, via integration of the application with a current HSM API of the current payment HSM; and (Batra: See paragraph [0092] “The payments platform 126 can then execute one of the payment gateway adapters that have been selected by a client to implement the set of APEX® payment gateway adapter APIs 216 so that APIs of particular payment gateway service 140 can be translated into the payment gateway client APIs 212 (APIs of the cloud computing platform 102). In other words, each payment gateway adapter 13 0 translates APIs of a particular payment gateway service into the APIs of the cloud computing platform 102 so that they are compatible.”)
select the target payment HSM from the plurality of payment HSMs, the target payment HSM selected for communicating with the application in a runtime phase, wherein the application lacks support for communicating with the target payment HSM selected. (Batra: See paragraph [0092] “The payments platform 126 can then execute one of the payment gateway adapters that have been selected by a client to implement the set of APEX® payment gateway adapter APIs 216 so that APIs of particular payment gateway service 140 can be translated into the payment gateway client APIs 212 (APIs of the cloud computing platform 102). In other words, each payment gateway adapter 13 0 translates APIs of a particular payment gateway service into the APIs of the cloud computing platform 102 so that they are compatible.”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 11:
Batra discloses the following:
The system of Claim 1, wherein the application is configured to switch from communicating with the current payment HSM in a runtime phase to communicating with the target payment HSM by selecting, in a setup phase, the current payment HSM and the target payment HSM and wherein, in the setup phase, the multiPayHSM module is further configured to configure converter setup information of the multiPayHSM module to effectuate switching of the communicating. (Batra: See paragraph [0086] “payment gateway client APIs 212 can include REST/SOAP/APEX® APIs that can be exposed to the clients 110 to call from flows, process builders, customer code, etc., whereas the APEX® payment gateway adapter APIs 216 are APEX® APIs. For instance, a client 110 can use a REST APIs for a sale call even though underneath the cover the payment provider supports SOAP APIs. This provides a huge advantage because clients 110 of the payments platform 126 do not have to understand and interact with multiple APIs for different payment gateways 140.”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 12:
Batra discloses the following:
The system of Claim 1, wherein:
in a setup phase of the system, the application is further configured to select the current payment HSM and the target payment HSM; and (Batra: See paragraph [0086] “payment gateway client APIs 212 can include REST/SOAP/APEX® APIs that can be exposed to the clients 110 to call from flows, process builders, customer code, etc., whereas the APEX® payment gateway adapter APIs 216 are APEX® APIs. For instance, a client 110 can use a REST APIs for a sale call even though underneath the cover the payment provider supports SOAP APIs. This provides a huge advantage because clients 110 of the payments platform 126 do not have to understand and interact with multiple APIs for different payment gateways 140.”)
in the setup phase, the multiPayHSM module is further configured to configure converter setup information of the multiPayHSM module based on the current payment HSM selected and the target HSM selected by the application. (Batra: See paragraph [0086] “payment gateway client APIs 212 can include REST/SOAP/APEX® APIs that can be exposed to the clients 110 to call from flows, process builders, customer code, etc., whereas the APEX® payment gateway adapter APIs 216 are APEX® APIs. For instance, a client 110 can use a REST APIs for a sale call even though underneath the cover the payment provider supports SOAP APIs. This provides a huge advantage because clients 110 of the payments platform 126 do not have to understand and interact with multiple APIs for different payment gateways 140.”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 13:
Batra discloses the following:
The system of Claim 12, wherein the transformed request is based on the target API of the target payment HSM, wherein the multiPayHSM module includes at least one application-communications converter and at least one HSM-communications converter, and wherein, in a runtime phase, the multiPayHSM module is further configured to: (Batra: See paragraph [0086] “payment gateway client APIs 212 can include REST/SOAP/APEX® APIs that can be exposed to the clients 110 to call from flows, process builders, customer code, etc., whereas the APEX® payment gateway adapter APIs 216 are APEX® APIs. For instance, a client 110 can use a REST APIs for a sale call even though underneath the cover the payment provider supports SOAP APIs. This provides a huge advantage because clients 110 of the payments platform 126 do not have to understand and interact with multiple APIs for different payment gateways 140.”)
employ an application-communications converter of the at least one application- communications converter based on the converter setup information configured, wherein the application-communications converter is configured to convert the input request received from the application into API data produced in a common format by decoding the input request based on the current API; and (Batra: See paragraph [0089] “the payment gateway integration layer 214 can also initialize and load an APEX® adapter class based on the configuration provided in the payment request, convert the payment request to appropriate APEX® API specific format, execute the APEX® adapter, receive the APEX® response, and convert the APEX® response to gateway response and return the response.”)
employ a HSM-communications converter of the at least one HSM- communications converter based on the converter setup information configured and wherein the HSM-communications converter is configured to produce the transformed request by encoding the API data in accordance with the target API. (Batra: See paragraph [0089] “the payment gateway integration layer 214 can also initialize and load an APEX® adapter class based on the configuration provided in the payment request, convert the payment request to appropriate APEX® API specific format, execute the APEX® adapter, receive the APEX® response, and convert the APEX® response to gateway response and return the response.”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 14:
Batra discloses the following:
The system of Claim 13, wherein the API data is request-API data and wherein, in the runtime phase, the multiPayHSM module is further configured to:
transform an input response into a transformed response interpretable by the application, wherein the input response is sourced by the target payment HSM responsive to the processing of the transformed request, wherein the input response is uninterpretable by the application, and wherein, to transform the input response, the multiPayHSM module is further configured to: (Batra: See paragraph [0056] “forwarding the actual payment response to the particular payment gateway adapter; transforming, at the particular payment gateway adapter, the actual payment response into a specific format used by the payments platform to generate a transformed payment response”)
employ the HSM-communications converter to convert the input response into response-API data produced in the common format by decoding the input response based on the target API; and (Batra: See paragraph [0089] “the payment gateway integration layer 214 can also initialize and load an APEX® adapter class based on the configuration provided in the payment request, convert the payment request to appropriate APEX® API specific format, execute the APEX® adapter, receive the APEX® response, and convert the APEX® response to gateway response and return the response.”)
employ the application-communications converter to produce the transformed response by encoding the response-API data in accordance with the current API; and transmit the transformed response to the application for processing. (Batra: See paragraph [0089] “the payment gateway integration layer 214 can also initialize and load an APEX® adapter class based on the configuration provided in the payment request, convert the payment request to appropriate APEX® API specific format, execute the APEX® adapter, receive the APEX® response, and convert the APEX® response to gateway response and return the response.”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 15:
Batra discloses the following:
The system of Claim 1, wherein the multiPayHSM module is further configured to transform the input request in a runtime phase and wherein, in an event the application selects, in a setup phase, the current payment HSM and the target payment HSM for communication in the runtime phase, the multiPayHSM module is further configured to: (Batra: See paragraph [0056] “wherein the particular payment gateway adapter corresponds to a particular payment gateway of a plurality of payment gateways; transforming, at the particular payment gateway adapter, the payment request into a gateway specific format of the particular payment gateway to generate a transformed payment request”, and see also [0074])
transmit, in the runtime phase, the input request sourced by the application to the current payment HSM, unaltered. (Batra: See paragraph [0056] “calling the payment gateway via the particular payment gateway adapter to send the transformed payment request to the payment gateway. The particular payment gateway, when executed by a second hardware-based processing system, is configurable to cause receiving the transformed payment request”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 16:
Batra discloses the following:
The system of Claim 15, wherein the multiPayHSM module is further configured to:
transform, in the runtime phase, a first input response into a transformed response interpretable by the application, wherein the first input response is sourced by the target payment HSM responsive to the processing of the transformed request; (Batra: See paragraph [0056] “transforming, at the particular payment gateway adapter, the actual payment response into a specific format used by the payments platform to generate a transformed payment response”)
transmit the transformed response to the application for processing; and (Batra: See paragraph [0056] “forwarding the actual payment response to the particular payment gateway adapter”)
transmit a second input response, sourced by the current payment HSM responsive to the processing of the input request, to the application, unaltered, for processing. (Batra: See paragraph [0056] “sending the transformed payment response from the payment gateway adapter to the payments platform; and persisting data from the transformed payment response in a payment record at the multitenant database system of the cloud computing platform.”)
Batra does not explicitly disclose the term of “payment hardware system module (HSM)”, however Anumulapally further teaches the use of payment hardware security module (HSM) that uses third party APIs to communicate with payment servers and interfaces allowing payment HSM to interact with payment applications (Anumulapally: see paragraphs [0014-0019] and [0043]). The motivation to combine is same as above.
Regarding claim 17:
Batra discloses the following:
The system of Claim 1, wherein the system is a cloud-based system. (Batra: See paragraph [0041])
Regarding claim 18:
Batra discloses the following:
The system of Claim 1, wherein the system is implemented on an integrated circuit (IC) chip. (Batra: See paragraph [0234])
Regarding claims 19 and 37-38: it is similar scope to claim 1, and thus it is rejected under similar rationale.
Regarding claim 20: it is similar scope to claim 2, and thus it is rejected under similar rationale.
Regarding claim 21: it is similar scope to claim 3, and thus it is rejected under similar rationale.
Regarding claim 22: it is similar scope to claim 4, and thus it is rejected under similar rationale.
Regarding claim 23: it is similar scope to claim 5, and thus it is rejected under similar rationale.
Regarding claim 24: it is similar scope to claim 6, and thus it is rejected under similar rationale.
Regarding claim 25: it is similar scope to claim 7, and thus it is rejected under similar rationale.
Regarding claim 26: it is similar scope to claim 8, and thus it is rejected under similar rationale.
Regarding claim 27: it is similar scope to claim 9, and thus it is rejected under similar rationale.
Regarding claim 28: it is similar scope to claim 10, and thus it is rejected under similar rationale.
Regarding claim 29: it is similar scope to claim 11, and thus it is rejected under similar rationale.
Regarding claim 30: it is similar scope to claim 12, and thus it is rejected under similar rationale.
Regarding claim 31: it is similar scope to claim 13, and thus it is rejected under similar rationale.
Regarding claim 32: it is similar scope to claim 14, and thus it is rejected under similar rationale.
Regarding claim 33: it is similar scope to claim 15, and thus it is rejected under similar rationale.
Regarding claim 34: it is similar scope to claim 16, and thus it is rejected under similar rationale.
Regarding claim 35: it is similar scope to claim 17, and thus it is rejected under similar rationale.
Regarding claim 36: it is similar scope to claim 18, and thus it is rejected under similar rationale.
Conclusion
The prior art made of record but not relied upon herein but pertinent to Applicant’s disclosure is listed in the enclosed PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YONG S PARK whose telephone number is (571)272-8349. The examiner can normally be reached M-F 9:00-5:00 PM, EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M. Sigmond can be reached on (303)297-4411. 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.
/YONGSIK PARK/Examiner, Art Unit 3694
December 26, 2025
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694