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 .
Claim Status
As of the Office Action dated September 5, 2025 claims 1-24 were pending and claims 1-24 stood rejected. Claim 18 has been amended and claim 23 has been cancelled. No claims have been added. Claims 1-22 and 24 are therefore currently pending and are presented for examination on the merits.
Information Disclosure Statement
The information disclosure statement (IDS) was submitted on February 4, 2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant’s argument with regard to the 35 U.S.C. § 103 rejection of claims 1, 2 and 8 as being unpatentable over Leavitt et al. (U.S. Patent Publication 2020/0134609, hereinafter referred to as Leavitt) in view of Hummer (U.S. Patent Publication 2020/0258148) has been fully considered but is not persuasive. Applicant’s written disclosure at paragraph 0173 provides no structural description of either the value authority or the value authority algorithm but only provides a functional description. No examples of either term are given. Oracles are applications that source, verify, and transmit external information. Therefore as an oracle is a software application and those of ordinary skill would view an oracle as being a value authority algorithm that is programmed to query external data sources which would read on the value authority (or value authorities). Therefore there is no deficiency and Applicant has failed to demonstrate any clear error on the part of the Examiner. As such the rejection of claims 1, 2 and 8 will be maintained.
Applicant’s argument with regard to the 35 U.S.C. § 103 rejection of claims 3 and 4 as being unpatentable over Leavitt in view of Hummer 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) has been fully considered but is not persuasive. As the argument relies on the alleged deficiencies of Leavitt in view of Hummer as applied to claim 1 the argument is deemed as deficient and therefore the present rejection of claims 3 and 4 will be maintained.
Applicant’s argument with regard to the 35 U.S.C. § 103 rejection of claims 5, 6 and 7 as being unpatentable over Leavitt in view of Hummer in view of Douglas as applied to claim 4 above, and further in view of in view of Daniels (Canada Publication CA 3214827 A1) has been fully considered but is not persuasive. As the argument relies on the alleged deficiencies of Leavitt in view of Hummer as applied to claim 1 the argument is deemed as deficient and therefore the present rejection of claims 5, 6 and 7 will be maintained.
Applicant’s argument with regard to the 35 U.S.C. § 103 rejection of claims 9-17 as being unpatentable over Leavitt in view of Hummer as applied to claim 1 above, and further in view of Cella et al. (U.S. Patent Publication 2023/0206329, hereinafter referred to as Cella) has been fully considered but is not persuasive. As the argument relies on the alleged deficiencies of Leavitt in view of Hummer as applied to claim 1 the argument is deemed as deficient and therefore the present rejection of claims 9-17 will be maintained.
Applicant’s argument with regard to the 35 U.S.C. § 103 rejection of claims 18-24 as being unpatentable over Daniels in view of Hummer and in view of Douglas has been fully considered but is not persuasive. The argument repeats the alleged deficiency of Hummer as applied to claim 1 which has been shown by Examiner as failing to demonstrate any clear error on the part of the Examiner. As claim 23 has now been consolidated into claim 18 Examiner will maintain the existing rejection of Daniels in view of Hummer and Douglas with regard to claims 18-22 and 24.
Applicant’s argument with regard to the 35 U.S.C. § 101 rejection of claims 1-24 has been fully considered but is not persuasive. Applicant’s written disclosure at paragraph 0173 provides no structural description of either the value authority or the value authority algorithm but only provides a functional description. No examples of either term are given. An algorithm in the broadest reasonable interpretation is simply a “a step-by-step procedure for solving a problem or accomplishing some end” (© 2026 Merriam-Webster, Incorporated). Human beings have long performed step-by-step procedures for solving a problem or accomplishing some end which has included procedures for obtaining interest rates from sources such as the Federal Reserve or the London Interbank Offering Rate without the involvement of a computer for the purpose of establishing loan and savings terms and can therefore be viewed as a fundamental economic practice. Steps that human beings performed to “select a value authority algorithm” would include obtaining and reading a newspaper, locating and reading a stock ticker or other type of telegram means, etc. Therefore this argument is not persuasive with regard to Prong One of Step 2A. With regard to the second argument on page 19 of remarks Examiner would point out that the current guidance on Patent Subject Matter Eligibility is incorporated in Manual of Patent Examining Procedure,Latest Revision November 2024 [R-01.2024] at section 2106 which served as the basis for Examiner’s rejection. Examiner referred to MPEP § 2106.04(a)(2)(II)(A) with regard to the fundamental economic practice and MPEP § 2106.04(a)(2)(III)(B) with regard to the operations being directed towards a mental process and Applicant has not shown any clear error in Examiner’s determination. With regard to Step 2B it is clear that no technological improvement is being made to the functioning of a computer (MPEP § 2106.05(a)) and that the all of the limitations can be viewed as mere instructions to apply the abstract idea (MPEP § 2106.05(f)). Examiner respectfully disagrees with Applicant’s conclusory statements that the claim are related to any of the cited court cases and the argument amounts to nothing more than a mere statement that the claims are eligible. As such Examiner will be maintaining the current rejection under section 101.
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-24 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. 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. Therefore under Step 2B claim 1 is deemed as being directed towards ineligible subject matter.
Dependent claims 2-17 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 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 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. 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. Therefore claim 24 is deemed as being directed towards ineligible subject matter.
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 and 8 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 Hummer (U.S. Patent Publication 2020/0258148).
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 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. Hummer 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 (0004 “Banks offer variable rate loans to both individuals and institutions that are priced off various bases, such as LIBOR (London Inter-Bank Offered Rate) or the prime rate. More recently, new base rates such as SONIA (Sterling Overnight Index Average) and SOFR (U.S. Secured Overnight Financing Rate) have been developed to supplant LIBOR for greater accuracy and reliability, but the changeover will not occur for several more years. Even then, there will still be many existing floating rate loans that are based on LIBOR terms”, 0010 “An aspect of the invention relates to a system and method for processing and executing interest rate swaps between one or more counterparties using a distributed blockchain ledger, smart contracts, and oracles to enable parties to transact without needing a trusted third party or intermediary…One or more oracles may be used to obtain interest rate and/or other information needed by the system”, [0040] “(viii) Information on message sender and address obtained from registration and login” [0041] “(ix) Ether (ETH), ERC (Ethereum Request for Comments) token, or similar account address to pay escrow and to receive payout”)
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 bi-directional digital asset point of sale computing device of Hummer for the purpose of enabling parties to transact without needing a trusted party or intermediary.
As per claim 2
Hummer 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 (0084 “Smart contracts are computer programs stored on a blockchain that facilitate, verify, or enforce the negotiation or performance of a contract, or that make a contractual clause unnecessary as contracts are automatically executed when pre-programmed conditions are satisfied. Smart contracts may also have a user interface and often emulate the logic of contractual clauses. Smart contracts eliminate ambiguity regarding the terms of agreements and reduce the reliance on external dependencies” 0085 “one or more smart contracts may be configured to depend on various conditions (e.g., a reference interest rate at a given date or time). To enhance the integrity of the system, an agreed-upon outside system or service, known as an “oracles,” can be used to monitor and verify such conditions, data, and/or other events. The oracle may be an agreed to off-chain service (not part of the blockchain) that may send information to the one or more smart contracts”, 0086 “To develop a smart contract, parts of the terms that make up a traditional contract are implemented in software code and uploaded to the blockchain, producing a decentralized smart contract that does not rely on a third party for recordkeeping or enforcement. Contractual clauses are automatically executed when pre-programmed conditions are satisfied. This eliminates ambiguity regarding the terms of the agreement and disagreement concerning the existence of external dependencies”)
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 bi-directional digital asset point of sale computing device of Hummer for the purpose of enabling parties to transact without needing a trusted party or intermediary.
As per claim 8
Hummer 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 (0025 “…variable rate oracle 130 may be configured to interact with one or more external resources to obtain a variable rate”, 0062 “The dApp may use an oracle for the swap rate and other data (e.g., for Libor and/or other reference rate on the first day of the contract maturity month) instead of it being entered by the administrator or other individual”).
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 bi-directional digital asset point of sale computing device of Hummer for the purpose of enabling parties to transact without needing a trusted party or intermediary.
Claims 3 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Leavitt in view of Hummer 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 Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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 Hummer 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 Hummer and Douglas disclose the limitations of claim 4 including the transaction details including the payment amount and the commercial value for the variable term (Hummer as above at 0004, 0040 and 0041) 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 bi-directional digital asset point of sale computing device of Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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 Hummer 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 Hummer, 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 bi-directional digital asset point of sale computing device of Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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 Hummer, 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 a 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 a 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 bi-directional digital asset point of sale computing device of Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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 Hummer 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. Hummer 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 (0084 “Smart contracts are computer programs stored on a blockchain that facilitate, verify, or enforce the negotiation or performance of a contract, or that make a contractual clause unnecessary as contracts are automatically executed when pre-programmed conditions are satisfied. Smart contracts may also have a user interface and often emulate the logic of contractual clauses. Smart contracts eliminate ambiguity regarding the terms of agreements and reduce the reliance on external dependencies” 0085 “one or more smart contracts may be configured to depend on various conditions (e.g., a reference interest rate at a given date or time). To enhance the integrity of the system, an agreed-upon outside system or service, known as an “oracles,” can be used to monitor and verify such conditions, data, and/or other events. The oracle may be an agreed to off-chain service (not part of the blockchain) that may send information to the one or more smart contracts”, 0086 “To develop a smart contract, parts of the terms that make up a traditional contract are implemented in software code and uploaded to the blockchain, producing a decentralized smart contract that does not rely on a third party for recordkeeping or enforcement. Contractual clauses are automatically executed when pre-programmed conditions are satisfied. This eliminates ambiguity regarding the terms of the agreement and disagreement concerning the existence of external dependencies”)
Hummer 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 determining a time varying term and/or a condition dependent term 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 (0084 “Smart contracts are computer programs stored on a blockchain that facilitate, verify, or enforce the negotiation or performance of a contract, or that make a contractual clause unnecessary as contracts are automatically executed when pre-programmed conditions are satisfied. Smart contracts may also have a user interface and often emulate the logic of contractual clauses. Smart contracts eliminate ambiguity regarding the terms of agreements and reduce the reliance on external dependencies” 0085 “one or more smart contracts may be configured to depend on various conditions (e.g., a reference interest rate at a given date or time). To enhance the integrity of the system, an agreed-upon outside system or service, known as an “oracles,” can be used to monitor and verify such conditions, data, and/or other events. The oracle may be an agreed to off-chain service (not part of the blockchain) that may send information to the one or more smart contracts”, 0086 “To develop a smart contract, parts of the terms that make up a traditional contract are implemented in software code and uploaded to the blockchain, producing a decentralized smart contract that does not rely on a third party for recordkeeping or enforcement. Contractual clauses are automatically executed when pre-programmed conditions are satisfied. This eliminates ambiguity regarding the terms of the agreement and disagreement concerning the existence of external dependencies”)
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 bi-directional digital asset point of sale computing device of Hummer for the purpose of enabling parties to transact without needing a trusted party or intermediary.
Daniels, Leavitt and Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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. Hummer 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 (0004 “Banks offer variable rate loans to both individuals and institutions that are priced off various bases, such as LIBOR (London Inter-Bank Offered Rate) or the prime rate. More recently, new base rates such as SONIA (Sterling Overnight Index Average) and SOFR (U.S. Secured Overnight Financing Rate) have been developed to supplant LIBOR for greater accuracy and reliability, but the changeover will not occur for several more years. Even then, there will still be many existing floating rate loans that are based on LIBOR terms”, 0010 “An aspect of the invention relates to a system and method for processing and executing interest rate swaps between one or more counterparties using a distributed blockchain ledger, smart contracts, and oracles to enable parties to transact without needing a trusted third party or intermediary…One or more oracles may be used to obtain interest rate and/or other information needed by the system”, [0040] “(viii) Information on message sender and address obtained from registration and login” [0041] “(ix) Ether (ETH), ERC (Ethereum Request for Comments) token, or similar account address to pay escrow and to receive payout”)
Hummer 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 (0084 “Smart contracts are computer programs stored on a blockchain that facilitate, verify, or enforce the negotiation or performance of a contract, or that make a contractual clause unnecessary as contracts are automatically executed when pre-programmed conditions are satisfied. Smart contracts may also have a user interface and often emulate the logic of contractual clauses. Smart contracts eliminate ambiguity regarding the terms of agreements and reduce the reliance on external dependencies” 0085 “one or more smart contracts may be configured to depend on various conditions (e.g., a reference interest rate at a given date or time). To enhance the integrity of the system, an agreed-upon outside system or service, known as an “oracles,” can be used to monitor and verify such conditions, data, and/or other events. The oracle may be an agreed to off-chain service (not part of the blockchain) that may send information to the one or more smart contracts”, 0086 “To develop a smart contract, parts of the terms that make up a traditional contract are implemented in software code and uploaded to the blockchain, producing a decentralized smart contract that does not rely on a third party for recordkeeping or enforcement. Contractual clauses are automatically executed when pre-programmed conditions are satisfied. This eliminates ambiguity regarding the terms of the agreement and disagreement concerning the existence of external dependencies”)
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 bi-directional digital asset point of sale computing device of Hummer for the purpose of enabling parties to transact without needing a trusted party or intermediary.
Daniels, Leavitt and Hummer 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 bi-directional digital asset point of sale computing device of Hummer 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.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES D NIGH whose telephone number is (571)270-5486. The examiner can normally be reached 6:00 to 9:45 and 10:30 to 2:45.
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