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
Applicant filed an amendment on January 23, 2026. Claims 1-20 were pending in the Application. Claims 1-14 are amended. Claims 21-22 have been added. Claims 15-20 remain withdrawn. Claims 1 and 10 are the independent claims, the remaining claims depend on claims 1 and 10. Thus claims 1-14 and 21-22 are currently pending. After careful and full consideration of Applicant arguments and amendments, the Examiner finds them to be moot and/or not persuasive.
Claim Objections
Claim 10 is objected to because of the following informalities: “receiving, via the uniform SPI, an approval of the payment mandate setup request …” should read “receiving, via the uniform SPI, an approval of the payment provider-independent payment mandate setup request …”.
Claim 21 is objected to because of the following informalities: “…, wherein the standardized data structure includes a an object …” should read “…, wherein the standardized data structure includes an object …”.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(4) because reference characters "152" and "153" have both been used to designate “Merchant application programming interface (API)” in specification, (US 20250182114 A1, FIG. 1; paras 29-30). Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Response to Arguments
In the context of 35 U.S.C. §101, Applicant respectfully traverses the rejection. Applicant is of the opinion that the claims are statutory and respectfully asserts that “the claims are not directed an “Abstract Idea” and accordingly, are “eligible at Step 2A Prong One”; amended, independent claims 1 and 10 are removed from any potential realm of human activity, as analyzing and exchanging complex and voluminous information using a schema/structure for mapping data fields between highly varying interfaces and systems, as would be maintained by different service provider and merchants, qualifies as non-human activity; the use of such structures improves security and efficiency of data exchange by utilizing a uniform SPI and server-controlled APIs; the elements in combination cannot be practically performed by humans and require specialized computing resources; the claims are integrated into a practical application; because the Office’s analysis under Prong One of Step 2A is improper, analysis under Prong Two is unnecessary; the pending claims present additional elements that reflect “an improvement to … technology or [a] technical field and that apply or use the judicial exception in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception”; the additional elements provide a clear and concrete technical improvement over prior art systems; the system “addresses the problem of delivering consistent payment mandate services to customers, regardless of the payment provider that the customer chooses to use for the payment mandate because the supported payment providers comply with a standardized or uniform interface for setting up payment mandates; the claimed invention shares certain similarities with claim 1 of Example 42 in the 2019 Subject Matter Eligibility Examples: Abstract Ideas; the present claims share key characteristics with Example 42 that render them patent-eligible under Step 2A, Prong 1 and Prong 2; like Example 42, the present claims solve the technical problem of standardizing inter-system inputs and data formatting to facilitate inter-system communication (e.g., in real time); like Example 42, the present claims do not merely organize human activity or perform generic data processing, but rather, they use a standardized data structure to facilitate exchange of data related to payment mandates between various merchants and service providers; the improvements provided by the claimed methods are rooted in computer technology and cannot be practically performed by humans; the claims are eligible at Prong Two because “the claims as a whole integrate the alleged recited judicial exception into a practical application of that exception; the claims amount to “Significantly More” than any alleged abstract idea; the claims do not recite and are not directed to an abstract idea, and, thus, the “significantly more” inquiry does not apply; assuming the claims are directed to an abstract idea (which they are not), the claims amount to “significantly more” than any abstract idea because the claims recite additional elements that are not well-understood, routine, or conventional; like the claims in DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258 (Fed. Cir. 2014), the claims do not merely apply a generic concept or organize human activity, rather, they recite specific technical mechanisms, including exchanging data through server-configured merchant and transaction APIs, standardized data structure, and storing payment mandates in a data store (e.g., for later use); these features improve system responsiveness and performance by providing a standardized data structure for facilitating inter-system communication, which is a technical solution to a technical problem, not an abstract idea; the claimed invention shares certain similarities with claim 2 of Example 21 in the 2015 Subject Matter Eligibility Examples (see July 2015 Update Appendix 1: Examples at 1-5; the present claims share key characteristics with Example 21 that render them patent-eligible under Step 2B; the features of amended claims 1 and 10 operate to solve a technical problem: standardized inter-system inputs and data formatting to facilitate inter-system communication (e.g., in real time); and like claim 2 of Example 21, amended claims 1 and 10 amount to significantly more than simply organizing and comparing data but, instead, employ particular technical mechanisms to solve a particular technological problem.”
Initially, the Examiner would like to point out that the basis of the rejection is Alice, by applying the subject matter eligibility analysis and flowchart according to MPEP § 2106, which applies a two-step framework, earlier set out in Mayo Collaborative Services v. Prometheus Laboratories, Inc., 566 U.S. 66 (2012), "for distinguishing patents that claim laws of nature, natural phenomena, and abstract ideas from those that claim patent-eligible applications of those concepts." Alice, 573 U.S. at 217.
Under the two-step framework, it must first be determined if "the claims at issue are directed to a patent-ineligible concept." If the claims are determined to be directed to a patent-ineligible concept, e.g., an abstract idea, then the second step of the framework is applied to determine if "the elements of the claim ... contain an "inventive concept" sufficient to 'transform' the claimed abstract idea into a patent-eligible application." (citing Mayo, 566 U.S. at 72-73, 79).
With regard to step one of the Alice framework, we apply a "directed to" two-prong test: 1) evaluate whether the claim recites a judicial exception, and 2) if the claim recites a judicial exception, evaluate whether the claim "applies, relies on, or uses 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 judicial exception," i.e., whether the claim integrates the judicial exception into a practical application. (MPEP §2106.04 II.A.1. and II.B.2.).
[AltContent: ]The Specification, (PG Pub US 20250182114 A1, para 3), provides evidence as to what the claimed invention is directed. In this case, the specification, (‘114 A1, para 3), discloses that the invention relates to payment mandates for merchant-initiated transactions, and is grouped under “Certain Methods of Organizing Human Activity, commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations)”, in prong one of step 2A. (MPEP §2106.04 II.A.1.).
Claim 10 provides additional evidence, and recites the limitations “establishing a communicative link with a merchant of a plurality of merchants via a merchant application programming interface (API) operated by the server; receiving, via the merchant API, a payment mandate setup request from the merchant to set up the payment mandate, the payment mandate setup request comprising a payment provider identifier identifying a payment provider of a plurality of payment providers; generating, by a computer system comprising a processor and a memory, a payment provider-independent payment mandate setup request that conforms to a standardized data structure defined by the server for mapping data fields exposed through the merchant API to corresponding data fields associated with a uniform service provider interface (SPI) defined by the server, the standardized data structure enabling interoperability with the plurality of payment providers via the uniform SPI; transmitting, by the computer system via the uniform SPI, the payment provider-independent payment mandate setup request to the payment provider identified by the payment provider identifier, the payment provider-independent payment mandate setup request comprising a payment mandate identifier; receiving, via the uniform SPI, an approval of the payment mandate setup request from the identified payment provider, the approval comprising the payment mandate identifier; and storing, in a payment mandate data store, the payment mandate for a customer of the merchant in association with the merchant and the payment provider, the payment mandate being associated with the payment mandate identifier”, where the italicized claim language represents the abstract idea of “setting up payment agreements between merchant and customer”, and the additional elements are in bold. (MPEP §2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional elements of the claim, such as “establishing a communicative link with a merchant of a plurality of merchants via a merchant application programming interface (API) operated by the server”, “generating, by a computer system comprising a processor and a memory, a payment provider-independent payment mandate setup request that conforms to a standardized data structure defined by the server for mapping data fields exposed through the merchant API to corresponding data fields associated with a uniform service provider interface (SPI) defined by the server, the standardized data structure enabling interoperability with the plurality of payment providers via the uniform SPI”, and “a payment mandate data store”, amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “setting up payment agreements between merchant and customer.”
The limitations of “receiving, via the merchant API, a payment mandate setup request …”, “receiving, via the uniform SPI, an approval of the payment provider-independent payment mandate setup request …”, and “transmitting, by the computer system via the uniform SPI, the payment provider-independent mandate setup request to the payment provider …” as additional elements, are recited at a high level of generality (i.e., as a general means of gathering a payment mandate setup request, an approval of the payment provider-independent payment mandate setup request, and data outputting, such as transmitting the payment provider-independent mandate setup request to the payment provider), and amounts to mere data gathering and data output, which are forms of insignificant extra-solution activity.
Examiner notes the basis of the rejection was, and is not as any mental process covering performance in the mind, but classified as an abstract idea, “setting up payment agreements between merchant and customer”, grouped under “Certain Methods of Organizing Human Activity, commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations)”.
With respect to the additional elements operating in a non-conventional and non-generic way and reflecting an improvement to a particular technological environment, the cited additional elements represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “setting up payment agreements between merchant and customer”. The claim is not directed to improving computer functionality nor improving another technology or technical field, but improving the abstract idea “setting up payment agreements between merchant and customer”. For potential improvement in an abstract idea “setting up payment agreements between merchant and customer”, it is important to keep in mind that an improvement in the abstract idea itself (e.g. a setting up payment agreements between merchant and customer concept) is not an improvement in technology. (MPEP § 2106.04(d)(1)). Therefore, claim 10 is non-statutory.
Claim 1 also recites the abstract idea of “setting up payment agreements between merchant and customer”, as well as the additional elements of “a server”, “a processor”, “a memory storing instructions that, when executed by the processor, cause the processor to perform operations comprising: …”, “establishing a communicative link with a merchant of a plurality of merchants via a merchant application programming interface (API) operated by the server”, “generating, based on the payment mandate setup request, a payment provider-independent payment mandate setup request that conforms to a standardized data structure defined by the server for mapping data fields exposed through the merchant API to corresponding data fields associated with a uniform service provider interface (SPI) defined by the server, the standardized data structure enabling interoperability with the plurality of payment providers via the uniform SPI”, and “a payment mandate data store”, which amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “setting up payment agreements between merchant and customer”.
The limitations of “receiving, via the merchant API, a payment mandate setup request …”, “receiving, via the uniform SPI, an approval of the payment mandate setup request …”, and “transmitting, via the uniform SPI, the payment provider-independent mandate setup request to the payment provider …” as additional elements, are recited at a high level of generality (i.e., as a general means of gathering a payment mandate setup request, an approval of the payment mandate setup request, and data outputting, such as transmitting the payment provider-independent mandate setup request to the payment provider), and amounts to mere data gathering and data output, which are forms of insignificant extra-solution activity.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of “setting up payment agreements between merchant and customer” using computer technology (e.g., “a processor” and “a memory”). Therefore, the use of these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 1 is non-statutory.
Finally, Examiner notes the basis of the rejection is Alice, by applying the subject matter eligibility analysis and flowchart according to MPEP § 2106. And, based on this standard, the claims are non-statutory, and correctly rejected under 35 U.S.C. § 101.
In the context of 35 U.S.C. § 112(a), Written Description, paragraph 17 of the Non-Final Rejection Office Action dated September 25, 2025, Applicant has adequately amended to render the rejection under 35 U.S.C. § 112(a), New Matter, moot. Claim 9 has been amended to recite “The server of claim 1, wherein the payment provider-independent payment mandate setup request comprises a return uniform resource identifier (URI)”, which the specification, (PG Pub US 20250182114 A1, para 44) provides support by reciting “… the payment mandate setup request 281 from the merchant may include a return uniform resource iden-tifier (URI), which may also be provided to the payment provider 283 as part of the payment provider-independent payment mandate setup request 284 …”. Examiner hereby rescinds the rejection under 35 U.S.C. § 112(a), Written Description, paragraph 17 of the Non-Final Rejection Office Action dated September 25, 2025.
In the context of 35 U.S.C. § 102, in the Non-Final Rejection Office Action dated September 25, 2025, Applicant has adequately amended to overcome the rejection under 35 U.S.C. § 102 by amending claim 1 to recite “a memory storing instructions that, when executed by the processor, cause the processor to perform operations comprising: establishing …; receiving …; generating …; transmitting …; receiving …; and storing …”. Therefore, Arya, US 11386445 B1, fails to disclose or suggest the amended subject matter. Based on the amended claim 1, Examiner has rescinded the rejection under 35 U.S.C. § 102 for claims 1-9.
In the context of 35 U.S.C. § 103, in the Final Rejection Office Action dated September 25, 2025, Applicant has not adequately amended to overcome the current record of art in the Non-Final Rejection Office Action, dated September 25, 2025. Applicant respectfully submits that Arya, US 11386445 B1, Piparsaniya, US 11392956 B2, and Meredith, US 11004083 B2, individually or in any combination, do not teach or suggest each and every element of any of independent claims 1 or 10, and therefore also do not teach or suggest each and every element of any of claims 2-9, 11-14, or 21-22, each of which depends from one of independent claims 1 and 10 and thereby incorporates its features.
Applicant submits that Piparsaniya does not describe or suggest, at least, creating a payment provider-independent payment mandate setup request, receiving or selecting among multiple payment providers, or transmitting mandate requests or their approvals using a standardized data structure, as recited in claims 1 and 10, nor does Piparsaniya disclose storing a payment mandate request between a merchant and customer, as also recited in amended claims 1 and 10. Meredith does not remedy the deficiencies of Arya and Piparsaniya. Accordingly, Arya, Piparsaniya, and Meredith, individually or in any combination, do not teach or suggest the features of the amended claims.
Examiner finds the applicant arguments for the limitation “generating based on the payment mandate setup request, a payment provider-independent payment mandate setup request that conforms to a standardized data structure defined by the server for mapping data fields exposed through the merchant API to corresponding data fields associated with a uniform service provider interface (SPI) defined by the server, the standardized data structure enabling interoperability with the plurality of payment providers via the uniform SPI”, moot in view of new grounds of rejection, and therefore, amended claim 1, as well as amended claim 10, is not patentable. Amended claim 1, as well as amended claim 10, stands rejected under 35 U.S.C §103 in the analysis below, and is therefore, not patentable in view of REST API Referemce now applying to the applicable amended sections for claim 1, as well as to amended claim 10. Claims 2-9 and 21-22, which depend on claim 1, and claims 11-14, which depends on claim 10, also stand rejected under 35 U.S.C. § 103.
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-14 and 21-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 1-9 and 21-22 are directed to a “ server”; and claims 10-14 are directed to a “method”. Therefore, these claims are directed to one of the four statutory categories of invention.
Claim 10 recites “establishing a communicative link with a merchant of a plurality of merchants via a merchant application programming interface (API) operated by the server; receiving, via the merchant API, a payment mandate setup request from the merchant to set up the payment mandate, the payment mandate setup request comprising a payment provider identifier identifying a payment provider of a plurality of payment providers; generating, by a computer system comprising a processor and a memory, a payment provider-independent payment mandate setup request that conforms to a standardized data structure defined by the server for mapping data fields exposed through the merchant API to corresponding data fields associated with a uniform service provider interface (SPI) defined by the server, the standardized data structure enabling interoperability with the plurality of payment providers via the uniform SPI; transmitting, by the computer system via the uniform SPI, the payment provider-independent payment mandate setup request to the payment provider identified by the payment provider identifier, the payment provider-independent payment mandate setup request comprising a payment mandate identifier; receiving, via the uniform SPI, an approval of the payment mandate setup request from the identified payment provider, the approval comprising the payment mandate identifier; and storing, in a payment mandate data store, the payment mandate for a customer of the merchant in association with the merchant and the payment provider, the payment mandate being associated with the payment mandate identifier” where the italicized claim language represents the abstract idea of “setting up payment agreements between merchant and customer”, and the additional elements are in bold. (MPEP §2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional elements of the claim, such as “establishing a communicative link with a merchant of a plurality of merchants via a merchant application programming interface (API) operated by the server”, “generating, by a computer system comprising a processor and a memory, a payment provider-independent payment mandate setup request that conforms to a standardized data structure defined by the server for mapping data fields exposed through the merchant API to corresponding data fields associated with a uniform service provider interface (SPI) defined by the server, the standardized data structure enabling interoperability with the plurality of payment providers via the uniform SPI”, and “a payment mandate data store”, amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “setting up payment agreements between merchant and customer”.
The limitations of “receiving, via the merchant API, a payment mandate setup request …”, “receiving, via the uniform SPI, an approval of the payment provider-independent payment mandate setup request …”, and “transmitting, by the computer system via the uniform SPI, the payment provider-independent mandate setup request to the payment provider …” as additional elements, are recited at a high level of generality (i.e., as a general means of gathering a payment mandate setup request, an approval of the payment provider-independent payment mandate setup request, and data outputting, such as transmitting the payment provider-independent mandate setup request to the payment provider), and amounts to mere data gathering and data output, which are forms of insignificant extra-solution activity.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of “setting up payment agreements between merchant and customer” using computer technology (e.g., “a computer system” and “a merchant API”). Therefore, these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 10 is non-statutory.
Claim 1 also recites the abstract idea of “setting up payment agreements between merchant and customer”, as well as the additional elements of “a server”, “a processor”, “a memory storing instructions that, when executed by the processor, cause the processor to perform operations comprising: …”, “establishing a communicative link with a merchant of a plurality of merchants via a merchant application programming interface (API) operated by the server”, “generating, based on the payment mandate setup request, a payment provider-independent payment mandate setup request that conforms to a standardized data structure defined by the server for mapping data fields exposed through the merchant API to corresponding data fields associated with a uniform service provider interface (SPI) defined by the server, the standardized data structure enabling interoperability with the plurality of payment providers via the uniform SPI”, and “a payment mandate data store”, which amount to merely “apply it”, as they represent the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “setting up payment agreements between merchant and customer”.
The limitations of “receiving, via the merchant API, a payment mandate setup request …”, “receiving, via the uniform SPI, an approval of the payment mandate setup request …”, and “transmitting, via the uniform SPI, the payment provider-independent mandate setup request to the payment provider …” as additional elements, are recited at a high level of generality (i.e., as a general means of gathering a payment mandate setup request, an approval of the payment mandate setup request, and data outputting, such as transmitting the payment provider-independent mandate setup request to the payment provider), and amounts to mere data gathering and data output, which are forms of insignificant extra-solution activity.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of “setting up payment agreements between merchant and customer” using computer technology (e.g., “a processor” and “a memory”). Therefore, the use of these additional elements do no more than employ a computer as a tool to implement the abstract idea. And as the computer does no more than serve as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. Therefore, claim 1 is non-statutory.
Dependent claims 2-9, 11-14, and 21-22 further describe the abstract idea of “setting up payment agreements between merchant and customer”, which is insufficient to overcome the rejections of claims 1 and 10.
Dependent claims 2-8, 11-13, and 21-22 do not recite any new additional elements that integrate the abstract idea into a practical application, and that do no more than represent a computer performing functions that correspond to implementing the acts of “setting up payment agreements between merchant and customer”, when analyzed under Step 2A, Prong Two. And, as they do no more than employ a computer as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or a technical field, when analyzed under Step 2B.
Dependent claims 9 and 14 recite a new additional element of “a return uniform resource identifier (URI)”, which does no more than employ a computer as a tool to implement the abstract idea, when analyzed under Step 2A, Prong Two. And, as it does no more than employ a computer as a tool to implement the abstract idea, it does not improve computer functionality nor improve another technology or a technical field, when analyzed under Step 2B.
Hence, claims 1-14 and 21-22 are not patent eligible.
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 set forth in Graham v. John Deere Co., 383 U. S. 1. 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 9-11, 14, and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Arya et al (U. S. Patent No. 11386445 B1), herein referred to as Arya, in view of Piparsaniya et al (U. S. Patent No. 11392956 B2), herein referred to as Piparsaniya, and in further view of Authentication | REST API Reference | Wix.com (searchable link), herein referred to as REST API Reference.
Regarding claims 1 and 10, Arya discloses a server comprising (FIG. 1, items 100, 104; C/L 1/65-2/32, “… The system includes a network interface configured to communicate, via a network, with a customer device associated with a customer and a processing circuit. The processing circuit includes a memory and at least one processor. The memory stores instructions that are executable by the at least one processor to receive a request from the customer to open a subscription account. The memory stores instructions that are executable by the at least one processor to create the subscription account for the customer. The memory stores instructions that are executable by the at least one processor to deduct a fee from the subscription account, the fee structured to subsidize benefit fees associated with benefits for the customer. The memory stores instructions that are executable by the at least one processor to determine a benefit for the customer, wherein the benefit is offered by a third-party vendor in exchange for an associated fee. The memory stores instructions that are executable by the at least one processor to reimburse the subscription account for the customer in an amount of the fee associated with the benefit. The memory stores instructions that are executable by the at least one processor to gather financial information associated with the customer. The memory stores instructions that are executable by the at least one processor to analyze the financial information to identify positive financial behavior of the customer. The memory stores instructions that are executable by the at least one processor to invoke, via a user interface on the customer device, a graphical depiction executable, wherein the graphical depiction comprises a chart generated by the system. The memory stores instructions that are executable by the at least one processor to determine that the positive financial behavior meets a threshold. The memory stores instructions that are executable by the at least one processor to offer the customer a reward based on the positive financial behavior meeting the threshold …”): a processor; and a memory (FIG. 1, items 132, 134, 140; C/L 7/19-22, “… The processing circuit 132 includes a processor 140. As shown in FIG. 1, the processing circuit 132 is also operably connected to the memory 134. As further shown in FIG. 1, the memory 134 includes a customer accounts database 142 …”) storing instructions that, when executed by the processor, cause the processor to perform operations comprising:
establishing a communicative link with a merchant of a plurality of merchants via a merchant application programming interface (API) operated by the server (C/L 15/27-39, “… the subscription account management circuit 138 may interface with one or more vendor computing systems 106 associated with the one or more vendors (e.g., using APIs) to determine what third-party benefits a particular customer already holds with the third-party vendors… the subscription account management circuit 138 may use an API to access information about a particular customer stored with a vendor at the vendor computing system 106 (e.g., with the customer's permission) to determine whether the customer has an account with the vendor. Then, the subscription account management circuit 138 may use the gathered vendor account information to directly pay the vendor on the customer's behalf …”; C/L 16/1-8, “… after receiving permission from the customer, the subscription account management circuit 138 may interface with the one or more vendor computing systems 106 (e.g., using APIs) to determine whether the customer already has an account with each of the one or more vendor computing systems 106, as described above, to recommend that the customer select a third-party benefit that the customer already uses …”);
receiving, via the merchant API, a payment mandate setup request from the merchant to set up the payment mandate, the payment mandate setup request comprising a payment provider identifier identifying a payment provider of a plurality of payment providers (FIG. 2, items 200, 202; C/L 18/28-38, “… At 202, the provider computing system 104 receives a request from a customer (e.g., via the customer device 102) to open a subscription account … the customer is requesting to open a new account with the accounts provider … the customer is requesting to convert an existing account held with the accounts provider to the subscription account … the provider computing system 104 receives the request online, such as through a website associated with the provider computing system 104 or through a mobile banking application …”); …
… the payment provider-independent payment mandate setup request comprising a payment mandate identifier (FIG. 8, items 802, 804; C/L 30/4-11,”… FIG. 8, the accounts summary page 802 includes a list of the customer's accounts held with the accounts provider. In the example of FIG. 8, the accounts summary page 802 includes a subscription account section 804, a savings account section 806, and a mortgage account section 808. Each of the sections 804, 806, and 808 includes an icon 810 that the customer can select to view more options related to the account …”);
receiving, via the uniform SPI, approval of the payment provider-independent payment mandate setup request from the identified payment provider, the approval comprising the payment mandate identifier (FIG. 2, items 204, 206, 208; C/L 18/39-48, “… At 204, the provider computing system 104 verifies that the customer meets criteria for the subscription account … the criteria may include a certain level of risk that the customer meets or is below (e.g., based on the customer's credit score and financial history), a minimum balance that the customer needs to maintain in the subscription account, and so … the provider computing system 104 may offer the customer a subscription account with different terms based on whether the customer meets various account criteria thresholds …”; C/L 19/3-29, “… At 206, the provider computing system 104 prompts the customer to select a subscription tier … each subscription tier is associated with a certain subscription fee (e.g., charged on a monthly or yearly basis) … the provider computing system 104 may offer the customer three different subscription tiers, where the lowest tier is associated with a $1.99 per month fee, the second tier is associated with a $7 .99 per month fee, and the highest tier is associated with a $14.99 per month fee. Additionally, each subscription tier is associated with certain types and/or a certain amount (e.g., a certain monetary amount and/or a certain quantity) of benefits … the customer may be offered a fee discount if the customer pays for a certain amount of time for the subscription account at once, such as a 15% discount if the customer agrees to pay the entirety of a yearly subscription at once as opposed to paying the subscription fee month-to-month. … all subscription accounts may be offered at a single tier. As such, the customer may not be prompted to select a subscription tier, and the provider computing system 104 may instead proceed to opening the subscription account …”); and …
Arya does not specifically disclose, however, Piparsaniya discloses transmitting, via the uniform SPI, the payment provider-independent payment mandate setup request to the payment provider identified by the payment provider identifier (C/L Figure 3A, item 306; C/L 11/29-52, “… In a step 306, the consumer 104 provides details of the recurring payment transactions with the merchant 106 via the application or website. These recurring payment transactions may be a result of the consumer 104 purchasing products and/or services from the merchant 106 … the consumer 104 subscribed to a content streaming service provided by the merchant 106, such as Netflix. The recurring payment transactions would be for recurring payments to the merchant 106 during the subscription period of the content streaming service, such as monthly payments for a two-year subscription period … the consumer 104 purchased some products from the merchant 106 and wanted to pay for the products in installments. The recurring payment transactions would be for recurring installment payments to the merchant 106, such as six monthly installments over a half-year period. Accordingly, the consumer 104 is in a contractual agreement with the merchant 106, in which the consumer 104 agrees to make recurring payments over a contractual period to the merchant 106 in exchange for the products and/or services. Recurring payment transactions are initiated by the merchant 106 during the contractual period until the contractual period ends, or until the contractual agreement is terminated by either party or mutual agreement …”; Figure 4, item 414; C/L 16/29-32, “… After receiving the virtual payment instrument details, in a step 414, the consumer 104 provides details of the recur-ring payment transactions with the merchant 106 via the application or website …”), …
storing, in a payment mandate data store, the payment mandate for a customer of the merchant in association with the merchant and the payment provider (Figure 3D; C/L 14/26-40, “… Each consumer has a real payment instrument which is associated with or linked to a virtual instrument which is in turn associated with or linked to a set of payment tokens. These associations are stored on the payment network database 122. FIG. 3D illustrates an example of the set of payment tokens associated with the virtual payment instrument linked to the real payment instrument 110 … there are twelve payment tokens, each for a particular month from January 2018 to December 2018. Each payment token is associated with the virtual payment instrument and date data for the respective month. Each payment token may optionally be further associated with one or more of the real payment instrument details, set of common dates, common maximum payment amount, and optionally a common time …”; Figure 4, items 412, 416, 418, 420; C/L 16/21-39, “… the merchant 106 receives a merchant copy of the set of payment tokens after the payment network server 102 has generated the payment tokens. In a step 412, the payment network server 102 stores the real payment instrument details and virtual payment instrument details on the payment network database 122 … the merchant stores the merchant copy of the virtual payment instrument details and payment tokens on the merchant database. After receiving the virtual payment instrument details, in a step 414, the consumer 104 provides details of the recurring payment transactions with the merchant 106 via the application or website. In a step 416, the payment network server 102 receives the recurring payment transactions details from the consumer electronic device 108. In a step 418, the payment network server 102 generates the set of payment tokens based on the recurring payment transactions details. In a step 420, the payment network server 102 stores the set of payment tokens on the payment network database 122 …”), the payment mandate being associated with the payment mandate identifier (C/L 8/3-14, “… The account is linked to the consumer payment instrument 110 and thus the consumer payment instrument 110 stores identification information of the account. The account identification information may be stored in the form of an electronic chip or a machine-readable magnetic strip embedded in the consumer payment instrument 110. The account identification information may include an account number and the name of the account holder (i.e. consumer 104). The consumer payment instrument 110 has a unique identifier, an expiry date, security data, and type. The payment instrument identifier, expiry date, security data, and type constitute details of the consumer payment instrument 110 …”; C/L 9/16-34, “… The acquirer server 116 is a computer server operated by an acquirer institution or bank at which merchants including the merchant 106 maintain merchant accounts to receive and accept payments for goods, products, and/or services purchased by various consumers including the consumer 104. Account information of the merchant accounts established with the acquirer institution is stored as account profiles in an acquirer database of the acquirer institution. The acquirer database may reside locally on the acquirer server 116, or alternatively on a remote or cloud server communicatively linked to the acquirer server 116. The acquirer institution processes payment transaction requests received from the merchant server 112 by using the acquirer server 116. The acquirer server 116 communicates the payment transaction requests to the payment network server 102 and/or issuer institutions through the communication network 120. The acquirer server 116 is configured for crediting the financial account of the merchant 106 maintained in the acquirer institution upon processing of the payment transaction …”).
Piparsaniya discloses processing recurring payment transactions. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include processing recurring payment transactions, as in Piparsaniya, to improve and/or enhance the technology for determining and providing non-financial benefits on a subscription basis, as in Arya, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide an improved electronic system and computerized method for processing recurring payment transactions offering protection to the sensitive information contained in a real, physical credit card, that a merchant is in possession of after the merchant triggers payment of the subscription service after the free trial period has ended, and such details may be compromised during or after the subscription period.
Arya and Piparsaniya do not specifically disclose, however, REST API Reference discloses generating, based on the payment mandate setup request (“Create Transaction, “This SPI will be triggered when a transaction is recorded in Wix. Initiate payment upon receipt of this SPI …”; “Create Transaction – Installments, Number of payment installments”), a payment provider-independent (“Connect Account, “This SPI will be triggered when a merchant provides the required data to connect a payment provider account to their Wix site. This allows you to verify the merchant's credentials as provided to Wix, and confirm that the merchant is registered to your service…”, which shows the SPI is provider-independent because it can connect to a variety of payment providers) payment mandate setup request that conforms to a standardized data structure defined by the server (“Integration – High level schema, “One major difference between this SPI and a regular API is that you will have to implement a server on your side, rather than use an existing API. To accomplish this integration fully, use the Wix Event API …”, which describes a high level visualization of the integration process”) for mapping data fields exposed through the merchant API to corresponding data fields associated with a uniform service provider interface (SPI) defined by the server (“Create Transaction – Body Params”), the standardized data structure enabling interoperability with the plurality of payment providers via the uniform SPI (“Connect Account, “This SPI will be triggered when a merchant provides the required data to connect a payment provider account to their Wix site. This allows you to verify the merchant's credentials as provided to Wix, and confirm that the merchant is registered to your service…”, which offers interoperability with other payment service providers); …
REST API Reference discloses a payment provider SPI and APIs. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a payment provider SPI and APIs; as in REST API Reference; and to include processing recurring payment transactions, as in Piparsaniya, to improve and/or enhance the technology for determining and providing non-financial benefits on a subscription basis, as in Arya, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a payment platform comprising a service provider interface (SPI) being designed for deeper integration between the payment platform and external payment providers through application programming interfaces (APIs), and being considered as a B2B solution, which allows the payment platform to represent a huge variety of payment methods in different locations all over the globe, and being transparent and more efficient to the customer in completing transactions.
Regarding claims 2 and 11, Arya, Piparsaniya, and REST API Reference disclose the limitations of claims 1 and 10. Arya and REST API Reference do not specifically disclose, however, Piparsaniya discloses the server of claim 1, wherein the operation further comprise:
receiving, from the merchant, a payment intent request associated with the customer of the merchant (Figure 2, item 202; C/L 4/46-52, “… In a step 202 of the method 200, the transaction module 102a of the payment network server 102 receives a request from the merchant 106 for an instant payment transaction during an instant recurring period. The instant payment transaction request includes details of a virtual payment instrument of the consumer 104 and a payment amount for the instant recurring period …”);
retrieving the payment mandate for the customer of the merchant from the payment mandate data store (Figure 1, 2, items 122, 208; C/L 5/23-32, “… In a step 208, the token management module 102b retrieves, from the payment network database 122 in response to successful validation of the instant payment transaction request, details of the real payment instrument 110 linked to the virtual payment instrument. The real payment instrument details include an identifier and security data of the real payment instrument 110 … the real payment instrument 110 is a credit card and the details thereof include the credit card number, expiry date, security/ verification code, and authentication code ( e.g. PIN) …”); and
in response to successfully retrieving the payment mandate, transmitting a payment authorization request to the payment provider associated with the payment mandate (Figure 1, 2, items 102, 102c, 104, 106, 110, 118, 210; C/L 5/33-44, “… In a step 210, the authorization module 102c of the payment network server 102 communicates, to the issuer server 118 for the real payment instrument 110, a request for authorization of the instant payment transaction, the authorization request including the real payment instrument details and the payment amount. The authorization request is subsequently processed by the issuer server 118 in a standard manner readily known to the skilled person. The payment amount is transferred from the real payment instrument 110 of the consumer 104 to the account of the merchant 106 in response to authorization of the instant payment transaction …”).
Piparsaniya discloses processing recurring payment transactions. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include processing recurring payment transactions, as in Piparsaniya; and to include a payment provider SPI and APIs; as in REST API Reference, to improve and/or enhance the technology for determining and providing non-financial benefits on a subscription basis, as in Arya, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references providing a system and method for processing payment transactions between a consumer and a merchant, the payment transactions recurring over a series of recurring periods, and protecting the sensitive payment transaction card information of the consumer in possession of the merchant after the free subscription trial period has ended and triggering the recurring payments.
Regarding claims 9 and 14, Arya, Piparsaniya, and REST API Reference disclose the limitations of claims 1 and 10. Arya and REST API Reference do not specifically disclose, however, Piparsaniya discloses the server of claim 1, wherein the payment provider-independent payment mandate setup request comprises a return uniform resource identifier (URI) (Figure 3, item 302; C/L 11/4-11, “… In a step 302 of the consumer registration procedure 300, the consumer 104 executes the application on the consumer electronic device 108. Alternatively, the consumer 14 may initiate the consumer registration procedure 300 via a web-site interface accessible by the consumer electronic device 108. The application or website presents a graphical user interface (GUI) 502 on the consumer electronic device 108 for performing the consumer registration procedure 300 …”; Figure 3, item 306; C/L 29-31, “… In a step 306, the consumer 104 provides details of the recurring payment transactions with the merchant 106 via the application or website …”).
Piparsaniya discloses processing recurring payment transactions. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include processing recurring payment transactions, as in Piparsaniya; and to include a payment provider SPI and APIs; as in REST API Reference, to improve and/or enhance the technology for determining and providing non-financial benefits on a subscription basis, as in Arya, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a system and a method avoiding and/or eliminating the merchant being able to abuse the credit card details provided for recurring payments of a subscription to merchant services, and continue to process payments from the credit card, even after the subscription period has ended.
Regarding claim 21, Arya, Piparsaniya, and REST API Reference disclose the limitations of claim 1. Arya and Piparsaniya do not specifically disclose, however, REST API Reference discloses the server of claim 1, wherein the standardized data structure (“Integration – High level schema, “One major difference between this SPI and a regular API is that you will have to implement a server on your side, rather than use an existing API. To accomplish this integration fully, use the Wix Event API …”, which describes a high level visualization of the integration process”) includes a an object having specified fields describing one or more constraints of the payment mandate and one or more data type (“Create Transaction – Body Params”).
REST API Reference discloses a payment provider SPI and APIs. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a payment provider SPI and APIs; as in REST API Reference; and to include processing recurring payment transactions, as in Piparsaniya, to improve and/or enhance the technology for determining and providing non-financial benefits on a subscription basis, as in Arya, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a payment platform comprising a service provider interface (SPI) being designed for deeper integration between the payment platform and external payment providers through application programming interfaces (APIs), and being considered as a B2B solution, which allows the payment platform to represent a huge variety of payment methods in different locations all over the globe, and being transparent and more efficient to the customer in completing transactions.
Regarding claim 22, Arya, Piparsaniya, and REST API Reference disclose the limitations of claim 1. Arya and Piparsaniya do not specifically disclose, however, REST API Reference discloses the server of claim 1, wherein the one or more data type includes one or more of a payment mandate identifier, a customer identifier, and a merchant identifier (“Create Transaction – Body Params, wixTransactionId: Wix transaction ID; paymentMethod: Payment method supported by the payment provider. These values will be displayed to the end-user upon checkout and will be passed to the payment provider to understand what payment method a user selected on the Wix side. In case payment Method: creditCard field paymentMethodData will be initialized with card data; wixMerchantId: Wix merchant ID”).
REST API Reference discloses payment a provider SPI and APIs. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a payment provider SPI and APIs; as in REST API Reference; and to include processing recurring payment transactions, as in Piparsaniya, to improve and/or enhance the technology for determining and providing non-financial benefits on a subscription basis, as in Arya, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a payment platform comprising a service provider interface (SPI) being designed for deeper integration between the payment platform and external payment providers through application programming interfaces (APIs), and being considered as a B2B solution, which allows the payment platform to represent a huge variety of payment methods in different locations all over the globe, and being transparent and more efficient to the customer in completing transactions.
Claims 3-8 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Arya et al (U. S. Patent No. 11386445 B1), herein referred to as Arya, in view of Piparsaniya et al (U. S. Patent No. 11392956 B2), herein referred to as Piparsaniya, in view of Authentication | REST API Reference | Wix.com (searchable link), herein referred to as REST API Reference, and in further view of Meredith et al (U. S. Patent No. 11004083 B2), herein referred to as Meredith.
Regarding claims 3 and 12, Arya, Piparsaniya, and REST API Reference disclose the limitations of claims 1 and 10. Arya, Piparsaniya, and REST API Reference do not specifically disclose, however, Meredith discloses the server of claim 1, wherein the operations further comprise:
receiving a revocation request for the payment mandate (FIG. 1B, 3, items 110, 116A, 116B, 312, 350, 352; C/L 11/29-40, “… At a next stage (310), the consumer (140) transmits, to the remotely accessible server (110) an instruction to revoke one of the standing instructions. The remotely accessible server (110) may, similarly to the example described with reference to FIG. 2, require the consumer (140) to enter a PIN, passcode or passphrase before revoking the instruction at a next stage (312). The remotely accessible server (110) may receive the request to revoke a standing instruction at its revocation request component (116A), may revoke the instruction using its revoking component (116B), and may subsequently block relevant debits using the debit blocking component (116C) …”; C/L 11/52-67, “… The revoked instruction may … be a recurring direct debit transaction which the consumer (140) has approved on a previous occasion … the consumer (140) may have been satisfied with initial transaction details, such as a debit amount and debit dates provided, and proceeded to approve the transaction at an initial stage, but now wishes to revoke the recurring direct debit due to the fact that, over time, changes in the debit amount or frequency of debits which were not agreed upon between the consumer (140) and the merchant have taken place … the consumer (140) may wish to revoke a standing instruction because the consumer (140) never agreed to it being set up in the first place, or because the consumer (140) was hoodwinked into agreeing to the direct debit, or for any other suitable reason. The consumer (140) may be required to supply a reason for wishing to revoke the debit …”); and
updating the payment mandate in the payment mandate data store to indicate that the payment mandate is revoked (FIG. 1B, 3, items 111, 113, 116C; C/L 11/41-51, “… the database (111) is updated so as to remove the instruction from the consumer record (113) … the database (111) is updated to indicate that the standing instruction has been revoked, and that in response to subsequent requests from a clearing entity to debit the financial account of the consumer on behalf of the merchant associated with the instruction revoked by the consumer (140), the request must be denied, a denial message must be generated using the blocking component (116C) and transmitted to the clearing entity, and optionally also to the electronic device (150) …”).
Meredith discloses authorizing direct debit transactions. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include authorizing direct debit transactions, as in Meredith; to include a payment provider SPI and APIs; as in REST API Reference; and to include processing recurring payment transactions, as in Piparsaniya, to improve and/or enhance the technology for determining and providing non-financial benefits on a subscription basis, as in Arya, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a method and a system providing protection for the consumer’s direct debits being used for conducting recurring financial transactions, avoiding a potential drawback of direct debits presenting the risk of an unscrupulous party inappropriately obtaining funds from an account of a consumer.
Regarding claim 4, Arya, Piparsaniya, and REST API Reference disclose the limitations of claim 1. Arya, Piparsaniya, REST API Reference, and Meredith disclose the limitations of claim 3. Arya, Piparsaniya, and REST API Reference do not specifically disclose, however, Meredith discloses the server of claim 3, wherein the revocation request is received from the merchant (C/L 13/12-19, “… Upon receiving this selection, the remotely accessible server updates a consumer record in the database to revoke any approval or denial given in respect of the debit, whatever the case may be … when the particular merchant wishes to collect funds from the consumer (402), the consumer ( 402) will be provided with an electronic prompt requesting the consumer (402) to confirm or deny the direct debit transaction, as more fully described above …”), and
wherein the operations further comprise transmitting a message to the payment provider indicating revocation of the payment mandate (FIG. 2, items 350, 352; C/L 12/1-17,”… At a future stage (350), after the standing direct debit instruction has been revoked, the clearing entity (130) may receive another direct debit request on behalf of the merchant associated with the revoked direct debit instruction. The remotely accessible server (110), at a next stage (352), receives the request and accesses the consumer record (113) to check whether instructions from the specific source have been revoked … the remotely accessible server (110) determines that the consumer (140) has revoked debits from the merchant and, at a next stage (354), denies the requested direct debit transaction. The remotely accessible server (110) may then proceed to notify the clearing entity (130) and the consumer (140) (on the electronic device (150) of the consumer (140)) that a direct debit request has been received from the particular merchant, and subsequently denied …”).
Meredith discloses authorizing direct debit transactions. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include authorizing direct debit transactions, as in Meredith; to include a payment provider SPI and APIs; as in REST API Reference; and to include processing recurring payment transactions, as in Piparsaniya, to improve and/or enhance the technology for determining and providing non-financial benefits on a subscription basis, as in Arya, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a mechanism to avoid the administrative steps needing to be completed in order to modify a direct debit instruction from being time consuming, and in some cases, not being allowed by an issuing or acquiring bank. Also, to avoid successfully canceling a single or recurring direct debit from being time consuming and/or cumbersome.
Regarding claim 5, Arya, Piparsaniya, and REST API Reference disclose the limitations of claim 1. Arya, Piparsaniya, REST API Reference, and Meredith disclose the limitations of claim 3. Arya, Piparsaniya, and REST API Reference do not specifically disclose, however, Meredith discloses the server of claim 3, wherein the revocation request is received from the payment provider (C/L 13/12-19, “… Upon receiving this selection, the remotely accessible server updates a consumer record in the database to revoke any approval or denial given in respect of the debit, whatever the case may be. Subsequently, when the particular merchant wishes to collect funds from the consumer (402), the consumer ( 402) will be provided with an electronic prompt requesting the consumer (402) to confirm or deny the direct debit transaction, as more fully described above …”), and
wherein the operations further comprise transmitting a message to the merchant indicating revocation of the payment mandate (FIG. 2, items 350, 352; C/L 12/1-17,”… At a future stage (350), after the standing direct debit instruction has been revoked, the clearing entity (130) may receive another direct debit request on behalf of the merchant associated with the revoked direct debit instruction. The remotely accessible server (110), at a next stage (352), receives the request and accesses the consumer record (113) to check whether instructions from the specific source have been revoked … the remotely accessible server (110) determines that the consumer (140) has revoked debits from the merchant and, at a next stage (354), denies the requested direct debit transaction. The remotely accessible server (110) may then proceed to notify the clearing entity (130) and the consumer (140) (on the electronic device (150) of the consumer (140)) that a direct debit request has been received from the particular merchant, and subsequently denied …”).
Meredith discloses authorizing direct debit transactions. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include authorizing direct debit transactions, as in Meredith; to include a payment provider SPI and APIs; as in REST API Reference; and to include processing recurring payment transactions, as in Piparsaniya, to improve and/or enhance the technology for determining and providing non-financial benefits on a subscription basis, as in Arya, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a system and a method for account holders utilizing recurring payment transactions, periodically transmitting funds to a merchant through a series of payment vehicle-based transactions, with an adequate level of control by the account holder over the recurring payments, such as updating the billing parameters, optionally canceling future recurring payment transactions, etc., that is efficient and convenient for the account holder.
Regarding claims 6 and 13, Arya, Piparsaniya, and REST API Reference disclose the limitations of claims 1 and 10. Arya, Piparsaniya, REST API Reference, and Meredith disclose the limitations of claims 3 and 12. Arya, Piparsaniya, and REST API Reference do not specifically disclose, however, Meredith discloses the server of claim 3, wherein the operations further comprise:
receiving, from the merchant, a payment intent request associated with the customer (FIG. 2, item 206; C/L 7/44-67, “… The clearing entity (130) receives the direct debit file and determines which of the requests must be transmitted to the remotely accessible server (110) … only the debit requests addressed to the mobile banking system associated with the issuer (160) are, at a next stage (204), forwarded to the remotely accessible server (110). At a next stage (206), the remotely accessible server (110) receives the direct debit request. The request may be received at its clearing request component (112A). The request is a request to conduct a direct debit transaction against the financial account of the consumer (140), and prompts the remotely accessible server (110) to debit a financial account of the consumer (140) on behalf of a specific merchant (180). If the request is in the form of a batch request, the remotely accessible server (110) may identify various financial accounts which are to be debited. Upon receiving the direct debit request, the remotely accessible server (110) accesses the consumer record (113) of the consumer (140) in question, which is stored in the database (111), and checks whether the consumer (140) has previously approved a debit of the financial account on behalf of the same merchant (180). The database (111) may be checked using the checking component (112B) of the debit authorization module (112) …”);
determining, the payment mandate in the payment mandate data store is revoked (C/L 10/4-26, “… At a next stage (230), the clearing entity (130) receives a notification from the remotely accessible server (110) indicating that the request to debit the financial account has been denied. The acquirer (120), at a final stage (232), is then not permitted to credit the account held by the merchant (180). Correspondingly, the account of the consumer is not debited. The method of authorizing a direct debit as described above therefore provides a way of ensuring that a direct debit, and particularly a recurring payment, has been properly authorized before deducting any funds from the financial account of a consumer. If the consumer approves an initial direct debit transaction on behalf of a particular merchant, the database may be updated to indicate that upon subsequent requests from a clearing entity to conduct a direct debit transaction against the financial account of the consumer on behalf of the same merchant, a debit authorization message is to be generated and transmitted to the clearing entity … in response to the consumer indicating denial of the debit or failing to respond to the electronic prompt within a predetermined period, the database may be updated to revoke any previous approval that may have been given in respect of the debit …”); and
transmitting a response to the merchant indicating that the payment intent request is rejected (C/L 12/1-17, “… At a future stage (350), after the standing direct debit instruction has been revoked, the clearing entity (130) may receive another direct debit request on behalf of the merchant associated with the revoked direct debit instruction. The remotely accessible server (110), at a next stage (352), receives the request and accesses the consumer record (113) to check whether instructions from the specific source have been revoked … the remotely accessible server (110) determines that the consumer (140) has revoked debits from the merchant and, at a next stage (354), denies the requested direct debit transaction. The remotely accessible server (110) may then proceed to notify the clearing entity (130) and the consumer (140) (on the electronic device (150) of the consumer (140)) that a direct debit request has been received from the particular merchant, and subsequently denied …”).
Meredith discloses authorizing direct debit transactions. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include authorizing direct debit transactions, as in Meredith; to include a payment provider SPI and APIs; as in REST API Reference; and to include processing recurring payment transactions, as in Piparsaniya, to improve and/or enhance the technology for determining and providing non-financial benefits on a subscription basis, as in Arya, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide systems and methods for recurring billing arrangements, that offer a certain level of convenience for the account holder when making repetitive purchases of a service or product, in avoiding the difficulties often encountered when modifying or terminating the recurring billing arrangement.
Regarding claim 7, Arya, Piparsaniya, and REST API Reference disclose the limitations of claim 1. Arya, Piparsaniya, REST API Reference, and Meredith disclose the limitations of claim 3. Arya further discloses the server of claim 3, wherein the operations further comprise receiving a delegation request from the payment provider to delegate the payment mandate, the delegation request comprising the payment mandate identifier (FIG. 2, item 208; C/L 19/25-39, “… At 208, the provider computing system 104 opens a subscription account … if the customer has requested a new account, the provider computing system 104 opens a new subscription account for the customer and … transfers a certain amount of money provided by the customer into the new subscription account … if the customer has requested that an existing account be converted into the subscription account, the provider computing system converts the customer's existing account in to a subscription account and rolls over the customer's existing balance into the converted subscription account. In embodiments where the customer has selected a subscription tier at, the new subscription account is opened with benefits depending on the tier that the customer selected …”).
Regarding claim 8, Arya, Piparsaniya, and REST API Reference disclose the limitations of claim 1. Arya, Piparsaniya, REST API Reference, and Meredith disclose the limitations of claims 3 and 7. Arya further discloses the server of claim 7, wherein the operations further comprise:
authenticating the customer (FIG. 2, item 204; C/L 18/39-48, “… At 204, the provider computing system 104 verifies that the customer meets criteria for the subscription account … the criteria may include a certain level of risk that the customer meets or is below (e.g., based on the customer's credit score and financial history), a minimum balance that the customer needs to maintain in the subscription account, and so on … the provider computing system 104 may offer the customer a subscription account with different terms based on whether the customer meets various account criteria thresholds …”); and
transmitting a delegation response to the payment provider that the customer has been authenticated (FIG. 2, item 208; C/L 19/25-39, “… At 208, the provider computing system 104 opens a subscription account … if the customer has requested a new account, the provider computing system 104 opens a new subscription account for the customer and … transfers a certain amount of money provided by the customer into the new subscription account … if the customer has requested that an existing account be converted into the subscription account, the provider computing system converts the customer's existing account in to a subscription account and rolls over the customer's existing balance into the converted subscription account. In embodiments where the customer has selected a subscription tier at 206, the new subscription account is opened with benefits depending on the tier that the customer selected …”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Hazlehurst (U. S. Patent No. 9129268 B2) – Directing Payments To Satisfy Periodic Financial Obligations
Hazlehurst recites methods, computer program products, and systems, related to financial payments. Data corresponding to payments made by a first financial institution is analyzed to identify periodic financial obligations and a specific biller associated with each obligation. A visual user interface including a mechanism through which a user can submit a make-payments notification is generated and provided to a client computer. A first make-payments notification identifying an obligation and a specific biller is received. A determination is made as to whether the specific biller is automatically requesting payments to satisfy the obligation identified in the make-payments notification, and if so, a cease-billing instruction is caused to be sent to the specific biller. A billing instruction, instructing the first specific biller to automatically request payments from a second financial institution to satisfy the obligation, is caused to be sent to the first specific biller.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN CHISM whose telephone number is (571) 272-5915. The examiner can normally be reached during 9:00 AM – 3:00 PM Monday – Thursday, 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, Ryan D. Donlon can be reached (570) 272-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEVEN R CHISM/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692
June 3, 2026
Prosecution Insights