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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on May 11, 2026 has been entered.
Claim Status
As of the Office Action dated February 11, 2026 claims 1-22 and 24 were pending and claims 1-22 and 24 stood rejected. Claims 1, 18 and 24 have been amended. Claims 25 and 26 have been added. No claims have been cancelled. Claims 1-22 and 24-26 are therefore currently pending and are presented for examination on the merits.
Claim Interpretation
Claim 1 recites the term “arbitration process”. The term is also present in claims 12, 13, 18, 24 and 26. In reviewing Applicant’s written disclosure at paragraphs 0024, 0137 and 0139 no description is present with regard to what Applicant views as actually being an arbitration process as it is not described with any particular operations or steps but is simply being used as a generic placeholder term to link functional language. Therefore the term will be given only negligible patentable weight and for purposes of determining what constitutes prior art that reads on the claim any prior art teaching the functional language will be viewed as reading on the term arbitration process.
Response to Arguments
Applicant’s argument with regard to the 35 U.S.C. § 103 rejection(s) of claims 1-22 and 24 has been fully considered but is moot in view of the new ground(s) of rejection. However the Applicant makes numerous errors in the arguments that Examiner must address. With regard to section A.1 the argument is directed towards Hummer and is therefore moot although Examiner would comment that Applicant’s written description does not specify what constitutes a “value authority algorithm” anywhere in the four corners of the written description which only describes the value authority algorithm in a manner such that it can be thought of as no more than an idea of an algorithm. The claim itself is only claiming operations that occur “via the payment portal” which does not require that the payment portal actually institute the operation but only that the operation happen through the payment portal (not “by the payment portal” as the title of section A.1. states). Therefore the argument is not persuasive as it is not commensurate with the scope of the actual claim when read in light of the written description.
With regard to section A.2.(a-c) Examiner would point out that the language regarding the “operating independently of the buyer and the merchant” is nothing more than a simple assertion lacking in clarity. Examiner would point out that when the only parties in the claim as recited are the buyer, the merchant and the value authority and that the value authority is performing an arbitration process if the arbitration is being performed “independently of the buyer and the merchant” that a question in claim interpretation would arise, the question being exactly who are the parties in the arbitration process if not the buyer and the merchant which are the only parties who have been named in the claim? Given the extreme breadth of the claim and the absence of any clear description of the terms including any definitions Applicant is arguing that a narrow interpretation of the terms in the claim be made that is not rooted in the claim itself or the written description. Therefore the argument is not persuasive as it is not commensurate with the scope of the actual claim when read in light of the written description.
With regard to section A.3. this argument is moot in light of the new grounds of rejection. However Examiner would also point out that Applicant clearly does not understand what constitutes teaching away as it requires an actual statement in a reference that a solution be unsuitable in order to make it inappropriate to form a combination and not merely describe a different environment.
With regard to section A.4. this argument is moot in light of the new grounds of rejection.
With regard to section A.5. the argument is moot in light of the new grounds of rejection however Examiner would point out that all of the cited references are in the field of payments or finance and those of ordinary skill would deem that they are in the same field of art. Therefore this argument is unpersuasive.
With regard to section A.6. this argument is moot in light of the new grounds of rejection.
With regard to section A.7. this argument is moot in light of the new grounds of rejection. However it should also be pointed out that the interpretation of the claim in light of the written description is proper and Applicant’s argument are not commensurate with the scope of the claim and are therefore unpersuasive.
With regard to section A.8. this argument is moot in light of the new grounds of rejection.
With regard to section B this argument relies on the alleged deficiencies of Hummer and is therefore moot in view of the new grounds of rejection.
With regard to section C the argument relies on alleged deficiencies of Douglas and a claim interpretation that are is not actually required by the claim nor even clearly taught by Applicant’s written description. The payment portal is simply a nonce term and has not been described with anything other than functional language and the claim itself does not include any references to known structure such that the separation between the elements is clear. As such the broadest reasonable interpretation of the claim is far greater in scope than Applicant’s argument. Therefore the argument is not commensurate with the scope of the claim.
With regard to section D the argument relies on alleged deficiencies of Daniels and a claim interpretation that are is not actually required by the claim nor are they even taught by Applicant’s written description. The payment portal is simply a nonce term and has not been described with anything other than functional language and the claim itself does not include any references to known structure such that the separation between the elements is clear. As such the broadest reasonable interpretation of the claim is far greater in scope than Applicant’s argument. Therefore the argument is not commensurate with the scope of the claim.
With regard to section E with regard to the Cella reference the argument relies on the “independently” language of claim 1 that has been held as deficient. Therefore as this argument has been held as being unpersuasive the same rationale applies here for deeming the argument to be insufficient.
Section F is directed towards independent claims 18 and 24 and relies on the same deficient arguments previously stated with regard to claims 1-17. Therefore these arguments are also not persuasive.
Applicant’s argument with regard to the 35 U.S.C. § 101 rejection of claims 1-22 and 24-26 has been fully considered but is not persuasive. Applicant is not applying the accepted test from MPEP § 2106 but is mixing portions of elements and the abstract idea in order to assert that the claims are directed towards an eligible invention. As the argument is not applying the actual test from MPEP § 2106 but is simply creating a rationale entirely divorced from the MPEP the argument is not persuasive.
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-22 and 24-26 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claim 1 recites a method and therefore meets eligibility Step 1 of the patent subject matter eligibility guidelines (MPEP § 2106.03) as a method falls within one of the four categories of statutory subject matter.
The analysis then proceeds to Prong One of Eligibility Step 2A in which the claim is evaluated in order to determine whether the claim is directed towards a judicial exception (MPEP § 2106.04(1)(A)(1)). The claim recites determining transaction information, selecting a payment algorithm to be used in determining a payment amount to be paid by the buyer for the transaction and selecting a value authority algorithm to identify a value authority to be used in selecting a commercial value for a variable term to be associated with and/or included as part of the payment amount. Determining payment transaction information that includes merchant identifying information and payment information is both a fundamental economic practice (MPEP § 2106.04(a)(2)(II)(A) and an operation that can be viewed as a mental process (MPEP § 2106.04(a)(2)(III)(B) as human beings have determined payees and amounts due in bookkeeping processes prior to the invention of a computer. With regard to selecting a payment algorithm in reviewing the written disclosure at paragraph 0052 provides the recited examples of payment algorithms that include “…a buyer-initiated card payment (BICP) transaction, another payment algorithm 180 for processing a ghost card payment, another payment algorithm 180 for processing a single use card payment, another payment algorithm 180 for processing a gateway payment, another payment algorithm 180 for processing a third party processor payment, another payment algorithm 180 for processing a tokenized payment, etc.” which given the nature of the options would appear to require following the protocols that would be required to service a user selected payment card in conjunction with the merchant processing the transaction which is also a fundamental economic practice. The value authority is described in paragraph 0137 as being a “…trusted authority or the like that is operable to verify facts, check standards, and otherwise report information without dependence on parties to the transaction” and paragraph 0137 further recites an example where the value authority algorithm “…may be configured for identifying the value authority 32, or multiple value authorities 32 for separately determining one or more of the variable terms, as an independent entity, i.e., a service, the reporting agency, etc., operating independently of the buyer 105 and the merchant 160” and per the examples in paragraphs 0137-0139 would include tracking exchange rates, interest rates and other variables along with “…assessing if-then statements, hypotheticals, etc. for purposes of making a determination on one or more commercial values to be relatedly included when settling the transaction”. Selecting value authorities for reliable (and trusted) information for data such as prevailing interest rates, currency exchange rates, and prices for assets is also a fundamental economic practice. Therefore under Prong One of Step 2A claim 1 is deemed as being directed towards ineligible subject matter.
The analysis then proceeds to Prong Two of Step 2A in which the claim is evaluated in order to determine whether the claim recites additional elements sufficient to form a practical application of the abstract idea (MPEP § 2106.04(d)(I)). The claim recites that the method is performed via a computing device having a payment portal which is described in paragraphs 0066 and 0123-0125 in a manner that suggests that these are general purpose computing components. No technological improvement to the functioning of a computer is recited in the claim, nor is there any technological improvement being made to any other technology or technological field. Even if the selecting steps were viewed as elements there is no underlying algorithm for performing the selection described in the written disclosure as the selection process is not described in any particular detail and involves only a concept of the selection process. The step of determining transaction information associated with a transaction between a buyer and a merchant, the transaction information including merchant identifying information and payment information are mere instructions to apply the abstract idea (MPEP § 2106.05(f)). The recitation regarding the payment portal including a plurality of algorithms only describes a particular technological environment in which the claim operates (MPEP § 2106.05(h)) but it should also be pointed out that as the written description does not actually recite any actual recitation of algorithms but only the idea that a plurality of algorithms are present that the recitation can also be categorized as also being mere instructions to implement the abstract idea (MPEP § 2106.05(f)). The recitation regarding the selecting, via the payment portal and using the merchant identifying information and/or the payment information, a payment algorithm of the algorithms to be used in determining a payment amount to be paid by the buyer for the transaction can also be viewed as being mere instructions to implement the abstract idea (MPEP § 2106.05(f)) along with the selection of a payment algorithm as the written description does not actually teach any algorithms but only describes a plurality of algorithms at a conceptual level such that the selection is nothing more than the expression of an idea. The operation of selecting, via the payment portal and using the merchant identifying information and/or the payment information, a value authority algorithm of the algorithms to identify a value authority operating independently of the buyer and the merchant to be used in selecting a commercial value for a variable term through an arbitration process to be associated with and/or included as part of the payment amount can also be viewed as being mere instructions to implement the abstract idea (MPEP § 2106.05(f)) as the value authority algorithm is not described in the written description either by name or by actual operations but only describes the idea of a value authority algorithm and the value authority itself is not described in any particular detail and can be viewed as being nothing more than a concept as the value authority is described as a “clearinghouse, a dispute resolution services, or other independent or third-party entity operating outside of the buyer and/or the merchant with capabilities for arbitrating, weighing, or otherwise comparatively analyzing a wide variety of contracted parameters for purposes of selecting, adjusting, adding, removing, or otherwise manipulating terms, fees, and/or payment amounts associated with a transaction” (paragraph 0022). The operation of “transmitting, via the payment portal and using the value authority algorithm, a variable request to the value authority, the variable request including one or more variable selection parameters specifying at least one of a time frame for a time-dependent variable and conditions or rules for a condition-dependent variable, the variable selection parameters instructing the value authority to select the commercial value based thereon” can be viewed as both insignificant extra-solution activity as it only recites outputting data (MPEP § 2106.05(g)) but can also be viewed as being mere instructions to apply the abstract idea as the time frame and conditions or rules appear to be used in establishing terms and conditions for a loan (paragraph 0135) and are therefore used as part of implementing commercial activity. Therefore under Prong Two of Step 2A claim 1 is deemed as being directed towards ineligible subject matter.
The analysis then proceeds to Step 2B in which the claim is evaluated in order to determine whether the claim recites additional elements that form an inventive concept of the abstract idea (MPEP § 2106.05(d)(I)). The claim recites that the method is performed via a computing device having a payment portal which is described in paragraphs 0066 and 0123-0125 in a manner that suggests that these are general purpose computing components. No technological improvement to the functioning of a computer is recited in the claim, nor is there any technological improvement being made to any other technology or technological field. Even if the selecting steps were viewed as elements there is no underlying algorithm for performing the selection described in the written disclosure as the selection process is not described in any particular detail and involves only a concept of the selection process. The transmitting operation involves use of a network such as the Internet as described in paragraphs 0044 and 0065 and therefore falls under subject matter that has been held by the courts to involve nothing more than well-understood, routine and conventional activity (MPEP § 2106.05(d)). Therefore under Step 2B claim 1 is deemed as being directed towards ineligible subject matter.
Dependent claims 2-17 and 25 only extend the abstract idea of claim 1 as claim 2 recites compiling a settlement output where the compiling operation is not described in any detail but is reciting only the idea of an outcome. Claim 3-17 and 25 are directed either towards data gathering and outputting data or in the case of the parsing of claim 4, the exporting of claims 5 and 6 and the importing of claim 7 like claim 2 only recite an operation that is directed towards the idea of an outcome. No additional elements are present that would alter the analysis of Steps 2A and 2B. Therefore claims 2-17 and 25 are also deemed as being directed towards ineligible subject matter.
Claim 18 recites a method and therefore meets eligibility Step 1 of the patent subject matter eligibility guidelines (MPEP § 2106.03) as a method falls within one of the four categories of statutory subject matter.
The analysis then proceeds to Prong One of Eligibility Step 2A in which the claim is evaluated in order to determine whether the claim is directed towards a judicial exception (MPEP § 2106.04(1)(A)(1)). The claim recites accessing a buyer accounts payable system to retrieve transaction information, selecting a payment algorithm to be used in determining a payment amount, compiling a settlement output and transmitting a payment authorization request. Accessing an accounts payable system to retrieve transaction information is both a fundamental economic practice (MPEP § 2106.04(a)(2)(II)(A) and an operation that can be viewed as a mental process (MPEP § 2106.04(a)(2)(III)(B) as human beings have determined payees and amounts due in bookkeeping processes prior to the invention of a computer. With regard to selecting a payment algorithm in reviewing the written disclosure at paragraph 0052 provides the recited examples of payment algorithms that include “…a buyer-initiated card payment (BICP) transaction, another payment algorithm 180 for processing a ghost card payment, another payment algorithm 180 for processing a single use card payment, another payment algorithm 180 for processing a gateway payment, another payment algorithm 180 for processing a third party processor payment, another payment algorithm 180 for processing a tokenized payment, etc.” which given the nature of the options would appear to require following the protocols that would be required to service a user selected payment type in conjunction with the merchant processing the transaction which is also a fundamental economic practice. Compiling a settlement output per paragraph 0141 would appear to involve a form of packaging the data including the payment amount and the terms which can include “…each of the fees, penalties, rates, terms, conditions, and other particularities of the transaction that may need to be settled, which may be collectively referred to as transaction details” although no details are provided with regard to how the compiling is formed and therefore can be viewed as both a fundamental economic practice (MPEP § 2106.04(a)(2)(II)(A) and a mental process (MPEP § 2106.04(a)(2)(III)(B) as human beings have combined amounts and terms in settlement agreements prior to the invention of a computer. Selecting a value authority algorithm to identify a value authority to be used in determining a time varying term and/or a condition dependent term which Examiner is interpreting as a form of requesting an interest rate value from a publisher of an index or alternatively requesting loan terms is both a fundamental economic practice and an operation that can be performed mentally. Transmitting a payment authorization request is also a fundamental economic practice. Therefore under Prong One of Step 2A claim 18 is deemed as being directed toward ineligible subject matter.
The analysis then proceeds to Prong Two of Step 2A in which the claim is evaluated in order to determine whether the claim recites additional elements sufficient to form a practical application of the abstract idea (MPEP § 2106.04(d)(I)). The claim recites that the method is performed via a computing device having a payment portal which is described in paragraphs 0066 and 0123-0125 in a manner that suggests that these are general purpose computing components. No technological improvement to the functioning of a computer is recited in the claim, nor is there any technological improvement being made to any other technology or technological field. Even if the selecting and compiling steps were viewed as elements there is no underlying algorithm for performing the selection or compiling described in the written disclosure as the selection process and compiling process are not described in any particular detail and involves only a concept and amounts to mere instructions to apply the abstract idea. The claim recites “…accessing, via a computing device having a payment portal, a buyer accounts payable (AP) system of a buyer to retrieve transaction information, the transaction information relating to a transaction between the buyer and a merchant, the transaction information including merchant identifying information and payment information, the payment portal including a plurality of algorithms” which can be viewed as both mere insignificant extra-solution activity as the claim is reciting both data gathering (MPEP § 2106.05(g)) which is being performed as part of commercial activity and therefore can also be viewed as mere instructions to implement the abstract idea (MPEP § 2106.05(g)). The recitation regarding the selecting, via the payment portal and using the merchant identifying information and/or the payment information, a payment algorithm of the algorithms to be used in determining a payment amount to be paid by the buyer for the transaction can also be viewed as being mere instructions to implement the abstract idea (MPEP § 2106.05(f)) along with the selection of a payment algorithm as the written description does not actually teach any algorithms but only describes a plurality of algorithms at a conceptual level such that the selection is nothing more than the expression of an idea. The operation of “…compiling, via the payment portal and using a settlement algorithm of the algorithms, a settlement output to define settlement terms for settling the transaction, the settlement terms including the payment amount” can be viewed as mere instructions to apply the abstract idea (MPEP § 2106.05(f)) as the settlement terms are simply terms for a loan or other commercial exchange (paragraph 0135). The operation of “…selecting, via the payment portal and using the merchant identifying information and/or the payment information, a value authority algorithm of the algorithms to identify a value authority operating independently of the buyer and the merchant to be used in determining a time varying term and/or a condition dependent term through an arbitration process for inclusion in the settlement output, wherein the time varying term and/or the condition dependent term are associated with and/or included as part of the payment amount” can be viewed as mere instructions to apply the abstract idea (MPEP § 2106.05(f)) as the operation is essentially enlisting an entity to broker a loan and the algorithm is only described in a manner that can be viewed as nothing more than a concept or idea of an algorithm as opposed to a clear teaching of an actual algorithm. The operation of “…transmitting, via the payment portal and using the value authority algorithm, a variable request to the value authority, the variable request including one or more variable selection parameters specifying at least one of a time frame for a time-dependent variable and conditions or rules for a condition-dependent variable, the variable selection parameters instructing the value authority to select the commercial value based thereon” can be viewed as both insignificant extra-solution activity as it only recites outputting data (MPEP § 2106.05(g)) but can also be viewed as being mere instructions to apply the abstract idea as the time frame and conditions or rules appear to be used in establishing terms and conditions for a loan (paragraph 0135) and are therefore used as part of implementing commercial activity. The operation of “…transmitting, via the payment portal and based on the settlement output, a payment authorization request to request a payment application provider and/or an issuer to settle the transaction according to the settlement terms” can be viewed as both insignificant extra-solution activity as it only recites outputting data (MPEP § 2106.05(g)) but can also be viewed as being mere instructions to apply the abstract idea as the time frame and conditions or rules appear to be used in establishing terms and conditions for a loan (paragraph 0135) and are therefore used as part of implementing commercial activity. The transmitting operations involve use of a network such as the Internet as described in paragraphs 0044 and 0065 and therefore falls under subject matter that has been held by the courts to involve nothing more than well-understood, routine and conventional activity (MPEP § 2106.05(d)). Therefore under Prong Two of Step 2A claim 18 is deemed as being directed towards ineligible subject matter.
The analysis then proceeds to Step 2B in which the claim is evaluated in order to determine whether the claim recites additional elements that form an inventive concept of the abstract idea (MPEP § 2106.05(d)(I)). The claim recites that the method is performed via a computing device having a payment portal which is described in paragraphs 0066 and 0123-0125 in a manner that suggests that these are general purpose computing components. No technological improvement to the functioning of a computer is recited in the claim, nor is there any technological improvement being made to any other technology or technological field. Even if the selecting and compiling steps were viewed as elements there is no underlying algorithm for performing the selection or compiling described in the written disclosure as the selection process and compiling process are not described in any particular detail and involves only a concept and amounts to mere instructions to apply the abstract idea. Therefore under Step 2B claim 18 is deemed as being directed towards ineligible subject matter.
Dependent claims 19-22 only extend the abstract idea of claim 18 as claims 19-23 are directed either towards data gathering and outputting data or in the case of the parsing of claim 19, the exporting of claims 20 and 21 and the importing of claim 22 only recite an operation that is directed towards the idea of an outcome. No additional elements are present that would alter the analysis of Steps 2A and 2B. Therefore claims 19-22 are also deemed as being directed towards ineligible subject matter.
Claim 24 is also directed towards a method and merely combines limitations from claims 1 and 18 without adding any elements. Therefore the claim is also directed towards an abstract idea and as no new elements are added the results of the analysis under Steps 2A and 2B would not change. Claim 26 adds no elements that would alter the analysis. Therefore claims 24 and 26 are deemed as being directed towards ineligible subject matter.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-22 and 24-26 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1 recites “…selecting, via the payment portal and using the merchant identifying information and/or the payment information, a payment algorithm of the algorithms to be used in determining a payment amount to be paid by the buyer for the transaction”. Claims 18 and 24 contain similar recitations. MPEP § 2161.01 is directed towards the requirements for computer programming and computer implemented inventions and imposes additional requirements for the written description under 35 U.S.C. § 112(a) and Pre-AIA 35 U.S.C. § 112, first paragraph that are supplemental to those described in MPEP § 2163. In reviewing Applicant’s written disclosure Examiner notes that while the written disclosure recites in multiple instances “a plurality of payment algorithms” or similar language referencing an unspecified payment algorithm (at least at paragraphs 0013, 0052, 0076, 0091, 0134) no actual payment algorithm is actually taught or suggested within the written description. MPEP § 2161.01 imposes two requirements with regard to computer implemented inventions. The first requirement relates to the claiming of a genus. As noted in MPEP § 2161.01 problems satisfying the written description requirement for original claims often occur when claim language is generic or functional, or both. Ariad, 593 F.3d at 1349, 94 USPQ2d at 1171 ("The problem is especially acute with genus claims that use functional language to define the boundaries of a claimed genus. In such a case, the functional claim may simply claim a desired result, and may do so without describing species that achieve that result. But the specification must demonstrate that the applicant [inventor] has made a generic invention that achieves the claimed result and do so by showing that the applicant [inventor] has invented species sufficient to support a claim to the functionally-defined genus”). The issue that is present with the written description in this instance is that the use of language non-specific recitations such as “a payment algorithm of the plurality of algorithms” or simply “a payment algorithm” are not descriptions of actual algorithms but only express the idea of an algorithm or algorithms without sufficient description to support the claiming of the genus (or any sub-genus) of a plurality of algorithms or the species “a payment algorithm” and clearly the claim is broad enough in scope to read on any payment algorithm, present or future. As noted in MPEP § 2161.01 “…generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed. Ariad, 598 F.3d at 1349-50, 94 USPQ2d at 1171 ("[A]n adequate written description of a claimed genus requires more than a generic statement of an invention’s boundaries.") (citing Eli Lilly, 119 F.3d at 1568, 43 USPQ2d at 1405-06); Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement because it failed to support the scope of the genus claimed); Fiers v. Revel, 984 F.2d 1164, 1170, 25 USPQ2d 1601, 1606 (Fed. Cir. 1993) (rejecting the argument that "only similar language in the specification or original claims is necessary to satisfy the written description requirement"). The Federal Circuit has explained that a specification cannot always support expansive claim language and satisfy the requirements of 35 U.S.C. 112 "merely by clearly describing one embodiment of the thing claimed." LizardTech v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1346, 76 USPQ2d 1731, 1733 (Fed. Cir. 2005). The issue is whether a person skilled in the art would understand the inventor to have invented, and been in possession of, the invention as broadly claimed. In LizardTech, claims to a generic method of making a seamless discrete wavelet transformation (DWT) were held invalid under 35 U.S.C. 112, first paragraph, because the specification taught only one particular method for making a seamless DWT and there was no evidence that the specification contemplated a more generic method. "[T]he description of one method for creating a seamless DWT does not entitle the inventor . . . to claim any and all means for achieving that objective." LizardTech, 424 F.3d at 1346, 76 USPQ2d at 1733. Here no species has been disclosed that would establish possession of any embodiment as the written description only provides support on a conceptual level and therefore clearly constitutes the basis for indicating that the written description provides insufficient support for the claiming of what the claim recites as a “payment algorithm of the plurality of the algorithms to be used in determining a payment amount”. Furthermore with regard to the second requirement of MPEP § 2161.01 the claim merely recites an obtained result (determining a payment amount to be paid by the buyer) without any clear teaching as to how the result is obtained. It should also be pointed out that the particular claim limitation recites selecting a payment algorithm which given the absence of any disclosed algorithms also must be held as lacking in support as the written description recites only the idea of a plurality of algorithms while no actual algorithms are specified. As such claims 1, 18 and 24 are rejected under the written description requirement.
Claim 1 recites “…selecting, via the payment portal and using the merchant identifying information and/or the payment information, a value authority algorithm of the algorithms to identify a value authority operating independently of the buyer and merchant to bet used in selecting a commercial value for a variable term through an arbitration process to be associated with and/or included as part of the payment amount”. Claims 18 and 24 contain similar recitations. Claims 8, 9, 12, 13 and 25 also recite the term “value authority algorithm”. MPEP § 2161.01 is directed towards the requirements for computer programming and computer implemented inventions and imposes additional requirements for the written description under 35 U.S.C. § 112(a) and Pre-AIA 35 U.S.C. § 112, first paragraph that are supplemental to those described in MPEP § 2163. In reviewing Applicant’s written disclosure Examiner notes that while the written disclosure recites in multiple instances “a value authority algorithms of the algorithms” or similar language referencing an unspecified value authority algorithm (at least at paragraphs 0022, 0137) no actual value authority algorithm is fairly taught or suggested within the written description. MPEP § 2161.01 imposes two requirements with regard to computer implemented inventions. The first requirement relates to the claiming of a genus. As noted in MPEP § 2161.01 problems satisfying the written description requirement for original claims often occur when claim language is generic or functional, or both. Ariad, 593 F.3d at 1349, 94 USPQ2d at 1171 ("The problem is especially acute with genus claims that use functional language to define the boundaries of a claimed genus. In such a case, the functional claim may simply claim a desired result, and may do so without describing species that achieve that result. But the specification must demonstrate that the applicant [inventor] has made a generic invention that achieves the claimed result and do so by showing that the applicant [inventor] has invented species sufficient to support a claim to the functionally-defined genus”). The issue that is present with the written description in this instance is that the use of language “a plurality of payment algorithms” and non-specific recitations such as “a payment algorithm of the plurality of algorithms” along with a “value authority algorithm” are not descriptions of actual algorithms but only express the idea of an algorithm or algorithms without sufficient description to support the claiming of the genus (or any sub-genus) of payment algorithms or plurality of algorithms and clearly the claim is broad enough in scope to read on any payment algorithm, present or future. As noted in MPEP § 2161.01 “…generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed. Ariad, 598 F.3d at 1349-50, 94 USPQ2d at 1171 ("[A]n adequate written description of a claimed genus requires more than a generic statement of an invention’s boundaries.") (citing Eli Lilly, 119 F.3d at 1568, 43 USPQ2d at 1405-06); Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement because it failed to support the scope of the genus claimed); Fiers v. Revel, 984 F.2d 1164, 1170, 25 USPQ2d 1601, 1606 (Fed. Cir. 1993) (rejecting the argument that "only similar language in the specification or original claims is necessary to satisfy the written description requirement"). The Federal Circuit has explained that a specification cannot always support expansive claim language and satisfy the requirements of 35 U.S.C. 112 "merely by clearly describing one embodiment of the thing claimed." LizardTech v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1346, 76 USPQ2d 1731, 1733 (Fed. Cir. 2005). The issue is whether a person skilled in the art would understand the inventor to have invented, and been in possession of, the invention as broadly claimed. In LizardTech, claims to a generic method of making a seamless discrete wavelet transformation (DWT) were held invalid under 35 U.S.C. 112, first paragraph, because the specification taught only one particular method for making a seamless DWT and there was no evidence that the specification contemplated a more generic method. "[T]he description of one method for creating a seamless DWT does not entitle the inventor . . . to claim any and all means for achieving that objective." LizardTech, 424 F.3d at 1346, 76 USPQ2d at 1733. Here no species has been disclosed that would establish possession of any embodiment as the written description only provides support on a conceptual level and therefore clearly constitutes the basis for indicating that the written description provides insufficient support for the claiming of what the claim recites as a “value authority algorithm of the plurality of the algorithms to identify a value authority operating independently of the buyer and the merchant to be used in selecting a commercial value for a variable term through an arbitration process to be associated with and/or included as part of the payment amount”. Furthermore with regard to the second requirement of MPEP § 2161.01 the claim merely recites an obtained result (identify a value authority operating independently of the buyer and the merchant to be used in selecting a commercial value for a variable term through an arbitration process to be associated with and/or included as part of the payment amount) without any clear teaching as to how the result is obtained as the written description only states the presence of an arbitration algorithm and an arbitration process but does state anything beyond the conceptual level. It should also be pointed out that the particular claim limitation recites selecting a value authority algorithm which given the absence of any disclosed algorithms also must be held as lacking in support as the written description recites only the idea of a plurality of algorithms while no actual algorithms are specified. As such claims 1, 8, 9, 12, 13, 18, 24 and 25 are rejected under the written description requirement.
Claim 2 recites “...compiling, via the payment portal and using a settlement algorithm of the algorithms, a settlement output to define settlement terms for settling the transaction, the settlement terms including the payment amount and the variable term”. Claims 18 and 24 contain similar recitations and claim 26 also recites the settlement algorithm. The written description does not actually teach any settlement algorithm but only describes the algorithm in a conceptual manner i.e. the idea of a settlement algorithm without an actual teaching of a settlement algorithm. Therefore claims 2, 18, 24 and 26 are rejected under the written description requirement.
Claim 4 recites “…parsing, in the computer device and using a reporting algorithm of the algorithms, the response to determine one or more transaction details included with the response, the transaction details including an indication of whether the payment application provider and/or the issuer approved or denied the payment authorization request”. Claim 19 contains similar language. The written description does not actually teach any reporting algorithm but only describes the algorithm in a conceptual manner i.e. the idea of a reporting algorithm without an actual teaching of a reporting algorithm. Therefore claims 4 and 19 are rejected under the written description requirement.
Claim 5 recites “…exporting via the payment portal and using an exporting algorithm of the algorithms, the transaction details into a buyer accounts payable (AP) system of the buyer and/or a merchant accounts receivable (AR) system of the merchant, the transaction details imported including the payment amount, the commercial value for the variable term, and the indication”. Claims 6, 20 and 21 contain similar language. The written description does not actually teach any exporting algorithm but only describes the algorithm in a conceptual manner i.e. the idea of a exporting algorithm without an actual teaching of a exporting algorithm. Therefore claims 5, 6, 20 and 21 are rejected under the written description requirement.
Claim 7 recites “…autonomously importing, via the payment portal and using an importing algorithm of the algorithms, the transaction information from the buyer AP system automatically according to a predefined schedule and/or occurrence of a triggering event”. Claim 22 contains a similar recitation. The written description does not actually teach any importing algorithm but only describes the algorithm in a conceptual manner i.e. the idea of an importing algorithm without an actual teaching of an importing algorithm. Therefore claims 7 and 22 are rejected under the written description requirement.
Claim 15 recites “…receiving, via the payment portal and using a portal rules algorithm of the algorithms, the rules based on one or more buyer rules input thereto by the buyer and/or a buyer system of the buyer and/or one or more rules input thereto by the merchant and or a merchant system of the merchant”. The written description does not actually teach any portal rules algorithm but only describes the algorithm in a conceptual manner i.e. the idea of an portal rules algorithm without an actual teaching of an portal rules algorithm. Therefore claim 15 is rejected under the written description requirement.
Claim 16 recites “…generating, in the computer device and using a rules arbitration algorithm of the algorithms, the rules based on one or more buyer rules stored at a buyer rules system of the buyer and/or one or more merchant rules stored at a merchant rules system of the merchant, including accessing the buyer and/or merchant servers, via the payment portal, to retrieve the buyer and/or merchant rules”. Claim 17 also recites the “rules arbitration algorithm. The written description does not actually teach any rules arbitration algorithm but only describes the algorithm in a conceptual manner i.e. the idea of an rules arbitration algorithm without an actual teaching of an rules arbitration algorithm. Therefore claims 16 and 17 are rejected under the written description requirement.
Claim 26 recites “…compiling, via the payment portal and using the settlement algorithm, the settlement output to define the settlement terms such that the settlement terms further include a time stamp at which the value authority selected the commercial value through the arbitration process.” The written disclosure does not make any mention of a time stamp and Applicant did not indicate in remarks where support for claim 26 could be found. Therefore claim 26 represents the introduction of new subject matter.
Claims 2-17 and 25 are also rejected as being dependent upon claim 1.
Claims 19-22 are also rejected as being dependent upon claim 18.
Claim 26 is also rejected as being dependent upon claim 24.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-22 and 24-26 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “…selecting, via the payment portal and using the merchant identifying information and/or the payment information, a payment algorithm of the algorithms to be used in determining a payment amount to be paid by the buyer for the transaction”. Claims 18 and 24 also recite the term. In reviewing Applicant’s written description no definition of the term “payment algorithm” is provided and the term does not have any established meaning in the art. Paragraph 0052 ties the “payment algorithm” to various operations and other forms of functional language but it is unclear what Applicant is referring to when using the term “payment algorithm” as there is no actual algorithm that associates the term with the described operations which for example include buyer-initiated card payment, single use card payment, gateway payment, etc. Therefore the scope of the term is unclear.
Claim 1 recites “…selecting, via the payment portal and using the merchant identifying information and/or the payment information, a value authority algorithm of the algorithms to identify a value authority operating independently of the buyer and the merchant to be used in determining a time varying term and/or a condition dependent term through an arbitration process for inclusion in the settlement output, wherein the time varying term and/or the condition dependent term are associated with and/or included as part of the payment amount”. Claims 18 and 24 contain similar language. The language with regard to the arbitration process does not indicate who is participating in the arbitration process and it is noted that paragraph 0024 of the written disclosure recites “The value authority may thereafter perform an arbitration process whereby compliance with the buyer and merchant rules may be assessed, with the condition dependent fee being subsequently determined based on the outcome of the arbitration.” If the arbitration process is tasked with being in “compliance with the buyer and merchant rules” it is clear that the arbitration process is not completely “independent” of the buyer and the merchant and therefore the value authority that is implementing the arbitration process cannot be viewed as being completely independent of the buyer and the merchant and the word “independently” in this context must be viewed as a term of degree where the extent of the degree is unclear. The written disclosure does not provide any further context such that those of ordinary skill would be able to understand how to interpret the term “independently” given that the claim clearly requires merchant identifying information and/or the payment information supplied by one of or both of the buyer and the merchant, no clear structure can be associated with the value authority and the arbitration process performed by the value authority per paragraph 0024 must be compliant with buyer and merchant rules. Therefore claims 1, 18 and 24 are held as being indefinite.
Claim 1 recites “…selecting, via the payment portal and using the merchant identifying information and/or the payment information, a value authority algorithm of the algorithms to identify a value authority operating independently of the buyer and the merchant to be used in determining a time varying term and/or a condition dependent term through an arbitration process for inclusion in the settlement output, wherein the time varying term and/or the condition dependent term are associated with and/or included as part of the payment amount”. Claims 18 and 24 contain similar language. The terms “value authority algorithm” and “value authority” are newly introduced terms that lack any clear definition as is required by MPEP § 2173.05(a)(I). No clear definition of the term “value authority” is present in the written description and the term is only defined by oblique functional language including being identified by an undescribed value authority algorithm which itself is not clearly defined along with the arbitration module configured for executing an arbitration process that apparently requires no external participants per the claim as the claim now recites that the value authority operates independently of the buyer and the merchant which are the only other members present in the claim. Therefore claims 1, 18 and 24 are held as being indefinite.
Claim 3 recites “…transmitting, via the payment portal and based on the settlement output, a payment authorization request to request a payment application provider and/or an issuer to settle the transaction according to the settlement terms, the payment application provider and the issuer operating independently of the buyer and the merchant”. The language “independently of the buyer and the merchant” is a term of degree as an issuer must clearly have operations involving both the buyer and the merchant as the issuer interfaces with the buyer through both card issuance and account maintenance and the issuer interfaces with the merchant by reimbursing payment claims made by the merchant through the merchant’s acquiring bank. Neither the claim nor the written description explain what is meant by the “operating independently of the buyer and the merchant” language such that the scope of the claim is clear.
Claim 6 recites “…autonomously exporting, via the payment portal and using the exporting algorithm, the transaction details to the buyer AP system and/or the merchant AR system automatically according to a predefined schedule and/or occurrence of a triggering event”. Claim 21 contains a similar recitation. The term “autonomously” is a term of degree and the written disclosure at paragraphs 0021 and 0143 merely repeats the claim language which is insufficient to explain the modification being made to the exporting operation such that the claim is sufficiently clear in scope. Therefore claim 6 is rejected as being indefinite.
Claim 7 recites “…autonomously importing, via the payment portal and using an importing algorithm of the algorithms, the transaction information from the buyer AP system automatically according to a predefined schedule and/or occurrence of a triggering event”. Claim 22 contains a similar recitation. The term “autonomously” is a term of degree and the written disclosure at paragraphs 0021 and 0132 merely repeats the claim language which is insufficient to explain the modification being made to the importing operation such that the claim is sufficiently clear in scope. Therefore claim 7 is rejected as being indefinite.
Claim 8 recites “…transmitting, via the payment portal and using the value authority algorithm, a time dependent variable request to the value authority, the time dependent variable request requesting the value authority to determine the commercial value independently of the buyer and the merchant based on a time frame associated with the time dependent variable request”. The language “independently of the buyer and the merchant” is a term of degree as an issuer must clearly have operations involving both the buyer and the merchant as the issuer interfaces with the buyer through both card issuance and account maintenance and the issuer interfaces with the merchant by reimbursing payment claims made by the merchant through the merchant’s acquiring bank. Neither the claim nor the written description at paragraphs 0023, 0135 and 0138 explain what is meant by the “operating independently of the buyer and the merchant” language such that the scope of the claim is clear. Therefore claim 8 is held as being indefinite.
Claims 2-17 and 25 are also rejected as being dependent upon claim 1.
Claims 19-22 are also rejected as being dependent upon claim 18.
Claim 26 is also rejected as being dependent upon claim 24.
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 (i.e., changing from AIA to pre-AIA ) 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.
Claims 1, 2, 8 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Leavitt et al. (U.S. Patent Publication 2020/0134609, hereinafter referred to as Leavitt) in view of Anderson (U.S. Patent Publication 2022/0398585).
As per claim 1
Leavitt discloses determining, via a computing device having a payment portal, transaction information associated with a transaction between a buyer and a merchant, the transaction information including merchant identifying information and payment information, the payment portal including a plurality of algorithms (Abstract “The payment message is parsed using a first parsing algorithm to obtain merchant identifying information. The merchant identifying information is associated with at least a second parsing algorithm or at least one settlement algorithm. The payment message is parsed using the second parsing algorithm to obtain payment information for the transaction”)
Leavitt discloses selecting, via the payment portal and using the merchant identifying information and/or the payment information, a payment algorithm of the algorithms to be used in determining a payment amount to be paid by the buyer for the transaction (0012 “selecting, via the payment portal and using the at least one of the merchant identifying information and the payment information, a selected payment algorithm from the plurality of payment algorithms where the selected payment algorithm is associated in the payment portal with at least one of the merchant identifying information and the payment information, and where the payment information includes a payment amount to be paid by the buyer to the seller”)
Leavitt does not explicitly disclose selecting, via the payment portal and using the merchant identifying information and/or the payment information, a value authority algorithm of the algorithms to identify a value authority to be used in selecting a commercial value for a variable term to be associated with and/or included as part of the payment amount. Anderson teaches selecting, via the payment portal and using the merchant identifying information and/or the payment information, a value authority algorithm of the algorithms to identify a value authority to be used in selecting a commercial value for a variable term to be associated with and/or included as part of the payment amount (0256 “Referring now to FIG. 11, a flowchart 1100 of a method for providing an opportunity for a customer to replace a debit card payment with a one-time loan at a point of sale POS is disclosed in accordance with an embodiment.”, 0257 “In one embodiment, the customer is identified by information taken from level 1, level 2, and/or other levels that may exist such as level 3 (or other yet to be defined levels) that are included in the debit card (or credit card) transaction information obtained during the debit card's interaction with the POS (e.g., the swipe, chip, NFC [such as for virtual payments, from a payment from a bank app on a user's mobile device, from a mobile wallet payments, or the like]).”, 0260 “The most basic and common type of bank card transaction is the level 1 transaction. In one embodiment, some of the basic data fields used to complete a level 1 bank card transaction include a merchant name, a customer's billing zip code, and a transaction amount. In one embodiment, additional information, such as the date and time of the transaction and additional cardholder information is automatically recorded by the bank but isn't explicitly reported by the merchant processing the transaction”, 0267 “If the customer attempts to perform the transaction with a debit card (e.g., a card tied to a customer's bank account), and the customer qualifies for a one-time loan in the amount defined by the purchase price, then the customer can be offered (from the customer facing device) a one-time loan. The offer can include loan amount, pay-off schedule, an APR, and the like. In one embodiment, the offer could include incentives such as no interest for the first x-months, breaking the total down into a number of monthly payments with only a single upfront fee (e.g., 5 dollars or 1% of the transaction whichever is greater), allowing the customer to select the number of monthly payments, and the like.”, 0274 “In one embodiment, the loan amount and payment 1104, will also include an optional opportunity for the customer to change the default one-time loan terms and conditions, the interest rate, any grace period information, the breakdown of payments, and the like.”)
Anderson teaches transmitting, via the payment portal and using the value authority algorithm, a variable request to the value authority, the variable request including one or more variable selection parameters specifying at least one of a time frame for a time-dependent variable and conditions or rules for a condition-dependent variable, the variable selection parameters instructing the value authority to select the commercial value based thereon (0274 “In one embodiment, the loan amount and payment 1104, will also include an optional opportunity for the customer to change the default one-time loan terms and conditions, the interest rate, any grace period information, the breakdown of payments, and the like.”, 0278 “If the customer accepts the reduced term 1107a conditions and any additional terms and conditions that are included therewith, then the customer will move to the one-time loan acceptance 11010 and the transaction will be completed with the provider of the one-time loan paying for the transaction instead of the customer's debit card”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson for the purpose of establishing and building upon a customer-payment provider relationship. (Anderson at paragraph 0031).
As per claim 2
Anderson teaches compiling, via the payment portal and using a settlement algorithm of the algorithms, a settlement output to define settlement terms for settling the transaction, the settlement terms including the payment amount and the variable term (0281 “For example, if the customer would like to make monthly payments of 50 dollars toward the one-time loan, the customer would select the 50 dollar payment option and the modified loan terms would be presented to the customer at modified payment schedule 1108a.”, 0282 “If the customer accepts the modified payment schedule 1108a conditions and any additional terms and conditions that are included in the loan, then the customer will move to the one-time loan acceptance 11010 and the transaction will be completed with the provider of the one-time loan paying for the transaction instead of the customer's debit card.”, 0283 “Similarly, if the customer would like to make 10 monthly payments on the one-time loan, the customer would select the 10 months of payments option and the modified loan terms will be presented to the customer at modified payment schedule 1108a. In one embodiment, when the customer chooses to pay back the loan over a selected number of month that are longer than the default number of months, the loan fee would be increased by a defined amount and presented to the customer along with the terms and conditions. For example, the amount of the one-time loan would be 520 dollars (e.g., 500 dollars+10 dollar fee+10 dollars interest). Since the customer has selected a loan term of 10 months, the monthly payment would be 52 dollars per month.”, 0284 “If the customer accepts the modified payment schedule 1108a conditions and any additional terms and conditions that are included in the loan, then the customer will move to the one-time loan acceptance 11010 and the transaction will be completed with the provider of the one-time loan paying for the transaction instead of the customer's debit card.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson for the purpose of establishing and building upon a customer-payment provider relationship. (Anderson at paragraph 0031).
As per claim 8
Anderson teaches transmitting, via the payment portal and using the value authority algorithm, a time dependent variable request to the value authority, the time dependent variable request requesting the value authority to determine the commercial value independently of the buyer and the merchant based on a time frame associated with the time dependent variable request (0281 “For example, if the customer would like to make monthly payments of 50 dollars toward the one-time loan, the customer would select the 50 dollar payment option and the modified loan terms would be presented to the customer at modified payment schedule 1108a.”, 0282 “If the customer accepts the modified payment schedule 1108a conditions and any additional terms and conditions that are included in the loan, then the customer will move to the one-time loan acceptance 11010 and the transaction will be completed with the provider of the one-time loan paying for the transaction instead of the customer's debit card.”, 0283 “Similarly, if the customer would like to make 10 monthly payments on the one-time loan, the customer would select the 10 months of payments option and the modified loan terms will be presented to the customer at modified payment schedule 1108a. In one embodiment, when the customer chooses to pay back the loan over a selected number of month that are longer than the default number of months, the loan fee would be increased by a defined amount and presented to the customer along with the terms and conditions. For example, the amount of the one-time loan would be 520 dollars (e.g., 500 dollars+10 dollar fee+10 dollars interest). Since the customer has selected a loan term of 10 months, the monthly payment would be 52 dollars per month.”, 0284 “If the customer accepts the modified payment schedule 1108a conditions and any additional terms and conditions that are included in the loan, then the customer will move to the one-time loan acceptance 11010 and the transaction will be completed with the provider of the one-time loan paying for the transaction instead of the customer's debit card.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson for the purpose of establishing and building upon a customer-payment provider relationship. (Anderson at paragraph 0031).
As per claim 25
Anderson teaches generating, in the computer device and using the merchant identifying information, the payment information and/or the value authority algorithm, two or more variable selection parameters to be included with the variable request, the variable selection parameters specifying both a time frame for a time-dependent variable and conditions or rules for a condition-dependent variable, and instructing the value authority to select the commercial value based on both (0274 “In one embodiment, the loan amount and payment 1104, will also include an optional opportunity for the customer to change the default one-time loan terms and conditions, the interest rate, any grace period information, the breakdown of payments, and the like.”, 0278 “If the customer accepts the reduced term 1107a conditions and any additional terms and conditions that are included therewith, then the customer will move to the one-time loan acceptance 11010 and the transaction will be completed with the provider of the one-time loan paying for the transaction instead of the customer's debit card”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson for the purpose of establishing and building upon a customer-payment provider relationship. (Anderson at paragraph 0031).
Claims 3 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Leavitt in view of Anderson as applied to claim 2 above, and further in view of Douglas et al. (U.S. Patent Publication 2025/0259176, hereinafter referred to as Douglas).
As per claim 3
Neither Leavitt nor Anderson explicitly teaches transmitting, via the payment portal and based on the settlement output, a payment authorization request to request a payment application provider and/or an issuer to settle the transaction according to the settlement terms, the payment application provider and the issuer operating independently of the buyer and the merchant. Douglas teaches transmitting, via the payment portal and based on the settlement output, a payment authorization request to request a payment application provider and/or an issuer to settle the transaction according to the settlement terms, the payment application provider and the issuer operating independently of the buyer and the merchant (0023 “Ecosystem 100 also includes lender 104, which may comprise a credit card provider, a line of credit provider, or a bank and/or a service provider. In some embodiments, lender 104 may comprise a payment service network. For example, an acquiring bank may receive payment authorization requests from a source and send them to an issuing bank (which may include, or be a separate entity from, the acquiring bank). The acquiring bank may then relay a response from the issuing bank to the source. In some embodiments, the acquiring bank may be a third-party entity. The acquiring bank may provide a service or device that allows a source to accept credit cards as well as send credit card payment details to a network. Upon receipt, the network may forward the payment authorization to the acquiring bank”, 0025 “The receiver (e.g., receiver 106), which may be a merchant, may accept credit card payments, debits against a line of credit, etc. Receiver 106 may also send credit, debit instructions, and/or user account information to, and request payment authorization from, an issuing bank corresponding to the self-executing program (or a line of credit related to the self-executing program)”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson further with the variable self-executing programs of Douglas for the purpose of more easily and efficiently interact with legacy (e.g., non-blockchain) systems (0003).
As per claim 4
Douglas teaches receiving, via the payment portal, a response to the payment authorization request from the payment application provider and/or the issuer (0024 “An issuing bank may receive a payment authorization request from the credit card network and either approve or decline the transaction”)
Douglas teaches parsing, in the computer device and using a reporting algorithm of the algorithms, the response to determine one or more transaction details included with the response, the transaction details including an indication of whether the payment application provider and/or the issuer approved or denied the payment authorization request (0024 “An issuing bank may receive a payment authorization request from the credit card network and either approve or decline the transaction”, 0045 “Issuers' authorization decisions would be made through a rule set based on the first on-chain rule configuration function that would approve or decline based on their credit, fraud, etc., policies. Oracles 108 may enforce these policies and/or may use on-chain rule set based on the first on-chain rule configurations for performing anti-money laundering and/or know-your-customer checks on the receiver/seller. Rule set based on the first on-chain rule configuration may also include the capability to set a time period to reclaim payments (for chargebacks or re-bills due to disputes/fraud). For example, the system may determine an encoded instruction for the rule set based on the first on-chain rule configuration, wherein the encoded instruction causes a time period for use of or a specific use of the self-executing program. Approved authorizations would trigger the transfer of funds from the issuer's wallet to the receiver's/seller's wallet”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson further with the variable self-executing programs of Douglas for the purpose of more easily and efficiently interact with legacy (e.g., non-blockchain) systems (0003).
Claims 5, 6 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Leavitt in view of Anderson in view of Douglas as applied to claim 4 above, and further in view of Daniels (Canada Publication CA 3214827 A1).
As per claim 5
Leavitt in view of Anderson and Douglas disclose the limitations of claim 4 including the transaction details including the payment amount and the commercial value for the variable term (Anderson as above at 0260) and the indication (Douglas as above at 0024, 0045), but do not explicitly disclose exporting, via the payment portal and using an exporting algorithm of the algorithms, the transaction details into a buyer accounts payable (AP) system of the buyer and/or a merchant accounts receivable (AR) system of the merchant. Daniels teaches exporting the transaction details into a buyer accounts payable (AP) system of the buyer and/or a merchant accounts receivable (AR) system of the merchant (Page 13 lines 3-17) “By way of example, when the instant technology is employed in the financial industry, electronic resource management systems 108a and 108b through 108n are capable of maintaining event data associated with a payment (e.g., due date, payment amount, or entity to which the payment is rendered) similar to enterprise resource planning systems (e.g., as provided by Oracle , SAP , or the like) or accounting software (e.g., as provided by QuickBooks , Quicken , or the like). The electronic resource management system may thus provide a software application platform for maintaining or manipulating data associated with a general ledger, fixed assets, account payable, account receivable, cash management, financial consolidation, or the like. In some embodiments, the electronic resource management systems 108a and 108b through 108n maintains event data providing an indication of whether the resource transfer associated with the event is an inbound resource and/or an outbound resource. The inbound resource may be a resource that will be received by a particular user and/or user device at the scheduled time. The outbound resource may be a resource that will be transferred by a particular user and/or user device at a scheduled time”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson with the variable self-executing programs of Douglas further with the rerouting resources for management platforms of Daniel for the purpose of storing data about inbound resources to be received and about outbound resources to be transferred (page 3 line 30 through page 4 line 2).
As per claim 6
Daniels teaches autonomously exporting, via the payment portal and using the exporting algorithm, the transaction details to the buyer AP system and/or the merchant AR system automatically according to a predefined schedule and/or occurrence of a triggering event (page 3 line 24 through page 4 line 2 “For example and as further described herein, a first and second electronic resource management system may store data about an event. The event may be a future transfer of resources between one or more users and/or one or more user devices (both of which may be referred to as an entity). Event data for the event may include data for the amount of resources (or indication of resources) that will be transferred, a scheduled time for transferring the resources, the entities involved in the resource transfer, or other information about event. More particularly, the first electronic resource management system may store data about inbound resources to be received and the second electronic resource management system may store data about outbound resources to be transferred”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson with the variable self-executing programs of Douglas further with the rerouting resources for management platforms of Daniel for the purpose of storing data about inbound resources to be received and about outbound resources to be transferred (page 3 line 30 through page 4 line 2).
As per claim 7
Daniels teaches autonomously importing, via the payment portal and using an importing algorithm of the algorithms, the transaction information from the buyer AP system automatically according to a predefined schedule and/or occurrence of a triggering event (page 3 line 24 through page 4 line 2 “For example and as further described herein, a first and second electronic resource management system may store data about an event. The event may be a future transfer of resources between one or more users and/or one or more user devices (both of which may be referred to as an entity). Event data for the event may include data for the amount of resources (or indication of resources) that will be transferred, a scheduled time for transferring the resources, the entities involved in the resource transfer, or other information about event. More particularly, the first electronic resource management system may store data about inbound resources to be received and the second electronic resource management system may store data about outbound resources to be transferred”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson with the variable self-executing programs of Douglas further with the rerouting resources for management platforms of Daniel for the purpose of storing data about inbound resources to be received and about outbound resources to be transferred (page 3 line 30 through page 4 line 2).
Claims 9-17 are rejected under 35 U.S.C. 103 as being unpatentable over Leavitt in view of Anderson as applied to claims 1 and 8 above, and further in view of Cella et al. (U.S. Patent Publication 2023/0206329, hereinafter referred to as Cella).
As per claim 9
Leavitt in view of Anderson, while disclosing the limitations of claim 8, do not explicitly disclose generating, in the computer device and using the merchant identifying information, the payment information and/or the value authority algorithm, one or more variable selection parameters to be included with the time dependent variable request, the variable selection parameters specifying the time frame and instructing the value authority to select the commercial value based thereon. Cella teaches generating, in the computer device and using the merchant identifying information, the payment information and/or the value authority algorithm, one or more variable selection parameters to be included with the time dependent variable request, the variable selection parameters specifying the time frame and instructing the value authority to select the commercial value based thereon (3203 “Here, one type of payment detail that the wallet system 23350 may coordinate or control is the type of currency that is exchanged and/or when the exchange involving an enterprise digital asset occurs using a particular currency. Determining the type of currency or the timing of a transaction with a particular currency may allow the wallet system 23350 to have another approach to optimize value for a transaction. For instance, the value of different types of currencies is capable of fluctuating based on market conditions. That is, conversion rates or exchanges rates may be determined by a floating rate that depends on market forces of supply and demand for foreign exchange or a fixed rate. Due to the fluctuation of conversion rates, the timing of when a transaction occurs can dictate the buying power or selling power of an asset. To illustrate, if the United States Dollar (USD) has an exchange rate greater than one with respect to the British Pound, then the USD, at that time has greater buying power than when the USD has an exchange rate less than one with respect to the United Kingdom Pound. In other words, with a ratio over one, the USD gets a greater return in British Pound than with a ratio less than one. Therefore, if a transaction for a US enterprise 23200 was going to occur in British Pounds (e.g., with a British market participant), the wallet system 23350 may track the conversation rates and/or facilitate the execution of the transaction at a time within a particular transaction window (i.e., a permitted time period to execute the transaction) that is most advantageous to the US enterprise (e.g., when the USD has the greatest buying power). To facilitate such activity, the EAL system may access a set of predictions of currency conversion rates, such as one generated based on market factors, such as economic data for respective jurisdictions, central bank interest rates, and the like”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson with the transaction platform of Cella for the purpose of optimizing a transaction involving a currency exchange (3203).
As per claim 10
Cella teaches prompting the value authority, via the variable selection parameters, to select the commercial value according to a currency exchange rate published and/or tracked by the value authority or a third party for a period of time corresponding with the time frame (3203 “Here, one type of payment detail that the wallet system 23350 may coordinate or control is the type of currency that is exchanged and/or when the exchange involving an enterprise digital asset occurs using a particular currency. Determining the type of currency or the timing of a transaction with a particular currency may allow the wallet system 23350 to have another approach to optimize value for a transaction. For instance, the value of different types of currencies is capable of fluctuating based on market conditions. That is, conversion rates or exchanges rates may be determined by a floating rate that depends on market forces of supply and demand for foreign exchange or a fixed rate. Due to the fluctuation of conversion rates, the timing of when a transaction occurs can dictate the buying power or selling power of an asset. To illustrate, if the United States Dollar (USD) has an exchange rate greater than one with respect to the British Pound, then the USD, at that time has greater buying power than when the USD has an exchange rate less than one with respect to the United Kingdom Pound. In other words, with a ratio over one, the USD gets a greater return in British Pound than with a ratio less than one. Therefore, if a transaction for a US enterprise 23200 was going to occur in British Pounds (e.g., with a British market participant), the wallet system 23350 may track the conversation rates and/or facilitate the execution of the transaction at a time within a particular transaction window (i.e., a permitted time period to execute the transaction) that is most advantageous to the US enterprise (e.g., when the USD has the greatest buying power). To facilitate such activity, the EAL system may access a set of predictions of currency conversion rates, such as one generated based on market factors, such as economic data for respective jurisdictions, central bank interest rates, and the like”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson with the transaction platform of Cella for the purpose of optimizing a transaction involving a currency exchange (3203).
As per claim 11
Cella teaches prompting the value authority, via the variable selection parameters, to select the commercial value according to an interest rate published and/or tracked by the value authority or a third party for a period of time corresponding with the time frame (1435 “Present and predicted value for the collateral 4802 or assets may be based on a model, which may be accessed and used, such as in a smart contract 3431, to enable automated, or machine-assisted lending on the collateral or assets, such as the underwriting or offering of a microloan on the collateral 4802 or assets. Aggregation of data for a set of collateral 4802 or set of assets, such as a collection or fleet of collateral 4802 or fleet of assets owned by an entity 3330 may allow real time portfolio valuation and larger scale lending, including via smart contracts 3431 that automatically adjust interest rates and other terms and conditions based on the individual or aggregated value of collateral 4802 or assets based on real time condition monitoring and real-time market data collection and integration”, 1504 “Referring to FIG. 54, in embodiments, a lending platform is provided having a smart contract system 3431 that automatically adjusts an interest rate for a loan based on information collected via at least one of an Internet of Things system, a crowdsourcing system, a set of social network analytic services and a set of data collection and monitoring services. The platform 4800 may include an interest rate automation solution 4924 that may include a set of interfaces, workflows, and models (which may include, use or be enabled by various adaptive intelligent systems layers 3304) and other components that are configured to enable automation of the setting of interest rates based on a set of conditions, which may include smart contract 3431 terms and conditions, marketplace conditions (of platform marketplaces and/or external marketplaces 3390), conditions monitored by monitoring system layers 3306 and data collection systems 3318, and the like (such as of entities 3330, including without limitation parties 4910, collateral 4802 and assets 4918, among others). For example, a user of the interest rate automation solution 4924 may set (such as in a user interface) rules, thresholds, model parameters, and the like that determine, or recommend, an interest rate for a loan based on the above, such as based on interest rates available to the lender from secondary lenders, risk factors of the borrower (including predicted risk based on one or more predictive models using artificial intelligence 3448), or the system may automatically recommend or set such rules, thresholds, parameters and the like (optionally by learning to do so based on a training set of outcomes over time). Interest rates may be determined based on marketing factors (such as competing interest rates offered by other lenders). Interest rates may be calculated for new loans, for modifications of existing loans, for refinancing, for foreclosure situations (e.g., changing from secured loan rates to unsecured loan rates), and the like.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson with the transaction platform of Cella for the purpose of adjusting terms of a loan based on rates based on marketplace conditions (1504).
As per claim 12
Leavitt in view of Anderson, while disclosing the limitations of claim 1, do not explicitly disclose transmitting, via the payment portal and using the value authority algorithm, a condition dependent variable request to the value authority, the condition dependent variable request for requesting the value authority to perform an arbitration process to dynamically determine the commercial value. Cella teaches transmitting, via the payment portal and using the value authority algorithm, a condition dependent variable request to the value authority, the condition dependent variable request for requesting the value authority to perform an arbitration process to dynamically determine the commercial value (0432 “The term smart contract services (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a smart contract service includes any service or application that manages a smart contract or a smart lending contract. For example, the smart contract service may specify terms and conditions of a smart contract, such as in a rules database, or process output from a set of valuation services and assign items of collateral sufficient to provide security for a loan. Smart contract services may automatically execute a set of rules or conditions that embody the smart contract, wherein the execution may be based on or take advantage of collected data. Smart contract services may automatically initiate a demand for payment of a loan, automatically initiate a foreclosure process, automatically initiate an action to claim substitute or backup collateral or transfer ownership of collateral, automatically initiate an inspection process, automatically change a payment, or interest rate term that is based on the collateral, and may also configure smart contracts to automatically undertake a loan-related action. Smart contracts may govern at least one of loan terms and conditions, loan-related events, and loan-related activities. Smart contracts may be agreements that are encoded as computer protocols and may facilitate, verify, or enforce the negotiation or performance of a smart contract. Smart contracts may or may not be one or more of partially or fully self-executing, or partially or fully self-enforcing”, 0479 “For example, a borrower may negotiate an interest rate or loan terms with a lender. In another example, a borrower in default may negotiate an alternative resolution to avoid foreclosure with a lender. In certain embodiments, a smart contract circuit or robotic process automation system may negotiate for one or more of the parties, and process appropriate tasks for completing or attempting to complete a negotiation of terms”, 0522 “The term smart contract (and other forms or variations) as utilized herein may be understood broadly to describe a method, system, connected resource or wide area network offering one or more resources useful to assist or perform actions, tasks or things by embodiments disclosed herein. A smart contract may be a set of steps or a process to negotiate, administrate, restructure, or implement an agreement or loan between parties”), 1426 “As with other embodiments described above in connection with sourcing innovation, product demand, or the like, a blockchain 3422, such as optionally embodying a distributed ledger, may be configured with a set of smart contracts 3431 to administer…an arbitration or mediation”, 1544 “Referring to FIG. 57, in embodiments, a lending platform is provided having a robotic process automation system 3442 for negotiation of a set of terms and conditions for a loan. The RPA system 3442 may provide automation for one or more aspects of a negotiation solution 4932 that enables automated negotiation and/or provides a recommendation or plan for a negotiation relevant to a lending transaction. The negotiation solution 4932 and/or RPA system 3442 for negotiation may include a set of interfaces, workflows, and models (which may include, use, or be enabled by various adaptive intelligent systems layers 3304) and other components that are configured to enable automation of one or more aspects of a negotiation of one or more terms and conditions of a lending transaction, such as based on a set of conditions, which may include smart contract 3431 terms and conditions, marketplace conditions (of platform marketplaces and/or external marketplaces 3390, conditions monitored by monitoring system layers 3306 and data collection systems 3318, and the like (such as of entities 3330, including without limitation parties 4910, collateral 4802 and assets 4918, among others)). For example, a user of the negotiation solution 4932 may create, configure (such as using one or more templates or libraries), modify, set, or otherwise handle (such as in a user interface of the negotiation solution 4932 and/or RPA system 3442) various rules, thresholds, conditional procedures, workflows, model parameters, and the like that determine, or recommend, a negotiation action or plan for a lending transaction negotiation based on one or more events, conditions, states, actions, or the like, where the negotiation plan may be based on various factors, such as prevailing market interest rates, interest rates available to the lender from secondary lenders, risk factors of the borrower, the lender, one or more guarantors, market risk factors, and the like (including predicted risk based on one or more predictive models using artificial intelligence 3448), status of debt, condition of collateral 4802 or assets 4918 used to secure or back a loan, state of a business or business operation (e.g., receivables, payables, or the like), conditions of parties 4910 (such as net worth, wealth, debt, location, and other conditions), behaviors of parties (such as behaviors indicating preferences, behaviors indicating negotiation styles), and many others. Negotiation may include negotiation of lending transaction terms and conditions, debt restructuring, foreclosure activities, setting interest rates, changes in interest rate, changes in priority of secured parties, changes in collateral 4802 or assets 4918 used to back or secure debt, changes in parties, changes in guarantors, changes in payment schedule, changes in principal balance (e.g., including forgiveness or acceleration of payments), and many other transactions or terms and conditions. In embodiments, the negotiation solution 4932 may automatically recommend or set rules, thresholds, actions, parameters, and the like (optionally by learning to do so based on a training set of outcomes over time), resulting in a recommended negotiation plan, which may specify a series of actions required to accomplish a recommended or desired outcome of negotiation (such as within a range of acceptable outcomes), which may be automated and may involve conditional execution of steps based on monitored conditions and/or smart contract terms, which may be created, configured, and/or accounted for by the negotiation plan. Negotiation plans may be determined and executed based at least one part on market factors (such as competing interest rates offered by other lenders, values of collateral, and the like) as well as regulatory and/or compliance factors. Negotiation plans may be generated and/or executed for creation of new loans, for creation of guarantees and security, for secondary loans, for modifications of existing loans, for refinancing, for foreclosure situations (e.g., changing from secured loan rates to unsecured loan rates), for bankruptcy or insolvency situations, for situations involving market changes (e.g., changes in prevailing interest rates), and others. In embodiments, adaptive intelligent systems layers 3304, including artificial intelligence 3448, may be trained on a training set of negotiation activities by experts and/or on outcomes of negotiation actions to generate a set of predictions, classifications, control instructions, plans, models, or the like for automated creation, management and/or execution of one or more aspects of a negotiation plan”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson with the transaction platform of Cella for the purpose of generating a set of predictions, classifications, control instructions, plans, models, or the like for automated creation, management and/or execution of one or more aspects of a negotiation plan (1544).
As per claim 13
Cella teaches generating, in the computer device and using the merchant identifying information, the payment information and/or the value authority algorithm, one or more condition selection parameters to be included with the condition dependent variable request for use in the arbitration process (1544 “Referring to FIG. 57, in embodiments, a lending platform is provided having a robotic process automation system 3442 for negotiation of a set of terms and conditions for a loan… For example, a user of the negotiation solution 4932 may create, configure (such as using one or more templates or libraries), modify, set, or otherwise handle (such as in a user interface of the negotiation solution 4932 and/or RPA system 3442) various rules, thresholds, conditional procedures, workflows, model parameters, and the like that determine, or recommend, a negotiation action or plan for a lending transaction negotiation based on one or more events, conditions, states, actions, or the like, where the negotiation plan may be based on various factors, such as prevailing market interest rates, interest rates available to the lender from secondary lenders, risk factors of the borrower, the lender, one or more guarantors, market risk factors, and the like (including predicted risk based on one or more predictive models using artificial intelligence 3448), status of debt, condition of collateral 4802 or assets 4918 used to secure or back a loan, state of a business or business operation (e.g., receivables, payables, or the like), conditions of parties 4910 (such as net worth, wealth, debt, location, and other conditions), behaviors of parties (such as behaviors indicating preferences, behaviors indicating negotiation styles), and many others. Negotiation may include negotiation of lending transaction terms and conditions, debt restructuring, foreclosure activities, setting interest rates, changes in interest rate, changes in priority of secured parties, changes in collateral 4802 or assets 4918 used to back or secure debt, changes in parties, changes in guarantors, changes in payment schedule, changes in principal balance (e.g., including forgiveness or acceleration of payments), and many other transactions or terms and conditions”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson with the transaction platform of Cella for the purpose of generating a set of predictions, classifications, control instructions, plans, models, or the like for automated creation, management and/or execution of one or more aspects of a negotiation plan (1544).
As per claim 14
Cella teaches prompting, via the condition dependent variable request, the value authority to determine the commercial value based at least in part on arbitrating one or more rules relative to one or more of the condition selection parameters, the rules having been agreed to by the buyer and the merchant prior to the transaction (3159 “For instance, in some configurations, some functionality of the wallet system 23350 may be performed by the data services system 23320 or functionality of the governance system 23360 may be incorporated with the intelligence system 23330. In this respect, the EAL systems may be representative of the capabilities of the EAL 23300 more broadly. In embodiments, the set of EAL systems involved in any particular configuration of the EAL 23300 may include any of the systems described throughout this disclosure and the documents incorporated by reference herein, such as systems for counterparty discovery, opportunity mining, automated contract configuration, automated negotiation, automated crowdsourcing, automated facilitation of robotic process automation, one or more intelligent agents, automated resource optimization, resource tracking, and others”, 3200 “In some implementations, in addition to the selection of the digital asset, the acquirer includes or selects details about the transaction for the digital asset. To illustrate, an exchanging party (e.g., one of the buyers 23112, one of the sellers 23114, or the enterprise 23200) may dictate their preferred payment method (e.g., selected from a list of payment methods that the merchant accepts) using the transaction facilitator. In some implementations, the details about the transaction include terms for the transaction, such as transfer terms (e.g., shipping terms), payment terms (e.g., net 30/60/90), interest terms, licensing terms, or other contract terms (e.g., representations and/or warranties). With the transaction details, the wallet system 23350 may be configured to orchestrate the transaction using a payment or transaction gateway”, 1544 “Referring to FIG. 57, in embodiments, a lending platform is provided having a robotic process automation system 3442 for negotiation of a set of terms and conditions for a loan… For example, a user of the negotiation solution 4932 may create, configure (such as using one or more templates or libraries), modify, set, or otherwise handle (such as in a user interface of the negotiation solution 4932 and/or RPA system 3442) various rules, thresholds, conditional procedures, workflows, model parameters, and the like that determine, or recommend, a negotiation action or plan for a lending transaction negotiation based on one or more events, conditions, states, actions, or the like, where the negotiation plan may be based on various factors, such as prevailing market interest rates, interest rates available to the lender from secondary lenders, risk factors of the borrower, the lender, one or more guarantors, market risk factors, and the like (including predicted risk based on one or more predictive models using artificial intelligence 3448), status of debt, condition of collateral 4802 or assets 4918 used to secure or back a loan, state of a business or business operation (e.g., receivables, payables, or the like), conditions of parties 4910 (such as net worth, wealth, debt, location, and other conditions), behaviors of parties (such as behaviors indicating preferences, behaviors indicating negotiation styles), and many others. Negotiation may include negotiation of lending transaction terms and conditions, debt restructuring, foreclosure activities, setting interest rates, changes in interest rate, changes in priority of secured parties, changes in collateral 4802 or assets 4918 used to back or secure debt, changes in parties, changes in guarantors, changes in payment schedule, changes in principal balance (e.g., including forgiveness or acceleration of payments), and many other transactions or terms and conditions”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson with the transaction platform of Cella for the purpose of generating a set of predictions, classifications, control instructions, plans, models, or the like for automated creation, management and/or execution of one or more aspects of a negotiation plan (1544).
As per claim 15
Cella teaches receiving, via the payment portal and using a portal rules algorithm of the algorithms, the rules based on one or more buyer rules input thereto by the buyer and/or a buyer system of the buyer and/or one or more merchant rules input thereto by the merchant and/or a merchant system of the merchant (0432 “The term smart contract services (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a smart contract service includes any service or application that manages a smart contract or a smart lending contract. For example, the smart contract service may specify terms and conditions of a smart contract, such as in a rules database”, 1544 “For example, a user of the negotiation solution 4932 may create, configure (such as using one or more templates or libraries), modify, set, or otherwise handle (such as in a user interface of the negotiation solution 4932 and/or RPA system 3442) various rules, thresholds, conditional procedures, workflows, model parameters, and the like that determine, or recommend, a negotiation action or plan for a lending transaction negotiation based on one or more events, conditions, states, actions, or the like, where the negotiation plan may be based on various factors, such as prevailing market interest rates, interest rates available to the lender from secondary lenders, risk factors of the borrower, the lender, one or more guarantors, market risk factors, and the like (including predicted risk based on one or more predictive models using artificial intelligence 3448), status of debt, condition of collateral 4802 or assets 4918 used to secure or back a loan, state of a business or business operation (e.g., receivables, payables, or the like), conditions of parties 4910 (such as net worth, wealth, debt, location, and other conditions), behaviors of parties (such as behaviors indicating preferences, behaviors indicating negotiation styles), and many others”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson with the transaction platform of Cella for the purpose of generating a set of predictions, classifications, control instructions, plans, models, or the like for automated creation, management and/or execution of one or more aspects of a negotiation plan (1544).
As per claim 16
Cella teaches generating, in the computer device and using a rules arbitration algorithm of the algorithms, the rules based on one or more buyer rules stored at a buyer rules system of the buyer and/or one or more merchant rules stored at a merchant rules system of the merchant, including accessing the buyer and/or merchant servers, via the payment portal, to retrieve the buyer and/or merchant rules (0432 “The term smart contract services (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a smart contract service includes any service or application that manages a smart contract or a smart lending contract. For example, the smart contract service may specify terms and conditions of a smart contract, such as in a rules database”, 1544 “For example, a user of the negotiation solution 4932 may create, configure (such as using one or more templates or libraries), modify, set, or otherwise handle (such as in a user interface of the negotiation solution 4932 and/or RPA system 3442) various rules, thresholds, conditional procedures, workflows, model parameters, and the like that determine, or recommend, a negotiation action or plan for a lending transaction negotiation based on one or more events, conditions, states, actions, or the like, where the negotiation plan may be based on various factors, such as prevailing market interest rates, interest rates available to the lender from secondary lenders, risk factors of the borrower, the lender, one or more guarantors, market risk factors, and the like (including predicted risk based on one or more predictive models using artificial intelligence 3448), status of debt, condition of collateral 4802 or assets 4918 used to secure or back a loan, state of a business or business operation (e.g., receivables, payables, or the like), conditions of parties 4910 (such as net worth, wealth, debt, location, and other conditions), behaviors of parties (such as behaviors indicating preferences, behaviors indicating negotiation styles), and many others”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson with the transaction platform of Cella for the purpose of generating a set of predictions, classifications, control instructions, plans, models, or the like for automated creation, management and/or execution of one or more aspects of a negotiation plan (1544).
As per claim 17
Cella teaches generating, in the computer device and using a rules arbitration algorithm of the algorithms, the rules based on one or more buyer rules specified in a buyer rules message transmitted from a buyer messaging server of the buyer and/or one or more merchant rules specified in a merchant rules message transmitted from a merchant messaging server of the merchant (2036 “In embodiments, the market orchestration system platform 20500 may leverage the intelligent services system 20243 (such as artificial intelligence system, RPA module and/or NLP module 8824) to automatically convert discussions into a smart contract. In embodiments, discussions may include email discussions, instant messaging and/or chat discussions, text messaging discussions, video conferencing discussions, phone call discussions, and many others. For example, an agreement captured in a video conference to keep the video conference discussion confidential may be captured and applied to the video conference discussion as a wrapper”)
Claims 18-22 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Daniels in view of Leavitt in view of Anderson and in view of Douglas.
As per claim 18
Daniels discloses accessing, via a computing device having a payment portal, a buyer accounts payable (AP) system of a buyer to retrieve transaction information, the transaction information relating to a transaction between the buyer and a merchant, the transaction information including merchant identifying information and payment information, the payment portal including a plurality of algorithms (Page 13 lines 3-17, “By way of example, when the instant technology is employed in the financial industry, electronic resource management systems 108a and 108b through 108n are capable of maintaining event data associated with a payment (e.g., due date, payment amount, or entity to which the payment is rendered) similar to enterprise resource planning systems (e.g., as provided by Oracle , SAP , or the like) or accounting software (e.g., as provided by QuickBooks , Quicken , or the like). The electronic resource management system may thus provide a software application platform for maintaining or manipulating data associated with a general ledger, fixed assets, account payable, account receivable, cash management, financial consolidation, or the like. In some embodiments, the electronic resource management systems 108a and 108b through 108n maintains event data providing an indication of whether the resource transfer associated with the event is an inbound resource and/or an outbound resource. The inbound resource may be a resource that will be received by a particular user and/or user device at the scheduled time. The outbound resource may be a resource that will be transferred by a particular user and/or user device at a scheduled time”).”).
Daniels does not explicitly disclose selecting, via the payment portal and using the merchant identifying information and/or the payment information, a payment algorithm of the algorithms to be used in determining a payment amount to be paid by the buyer for the transaction. Leavitt teaches selecting, via the payment portal and using the merchant identifying information and/or the payment information, a payment algorithm of the algorithms to be used in determining a payment amount to be paid by the buyer for the transaction (0012 “selecting, via the payment portal and using the at least one of the merchant identifying information and the payment information, a selected payment algorithm from the plurality of payment algorithms where the selected payment algorithm is associated in the payment portal with at least one of the merchant identifying information and the payment information, and where the payment information includes a payment amount to be paid by the buyer to the seller”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the resource management system of Daniels with the electronic payment system of Leavitt for the purpose of processing various types of payments as directed by a buyer (0042).
Daniels and Leavitt do not explicitly disclose compiling, via the payment portal and using a settlement algorithm of the algorithms, a settlement output to define settlement terms for settling the transaction, the settlement terms including the payment amount. Anderson teaches compiling, via the payment portal and using a settlement algorithm of the algorithms, a settlement output to define settlement terms for settling the transaction, the settlement terms including the payment amount (0281 “For example, if the customer would like to make monthly payments of 50 dollars toward the one-time loan, the customer would select the 50 dollar payment option and the modified loan terms would be presented to the customer at modified payment schedule 1108a.”, 0282 “If the customer accepts the modified payment schedule 1108a conditions and any additional terms and conditions that are included in the loan, then the customer will move to the one-time loan acceptance 11010 and the transaction will be completed with the provider of the one-time loan paying for the transaction instead of the customer's debit card.”, 0283 “Similarly, if the customer would like to make 10 monthly payments on the one-time loan, the customer would select the 10 months of payments option and the modified loan terms will be presented to the customer at modified payment schedule 1108a. In one embodiment, when the customer chooses to pay back the loan over a selected number of month that are longer than the default number of months, the loan fee would be increased by a defined amount and presented to the customer along with the terms and conditions. For example, the amount of the one-time loan would be 520 dollars (e.g., 500 dollars+10 dollar fee+10 dollars interest). Since the customer has selected a loan term of 10 months, the monthly payment would be 52 dollars per month.”, 0284 “If the customer accepts the modified payment schedule 1108a conditions and any additional terms and conditions that are included in the loan, then the customer will move to the one-time loan acceptance 11010 and the transaction will be completed with the provider of the one-time loan paying for the transaction instead of the customer's debit card.”)
Anderson teaches selecting, via the payment portal and using the merchant identifying information and/or the payment information, a value authority algorithm of the algorithms to identify a value authority to be used in selecting a commercial value for a variable term to be associated with and/or included as part of the payment amount (0256 “Referring now to FIG. 11, a flowchart 1100 of a method for providing an opportunity for a customer to replace a debit card payment with a one-time loan at a point of sale POS is disclosed in accordance with an embodiment.”, 0257 “In one embodiment, the customer is identified by information taken from level 1, level 2, and/or other levels that may exist such as level 3 (or other yet to be defined levels) that are included in the debit card (or credit card) transaction information obtained during the debit card's interaction with the POS (e.g., the swipe, chip, NFC [such as for virtual payments, from a payment from a bank app on a user's mobile device, from a mobile wallet payments, or the like]).”, 0260 “The most basic and common type of bank card transaction is the level 1 transaction. In one embodiment, some of the basic data fields used to complete a level 1 bank card transaction include a merchant name, a customer's billing zip code, and a transaction amount. In one embodiment, additional information, such as the date and time of the transaction and additional cardholder information is automatically recorded by the bank but isn't explicitly reported by the merchant processing the transaction”, 0267 “If the customer attempts to perform the transaction with a debit card (e.g., a card tied to a customer's bank account), and the customer qualifies for a one-time loan in the amount defined by the purchase price, then the customer can be offered (from the customer facing device) a one-time loan. The offer can include loan amount, pay-off schedule, an APR, and the like. In one embodiment, the offer could include incentives such as no interest for the first x-months, breaking the total down into a number of monthly payments with only a single upfront fee (e.g., 5 dollars or 1% of the transaction whichever is greater), allowing the customer to select the number of monthly payments, and the like.”, 0274 “In one embodiment, the loan amount and payment 1104, will also include an optional opportunity for the customer to change the default one-time loan terms and conditions, the interest rate, any grace period information, the breakdown of payments, and the like.”)
Anderson teaches transmitting, via the payment portal and using the value authority algorithm, a variable request to the value authority, the variable request including one or more variable selection parameters specifying at least one of a time frame for a time-dependent variable and conditions or rules for a condition-dependent variable, the variable selection parameters instructing the value authority to select the commercial value based thereon (0274 “In one embodiment, the loan amount and payment 1104, will also include an optional opportunity for the customer to change the default one-time loan terms and conditions, the interest rate, any grace period information, the breakdown of payments, and the like.”, 0278 “If the customer accepts the reduced term 1107a conditions and any additional terms and conditions that are included therewith, then the customer will move to the one-time loan acceptance 11010 and the transaction will be completed with the provider of the one-time loan paying for the transaction instead of the customer's debit card”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the resource management system of Daniels with the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson for the purpose of establishing and building upon a customer-payment provider relationship. (Anderson at paragraph 0031).
Daniels, Leavitt and Anderson do not explicitly disclose transmitting, via the payment portal and based on the settlement output, a payment authorization request to request a payment application provider and/or an issuer to settle the transaction according to the settlement terms. Douglas teaches transmitting, via the payment portal and based on the settlement output, a payment authorization request to request a payment application provider and/or an issuer to settle the transaction according to the settlement terms (0023 “Ecosystem 100 also includes lender 104, which may comprise a credit card provider, a line of credit provider, or a bank and/or a service provider. In some embodiments, lender 104 may comprise a payment service network. For example, an acquiring bank may receive payment authorization requests from a source and send them to an issuing bank (which may include, or be a separate entity from, the acquiring bank). The acquiring bank may then relay a response from the issuing bank to the source. In some embodiments, the acquiring bank may be a third-party entity. The acquiring bank may provide a service or device that allows a source to accept credit cards as well as send credit card payment details to a network. Upon receipt, the network may forward the payment authorization to the acquiring bank”, 0025 “The receiver (e.g., receiver 106), which may be a merchant, may accept credit card payments, debits against a line of credit, etc. Receiver 106 may also send credit, debit instructions, and/or user account information to, and request payment authorization from, an issuing bank corresponding to the self-executing program (or a line of credit related to the self-executing program)”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the resource management system of Daniels with the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson further with the variable self-executing programs of Douglas for the purpose of more easily and efficiently interact with legacy (e.g., non-blockchain) systems (0003).
As per claim 19
Douglas teaches receiving, via the payment portal, a response to the payment authorization request from the payment application provider and/or the issuer (0024 “An issuing bank may receive a payment authorization request from the credit card network and either approve or decline the transaction”)
Douglas teaches parsing, in the computer device and using a reporting algorithm of the algorithms, the response to determine one or more transaction details included with the response, the transaction details including an indication of whether the payment application provider and/or the issuer approved or denied the payment authorization request (0024 “An issuing bank may receive a payment authorization request from the credit card network and either approve or decline the transaction”, 0045 “Issuers' authorization decisions would be made through a rule set based on the first on-chain rule configuration function that would approve or decline based on their credit, fraud, etc., policies. Oracles 108 may enforce these policies and/or may use on-chain rule set based on the first on-chain rule configurations for performing anti-money laundering and/or know-your-customer checks on the receiver/seller. Rule set based on the first on-chain rule configuration may also include the capability to set a time period to reclaim payments (for chargebacks or re-bills due to disputes/fraud). For example, the system may determine an encoded instruction for the rule set based on the first on-chain rule configuration, wherein the encoded instruction causes a time period for use of or a specific use of the self-executing program. Approved authorizations would trigger the transfer of funds from the issuer's wallet to the receiver's/seller's wallet”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the resource management system of Daniels with the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson further with the variable self-executing programs of Douglas for the purpose of more easily and efficiently interact with legacy (e.g., non-blockchain) systems (0003).
As per claim 20
Daniels discloses exporting, via the payment portal and using an exporting algorithm of the algorithms, the transaction details into a buyer accounts payable (AP) system of the buyer and/or a merchant accounts receivable (AR) system of the merchant, the transaction details imported including the payment amount and the indication (Page 13 lines 3-17) “By way of example, when the instant technology is employed in the financial industry, electronic resource management systems 108a and 108b through 108n are capable of maintaining event data associated with a payment (e.g., due date, payment amount, or entity to which the payment is rendered) similar to enterprise resource planning systems (e.g., as provided by Oracle , SAP , or the like) or accounting software (e.g., as provided by QuickBooks , Quicken , or the like). The electronic resource management system may thus provide a software application platform for maintaining or manipulating data associated with a general ledger, fixed assets, account payable, account receivable, cash management, financial consolidation, or the like. In some embodiments, the electronic resource management systems 108a and 108b through 108n maintains event data providing an indication of whether the resource transfer associated with the event is an inbound resource and/or an outbound resource. The inbound resource may be a resource that will be received by a particular user and/or user device at the scheduled time. The outbound resource may be a resource that will be transferred by a particular user and/or user device at a scheduled time”).
As per claim 21
Daniels discloses autonomously exporting, via the payment portal and using the exporting algorithms, the transaction details to the buyer AP system and/or the merchant AR system automatically according to a predefined schedule and/or occurrence of a triggering event (page 3 line 24 through page 4 line 2 “For example and as further described herein, a first and second electronic resource management system may store data about an event. The event may be a future transfer of resources between one or more users and/or one or more user devices (both of which may be referred to as an entity). Event data for the event may include data for the amount of resources (or indication of resources) that will be transferred, a scheduled time for transferring the resources, the entities involved in the resource transfer, or other information about event. More particularly, the first electronic resource management system may store data about inbound resources to be received and the second electronic resource management system may store data about outbound resources to be transferred”).
As per claim 22
Daniels discloses autonomously importing, via the payment portal and using an importing algorithm of the algorithms, the transaction information from the buyer AP system automatically according to a predefined schedule and/or occurrence of a triggering event (page 3 line 24 through page 4 line 2 “For example and as further described herein, a first and second electronic resource management system may store data about an event. The event may be a future transfer of resources between one or more users and/or one or more user devices (both of which may be referred to as an entity). Event data for the event may include data for the amount of resources (or indication of resources) that will be transferred, a scheduled time for transferring the resources, the entities involved in the resource transfer, or other information about event. More particularly, the first electronic resource management system may store data about inbound resources to be received and the second electronic resource management system may store data about outbound resources to be transferred”).
As per claim 24
Daniels discloses accessing, via a computing device having a payment portal, a buyer accounts payable (AP) system of a buyer to retrieve transaction information, the transaction information relating to a transaction between the buyer and a merchant, the transaction information including merchant identifying information and payment information, the payment portal including a plurality of algorithms (Page 13 lines 3-17, “By way of example, when the instant technology is employed in the financial industry, electronic resource management systems 108a and 108b through 108n are capable of maintaining event data associated with a payment (e.g., due date, payment amount, or entity to which the payment is rendered) similar to enterprise resource planning systems (e.g., as provided by Oracle , SAP , or the like) or accounting software (e.g., as provided by QuickBooks , Quicken , or the like). The electronic resource management system may thus provide a software application platform for maintaining or manipulating data associated with a general ledger, fixed assets, account payable, account receivable, cash management, financial consolidation, or the like. In some embodiments, the electronic resource management systems 108a and 108b through 108n maintains event data providing an indication of whether the resource transfer associated with the event is an inbound resource and/or an outbound resource. The inbound resource may be a resource that will be received by a particular user and/or user device at the scheduled time. The outbound resource may be a resource that will be transferred by a particular user and/or user device at a scheduled time”).
Daniels does not explicitly disclose selecting, via the payment portal and using the merchant identifying information and/or the payment information, a payment algorithm of the algorithms to be used in determining a payment amount to be paid by the buyer for the transaction. Leavitt teaches selecting, via the payment portal and using the merchant identifying information and/or the payment information, a payment algorithm of the algorithms to be used in determining a payment amount to be paid by the buyer for the transaction (0012 “selecting, via the payment portal and using the at least one of the merchant identifying information and the payment information, a selected payment algorithm from the plurality of payment algorithms where the selected payment algorithm is associated in the payment portal with at least one of the merchant identifying information and the payment information, and where the payment information includes a payment amount to be paid by the buyer to the seller”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the resource management system of Daniels with the electronic payment system of Leavitt for the purpose of processing various types of payments as directed by a buyer (0042).
Daniels and Leavitt do not explicitly disclose selecting, via the payment portal and using the merchant identifying information and/or the payment information, a value authority algorithm of the algorithms to identify a value authority to be used in selecting a commercial value for a variable term to be associated with and/or included as part of the payment amount. Anderson teaches selecting, via the payment portal and using the merchant identifying information and/or the payment information, a value authority algorithm of the algorithms to identify a value authority to be used in selecting a commercial value for a variable term to be associated with and/or included as part of the payment amount (0256 “Referring now to FIG. 11, a flowchart 1100 of a method for providing an opportunity for a customer to replace a debit card payment with a one-time loan at a point of sale POS is disclosed in accordance with an embodiment.”, 0257 “In one embodiment, the customer is identified by information taken from level 1, level 2, and/or other levels that may exist such as level 3 (or other yet to be defined levels) that are included in the debit card (or credit card) transaction information obtained during the debit card's interaction with the POS (e.g., the swipe, chip, NFC [such as for virtual payments, from a payment from a bank app on a user's mobile device, from a mobile wallet payments, or the like]).”, 0260 “The most basic and common type of bank card transaction is the level 1 transaction. In one embodiment, some of the basic data fields used to complete a level 1 bank card transaction include a merchant name, a customer's billing zip code, and a transaction amount. In one embodiment, additional information, such as the date and time of the transaction and additional cardholder information is automatically recorded by the bank but isn't explicitly reported by the merchant processing the transaction”, 0267 “If the customer attempts to perform the transaction with a debit card (e.g., a card tied to a customer's bank account), and the customer qualifies for a one-time loan in the amount defined by the purchase price, then the customer can be offered (from the customer facing device) a one-time loan. The offer can include loan amount, pay-off schedule, an APR, and the like. In one embodiment, the offer could include incentives such as no interest for the first x-months, breaking the total down into a number of monthly payments with only a single upfront fee (e.g., 5 dollars or 1% of the transaction whichever is greater), allowing the customer to select the number of monthly payments, and the like.”, 0274 “In one embodiment, the loan amount and payment 1104, will also include an optional opportunity for the customer to change the default one-time loan terms and conditions, the interest rate, any grace period information, the breakdown of payments, and the like.”)
Anderson teaches transmitting, via the payment portal and using the value authority algorithm, a variable request to the value authority, the variable request including one or more variable selection parameters specifying at least one of a time frame for a time-dependent variable and conditions or rules for a condition-dependent variable, the variable selection parameters instructing the value authority to select the commercial value based thereon (0274 “In one embodiment, the loan amount and payment 1104, will also include an optional opportunity for the customer to change the default one-time loan terms and conditions, the interest rate, any grace period information, the breakdown of payments, and the like.”, 0278 “If the customer accepts the reduced term 1107a conditions and any additional terms and conditions that are included therewith, then the customer will move to the one-time loan acceptance 11010 and the transaction will be completed with the provider of the one-time loan paying for the transaction instead of the customer's debit card”)
Anderson teaches compiling, via the payment portal and using a settlement algorithm of the algorithms, a settlement output to define settlement terms for settling the transaction, the settlement terms including the payment amount (0281 “For example, if the customer would like to make monthly payments of 50 dollars toward the one-time loan, the customer would select the 50 dollar payment option and the modified loan terms would be presented to the customer at modified payment schedule 1108a.”, 0282 “If the customer accepts the modified payment schedule 1108a conditions and any additional terms and conditions that are included in the loan, then the customer will move to the one-time loan acceptance 11010 and the transaction will be completed with the provider of the one-time loan paying for the transaction instead of the customer's debit card.”, 0283 “Similarly, if the customer would like to make 10 monthly payments on the one-time loan, the customer would select the 10 months of payments option and the modified loan terms will be presented to the customer at modified payment schedule 1108a. In one embodiment, when the customer chooses to pay back the loan over a selected number of month that are longer than the default number of months, the loan fee would be increased by a defined amount and presented to the customer along with the terms and conditions. For example, the amount of the one-time loan would be 520 dollars (e.g., 500 dollars+10 dollar fee+10 dollars interest). Since the customer has selected a loan term of 10 months, the monthly payment would be 52 dollars per month.”, 0284 “If the customer accepts the modified payment schedule 1108a conditions and any additional terms and conditions that are included in the loan, then the customer will move to the one-time loan acceptance 11010 and the transaction will be completed with the provider of the one-time loan paying for the transaction instead of the customer's debit card.”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the resource management system of Daniels with the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson for the purpose of establishing and building upon a customer-payment provider relationship. (Anderson at paragraph 0031).
Daniels, Leavitt and Anderson do not explicitly disclose transmitting, via the payment portal and based on the settlement output, a payment authorization request to request a payment application provider and/or an issuer to settle the transaction according to the settlement terms. Douglas teaches transmitting, via the payment portal and based on the settlement output, a payment authorization request to request a payment application provider and/or an issuer to settle the transaction according to the settlement terms (0023 “Ecosystem 100 also includes lender 104, which may comprise a credit card provider, a line of credit provider, or a bank and/or a service provider. In some embodiments, lender 104 may comprise a payment service network. For example, an acquiring bank may receive payment authorization requests from a source and send them to an issuing bank (which may include, or be a separate entity from, the acquiring bank). The acquiring bank may then relay a response from the issuing bank to the source. In some embodiments, the acquiring bank may be a third-party entity. The acquiring bank may provide a service or device that allows a source to accept credit cards as well as send credit card payment details to a network. Upon receipt, the network may forward the payment authorization to the acquiring bank”, 0025 “The receiver (e.g., receiver 106), which may be a merchant, may accept credit card payments, debits against a line of credit, etc. Receiver 106 may also send credit, debit instructions, and/or user account information to, and request payment authorization from, an issuing bank corresponding to the self-executing program (or a line of credit related to the self-executing program)”)
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the resource management system of Daniels with the electronic payment system of Leavitt with the method of providing a customer with a number of payment scenarios of Anderson further with the variable self-executing programs of Douglas for the purpose of more easily and efficiently interact with legacy (e.g., non-blockchain) systems (0003).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Buterin, “A next-generation smart contract and decentralized application platform”, January 14, 2014, 36 pages discloses a framework for the cryptocurrency Ethereum along with the use of smart contracts for embedding terms and conditions into expressions which can autonomously establish and enforce contractual arrangements and oracles for obtaining event driven data.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES D NIGH whose telephone number is (571)270-5486. The examiner can normally be reached 5 AM to 2 PM Monday through Thursday.
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, Neha Patel can be reached at (571) 270-1492. 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.
/JAMES D NIGH/Senior Examiner, Art Unit 3699
Prosecution Insights