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 application filed on 10/27/2025. Claims 1 and 4 have been amended. Claims 6-21 have been cancelled. New claims 22-31 have added. Claims 1-5 and 22-31 are currently pending and have been examined.
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 1-5 and 22-31 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. A Section 101 analysis is below.
Step 1 – are the claims directed to a process, machine, manufacture or composition of matter. The method of claim 1, system of claim 22 and CRM of claim 27 are within the statutory categories of invention. For the purposes of this analysis, representative claim 22 is addressed.
Step 2A, prong one – do the claims recite a judicial exception, which is an abstract idea enumerated in MPEP 2106, a law of nature, or a natural phenomenon. Abstract ideas are in bold below, and represent the abstract idea of certain methods of organizing human activity of the commercial or legal interaction of a business relations which is identifying one or more custom-defined payment fields in the custom payment method to process a payment for a first subscriber of a new tenant. Please see MPEP 2106.04(a)(2)(II)(B) noting processing information through a clearing-house is an example of business relations. Please see Applicant’s specification, [0023]-[0025], discussing a universal payment connector to process payment transactions.
22. A system comprising: one or more computers and one or more storage devices storing instructions that are operable, when executed by the one or more computers, to cause the one or more computers to perform operations comprising:
maintaining, by a distributed multi-tenant system comprising a plurality of computing devices, a plurality of tenants associated with one or more template payment method type objects, each template payment method type object comprising one or more default payment fields and one or more custom-defined payment fields that are specified by a respective tenant;
receiving, from a new tenant and via a call to a first application programming interface (API), a payload comprising a custom payment method type definition having one or more custom-defined payment fields;
generating a template payment method type object comprising one or more default payment fields and the one or more custom-defined payment fields defined by the new tenant;
storing, by the distributed multi-tenant system, the template payment method type object in association with an identifier of the new tenant associated with the payload;
receiving a request from a computing device associated with the new tenant to generate a payment for a first subscriber of the new tenant, wherein the request specifies an identified endpoint that is external to the distributed multi-tenant system; and
in response to the request, performing operations comprising:
generating, from the template payment method type object associated with the new tenant, an instantiated payment method object having the one or more default payment fields and the one or more custom-defined payment fields defined by the new tenant, and
providing the instantiated payment method object having the one or more default payment fields and the one or more custom-defined payment fields defined by the new tenant to the identified endpoint for payment,
wherein providing the instantiated payment method object to the identified endpoint causes the identified endpoint to use a payment field mapping between (i) the one or more default payment fields and the one or more custom-defined payment fields of the instantiated payment method object and (ii) respective payment gateway- specific fields of one or more payment gateways when processing the payment for the first subscriber of the new tenant.
Step 2A, prong two – do the claims recite additional elements that integrate the judicial exception into a practical application. Integration of the judicial exception into a practical application requires an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. The additional elements are considered as follows:
The “one or more computers”, “one or more storage devices”, “distributed multi-tenant system comprising a plurality of computing devices”, “first application programming interface (API)”, “endpoint that is external to the distributed multi-tenant system”, and “one or more payment gateways”. Referring to MPEP 2106.05(f), the preceding recited additional elements are no more than mere instructions to implement an abstract idea or other exception on a computer. The computer components are recited at a high-level of generality (e.g., to receive, store, or transmit data) such that it amounts no more than mere instructions to apply the exception using generic computer components. Accordingly, the additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Please see MPEP 2106.05(f)(1) discussing when the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished this does not show integration into a practical application. Please see MPEP 2106.05(f)(2) discussing when the claim invokes computers or other machinery merely as a tool to perform an existing process including use of a computer or other machinery for economic tasks this does not show integration into a practical application.
The steps of “generating a template payment method type object comprising one or more default payment fields and the one or more custom-defined payment fields defined by the new tenant”, “generating, from the template payment method type object associated with the new tenant, an instantiated payment method object having the one or more default payment fields and the one or more custom-defined payment fields defined by the new tenant”, and “payment field mapping between (i) the one or more default payment fields and the one or more custom-defined payment fields of the instantiated payment method object and (ii) respective payment gateway- specific fields”. Referring to MPEP 2106.05(g), the preceding recited additional elements are no more than insignificant extra-solution activity amounting to no more than manipulating gathered information.
Step 2B – do the claims recited additional elements that amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The computer components implementing the abstract idea appear to be generic in view of at least Applicant’s specification, [0030]. Focusing on the additional elements of “generating a template payment method type object comprising one or more default payment fields and the one or more custom-defined payment fields defined by the new tenant”, “generating, from the template payment method type object associated with the new tenant, an instantiated payment method object having the one or more default payment fields and the one or more custom-defined payment fields defined by the new tenant”, and “payment field mapping between (i) the one or more default payment fields and the one or more custom-defined payment fields of the instantiated payment method object and (ii) respective payment gateway- specific fields” identified as extra solution activity above, evidence that these elements are well understood, routine and conventional can be found in Grassadonia (US 2016/0125371) ([0161]); Gaur (US 2022/0172198) ([0055]); Fasoli (US 9,129,276) (4:43-4:55); Jain (US 2012/0215687) ([0020]); Ahmed (US 2012/0047425) ([0091]); and Foth (US 2003/0110128) ([0026]). Moreover, it is respectfully noted that the Applicant’s specification, [0004], itself notes payment field mapping between native field names and payment gateway-specific field names is a conventional process.
In view of the above analysis, independent claims 1, 22 and 27 are is not patent eligible. Dependent claims 2-5 do not cure the deficiencies in their respective base claims. Specifically, claims 2-5 merely refine the abstract idea (2A1) by invoking a computer as a tool to perform an existing process (2A2, 2B). Regarding the further additional element in the dependent claims including the second API (claim 4), please see MPEP 2106.05(f)(2) discussing when the claim invokes computers or other machinery merely as a tool to perform an existing process including use of a computer or other machinery for economic tasks this does not show integration into a practical application or provide significantly more.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-5 and 22-31 are rejected under 35 U.S.C. 103 as being unpatentable over Shankar (US 2023/0030187) in view of Wang (US 2020/0043064).
Claim 1 recites:
A method for onboarding a new tenant in a distributed multi-tenant system, the method comprising: (Shankar, Fig. 5, [0089], method 500 for supporting tenant customizations)
maintaining, by the distributed multi-tenant system comprising a plurality of computing devices, a plurality of tenants associated with one or more template payment method type objects, each template payment method type object comprising one or more default payment fields and one or more custom-defined payment fields that are specified by a respective tenant; (Shankar, Fig. 4, [0088], standard objects 320, 330, custom fields 420, 430; [0055], “standard object can be thought of as a default object”)
receiving, from a new tenant and via a call to a first application programming interface (API), a payload comprising a custom payment method type definition having one or more custom-defined payment fields; (Shankar, Fig. 5, [0091]-[0093], tenant-specified custom data passed to and from standard API; Fig. 6, [0097], payment)
generating a template payment method object comprising one or more default payment fields and the one or more custom-defined payment fields defined by the new tenant; (Shankar, Fig. 5, [0095], response payload that includes the tenant-specified custom data; Fig. 6, [0097], response payload 620 customized to include custom field 622. Shankar does not specifically disclose a template. Wang, [0051], discusses generating custom charge models from template charge models. It would have been obvious to a person of ordinary skill in the art before the time of effective filing to modify the custom data of Shankar to be a custom charge model from a template as in Wang in order to accommodate multiple tenants in a system as discussed in Wang, [0004], and Shankar, [0023].)
storing, by the distributed multi-tenant system, the template payment method object in association with an identifier of the new tenant associated with the payload. (Shankar, Fig. 1, [0032], [0033], database systems 130 that store information including custom information, tenant-specific customizations; [0047], object types are maintained as metadata 138 in the database defining structure, formatting, fields; [0051]-[0053], objects and records; [0096], tenant-specified customizations; Fig. 9, [0101], [0102] tenant database 922)
receiving a request from a computing device associated with the new tenant to generate a payment for a first subscriber of the new tenant, (Shankar, Fig. 5, [0092], request 520; Fig. 6, [0097], request payload 610)
wherein the request specifies an identified endpoint that is external to the distributed multi-tenant system; and (Shankar, Fig. 5, [0092], request 520, cloud computing platform; Fig. 2, [0067], showing cloud computing platform 202 external to clients 210)
in response to the request, performing operations comprising: generating, from the template payment method type object associated with the new tenant, an instantiated payment method object having the one or more default payment fields and the one or more custom-defined payment fields defined by the new tenant, and (Shankar, Fig. 5, [0093], [0094], process the request payload including tenant-specified custom data; Fig. 6, [0097], response payload 620 includes standard fields and custom field 622)
providing the instantiated payment method object having the one or more default payment fields and the one or more custom-defined payment fields defined by the new tenant to the identified endpoint for payment, (Shankar, Fig. 5, [0095], at 550 send response payload to an external application of the customer)
wherein providing the instantiated payment method object to the identified endpoint causes the identified endpoint to use a payment field mapping between (i) the one or more default payment fields and the one or more custom-defined payment fields of the instantiated payment method object and (ii) respective payment gateway-specific fields of one or more payment gateways when processing the payment for the first subscriber of the new tenant. (Shankar, Fig. 6, [0097], response payload 620 includes standard fields, custom field 612, with Fig. 6 specifically showing “gatewayResponse”)
Claims 22 and 27 correspond to claim 1 and are rejected on the same grounds. Regarding system claim 22, Shankar, Fig. 1, [0040], processor 105, memory 106. Regarding CRM claim 27, Shankar, Fig. 1, [0040], CRM.
Claim 2 recites:
The method of claim 1, further comprising: determining that the payload comprises the custom payment method type definition based on receiving the payload via the call to the first API. (Shankar, Fig. 5, [0093], API of platform processes request payload including tenant-specified custom data)
Claims 23 and 28 correspond to claim 2 and are rejected on the same grounds.
Claim 3 recites:
The method of claim 1, wherein identifying the one or more custom-defined payment fields comprises determining, from the custom payment method type definition, a respective data type for each of the one or more custom-defined payment fields. (Shankar, [0026], each key represents the tenant-specified custom data and each value represents a value for that tenant-specified custom data; [0052], [0073], custom object)
Claims 24 and 29 correspond to claim 3 and are rejected on the same grounds.
Claim 4 recites:
The method of claim 1, further comprising: receiving, at the distributed multi-tenant system and via a call to a second API, a request to update the custom payment method type definition; and modifying the custom payment method type definition responsive to receiving the request via the call to the second API. (Shankar, [0158], definition of API as connection between two computers; [0061], tenant-specified custom data passed to and from the standard API. Shankar does not specifically modifying the custom payment method type definition. Wang, [0051], discusses “modify the template charge models based on user input to generate customs charge models 122. For example, a user may modify default data and/or logic definitions, and/or define blank fields for data and/or logic definitions.” Wang, [0056], further notes communications between microservices may be API-based. It would have been obvious to a person of ordinary skill in the art before the time of effective filing to modify the custom data passed to and from of Shankar to be a modification of models between APIs as in Wang in order to accommodate multiple tenants in a system as discussed in Wang, [0004], and Shankar, [0023].)
Claims 25 and 30 correspond to claim 4 and are rejected on the same grounds.
Claim 5 recites:
The method of claim 4, wherein modifying the custom payment method type definition comprises at least one of adding a new custom-defined payment field, removing an existing custom-defined payment field, or changing a respective data type of the existing custom-defined payment field. (Shankar, [0074], add features including custom fields. Please also see Wang, [0051], modify default data and/or logic definitions, and/or define blank fields)
Claims 26 and 31 correspond to claim 5 and are rejected on the same grounds.
Response to Arguments
Applicant's arguments filed 10/27/2025 have been fully considered and are addressed below.
Regarding the rejection under 35 U.S.C. 101, Applicant’s arguments have been fully considered but they are not persuasive. Regarding Step 2A, prong one, no arguments were presented concerning Step 2A, prong one.
Regarding Applicant’s arguments regarding Step 2A, prong two, integration into a practical application requires an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Limitations that are indicative of integration into a practical application include improvements to the functioning of a computer, applying the judicial exception with a particular machine, effecting transformation of a particular article to a different state or thing or applying the judicial exception in some other meaningful was beyond generally linking the use of the judicial exception to a particular technological environment. It is respectfully submitted that the feature cited by the Applicants, “receiving a request from a computing device associated with the new tenant to generate a payment for a first subscriber of the new tenant, wherein the request specifies an identified endpoint that is external to the distributed multi-tenant system; and in response to the request, performing operations comprising: generating, from the template payment method type object associated with the new tenant, an instantiated payment method object having the one or more default payment fields and the one or more custom-defined payment fields defined by the new tenant, and providing the instantiated payment method object having the one or more default payment fields and the one or more custom-defined payment fields defined by the new tenant to the identified endpoint for payment, wherein providing the instantiated payment method object to the identified endpoint causes the identified endpoint to use a payment field mapping between (i) the one or more default payment fields and the one or more custom-defined payment fields of the instantiated payment method object and (ii) respective payment gateway- specific fields of one or more payment gateways when processing the payment for the first subscriber of the new tenant“ is mere instructions to apply an exception. Please see MPEP 2106.05(f)(1) discussing when the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished this does not show integration into a practical application. Please see MPEP 2106.05(f)(2) discussing when the claim invokes computers or other machinery merely as a tool to perform an existing process including use of a computer or other machinery for economic tasks this does not show integration into a practical application. MPEP 2106.05(f)(2) gives examples where the courts have found the additional elements to be mere instructions to apply an exception, because they do no more than merely invoke computers or machinery as a tool to perform an existing process including: requiring the use of software to tailor information and provide it to the user on a generic computer, Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370-71, 115 USPQ2d 1636, 1642 (Fed. Cir. 2015). Briefly, in the remarks the Applicant cites Applicant’s specification, [0004], which admits field mapping between native field names and gateway-specific field names is known. Accordingly, as all that is claimed is the computers or other machinery of the claimed “endpoint” are used merely as a tool to perform the existing process of mapping of custom fields to gateway specific fields for payment processing, which is an economic task, this does not show integration into a practical application. Please also see MPEP 2106.05(a), noting a commonplace business method applied on a general purpose computer and gathering/analyzing/displaying information using conventional techniques are examples of features courts have indicated as not to show an improvement to technology. Here, the commonplace business method is field mapping between native field names and gateway-specific field names. Regarding the citation to BASCOM, filtering is not claimed, and the vaguely recited “endpoint” does not correspond to the specificity of “the installation of a filtering tool at a specific location, remote from the end‐users, with customizable filtering features specific to each end user" as in BASCOM. Regarding the citation to Amdocs, a distributed network architecture is not claimed. To the contrary, the system of the present application only recites “one or more computers”.
Regarding Step 2B, no arguments were presented regarding Step 2B.
Regarding the rejections under 35 U.S.C. 103, Applicant’s arguments have been fully considered and the amended claims are addressed in detail above. The Applicant argues “Claim 1 as amended recites “providing the instantiated payment method object to the identified endpoint causes the identified endpoint to use a payment field mapping between (i) the one or more default payment fields and the one or more custom-defined payment fields of the instantiated payment method object and (ii) respective payment gateway-specific fields of one or more payment gateways when processing the payment for the first subscriber of the new tenant” and that the “identified endpoint [] is external to the distributed multi-tenant system”. Applicant respectfully submits that neither Shankar and Wang, alone or in any combination, teach or suggest at least this feature of amended claim 1.” The Examiner respectfully disagrees. Please see Shankar, Fig. 5, [0092], discussing that at step 520 the request is sent from the customer to the cloud computing platform. Shankar, Fig. 2, [0067], shows the cloud computing platform 202 is external to clients 210.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure includes: US 20220230153; US 20220172198; US 20160125371; US 9129276; US 20120215687; US 20120047425; and US 20030110128.
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 concerning this communication or earlier communications from the examiner should be directed to Gregory Harper whose telephone number is (571)272-5481. The examiner can normally be reached on M-Th 7am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan Donlon can be reached at (571) 270-3602. 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.
/GREGORY HARPER/Examiner, Art Unit 3692 /DAVID P SHARVIN/Primary Examiner, Art Unit 3692