DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Application
This is a final rejection relating to Amendments to the Claims and Remarks submitted on July 28, 2026 relating to U.S. Patent Application No. 19/013,598, filed on January 8, 2025. This application is a continuation of U.S. Patent Application No. 18/180,740, filed on March 8, 2023, now U.S. Patent 12,236,407. Claims 21, 23, 28, 30, 35and 37 have been amended. Claims 22, 29 and 36 have been cancelled. Claims 41-43 have been added. Claims 21, 23-28, 30-35 and 37- 43 are pending and have been examined.
Claim Objections
Claims 38, 39 and 40 are objected to insofar as their recited language, as currently presented, differs from the language recited at the time the claims were presented for examination on January 8, 2025 and examined pursuant to the Non-Final Rejection issued on April 30, 2026. New Claim 41 is also objected to insofar as the recited language is identical to previously presented Claim 40. Applicant’s current submissions of the Amendments to the Claims and Remarks give no indication that Claims 38, 39 or 40 have been canceled or amended (although in the claim listing, Claim 38 is indicated to be New). Applicant has asserted that Claims 21, 23, 28, 30, 35 and 37 are amended and that Claims 41-43 are new.
The numbering of claims is not in accordance with 37 CFR 1.126 which requires the original numbering of the claims to be preserved throughout the prosecution. When claims are canceled, the remaining claims must not be renumbered. When new claims are presented, they must be numbered consecutively beginning with the number next following the highest numbered claims previously presented (whether entered or not).
Appropriate correction is requested.
For purposes of compact prosecution, the listing of Claims 38, 39 and 40, as presented on January 8, 2025, will be maintained. New Claim 41 will not be examined insofar as it is identical to Claim 40.
Response to Arguments
The Remarks submitted by Applicant on July 28, 2026 have been fully considered.
With respect to the Double Patenting Rejection, Applicant is willing to file an appropriate terminal disclaimer to obviate this rejection once the asserted claims are found to be allowable and requests that this rejection be held in abeyance pending an indication of allowance of the claims. The Double Patenting Rejection is maintained.
With respect to the Section 112(b) Rejection, Applicant has amended independent Claims 21, 28 and 35 and resolved the antecedent basis issue. The Section 112(b) Rejection is withdrawn.
With respect to the Section 101 Rejection, Applicant asserts that the amended claims present patent-eligible subject matter in that the technical features recited in the amended claims recite a solution that integrates the alleged abstract idea into a practical application and cites, as support, to the application’s parent application as reciting similar technical features which were found to be patentable. Applicant asserts that the claims recite technical features that are an ordered combination with the other claim features which integrate the alleged abstract idea into a practical application and that the claimed technology provides an inventive concept of unconventional features as part of a technical solution to a technical problem. (Remarks, pp. 9-12). Examiner respectfully disagrees. As an initial matter, applications are examined separately and the findings in one application bear no weight with respect to the findings in another. The operation of the additional technical limitations and the additional elements recited in Claim 21 are being used as tools to implement the abstract idea. They do not provide technical improvements such as to the functioning of a computer or to technology or to a technical field and thus they do not integrate the abstract idea into a practical application or provide significantly more. (See Section 101 Rejection below). The Section 101 Rejection is maintained.
With respect to the Section 103 Rejections, Applicant asserts that the cited references, Wintle, Wu and Chaturvedi, do not disclose the elements of the amended claims, particularly that Chaturvedi does not disclose storing user account information under a user designated name. (Remarks, p. 13). Examiner respectfully disagrees. (See Chaturvedi, Pars. 30, 48 and 64, see also Wu, Par. 57). The cited references teach each and every element of the amended claims. (See Section 103 Rejections below). The Section 103 Rejections are maintained.
Double Patenting Rejection
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on non-statutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21-40 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1 - 14 of U.S. Patent 12,236,407. Although the claims at issue are not identical, they are not patentably distinct from each. Claim 21 from the instant application and claim 1 of the ‘407 patent each recite: a server computing system, comprising: one or more processors; and a non-transitory memory coupled to the one or more processors, the non-transitory memory including a set of instructions of computer-executable program code, which when executed by the one or more processors, causes the one or more processors to perform operations including: storing a plurality of transactions in a storage location (claim 1 stores a first financial transaction); training, via one or more ML algorithms of a machine learning (ML) module based on the stored user financial account data, one or more machine learning models to identify a transaction as a recurring transaction; receiving, from a client device, a user command to execute a transaction using funds from a source account, the transaction including transaction details (claim 1 receives a command to execute a second financial transaction from a client device of a user in a virtual chat communication session); identifying, via the trained one or more machine learning models based on the transaction details, the transaction as a recurring transaction; executing, via an application programming interface, the identified transaction using the transaction details; and saving the identified transaction in the storage location and classifying the identified transaction as a recurring transaction. The differences in the recited language between Claim 21 of the instant application and claim 1 of the ‘407 patent identified above are not patently significant. In addition to the aforementioned differences in the recited language, Claim 21 recites a final limitation: “and saving the identified transaction in the storage location and classifying the identified transaction as a recurring transaction.” The additional limitation in Claim 21 and the differences in the recited language identified above are not patently significant in that Claim 21 comprises the basic elements of the invention in claim 1 of the ‘407 patent. The additional limitations of saving the identified transaction in the storage location and classifying the identified transaction as a recurring transaction would be obvious in light of the basic elements of the invention. The inventions are not patently distinct.
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 21, 23-28, 30-35 and 37-43 are rejected pursuant to 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1 - Statutory Class
Claims 21, 23-27 and 42 are directed to a system. Claims 28, 30-34 and 43 are directed a computer program product. Claims 35 and 37-41 are directed to a method. Therefore, on its face, each of the claims is directed to a statutory class of invention.
Step 2A, Prong 1 – Abstract Idea
Claim 21 recites storing a plurality of transactions in a storage location, training, based on the stored user financial account data, one or more machine learning models to identify a transaction as a recurring transaction, receiving a user command to execute a transaction using funds from a source account, the transaction including transaction details, identifying via the models the transaction as a recurring transaction, executing the identified transaction using the transaction details, saving the identified executed transaction in the storage location under a user designated name associated with the executed identified transaction and classifying the identified transaction as a recurring transaction. Claim 21 recites the abstract idea of storing a plurality of transactions and using models to identify recurring transactions, receiving a command to execute a transaction, including transaction details, using funds from a source account, identifying the transaction as a recurring transaction, executing the transaction using the transaction details and saving the identified transaction which constitutes commercial interactions falling under Certain Methods of Organizing Human Activity enumerated in MPEP 2106.04(a). Claims 28 and 35 recite the same abstract idea.
Step 2A, Prong 2 – Practical Application
Claim 21 recites one or more processors, a non-transitory memory coupled to the one or more processors, a storage location, a machine learning (ML) module, one or more machine learning algorithms, a client device with a graphical user interface (GUI) display and an application programming interface (API). The claim also recites the additional technical limitation of training, via the one or more ML algorithms based on the stored user financial account data. This limitation generally recites training and basic machine learning operations. The operation of this additional technical limitation and the additional elements recited in Claim 21 are being used as tools to implement the abstract idea. They do not provide technical improvements such as to the functioning of a computer or to technology or to a technical field and thus they do not integrate the abstract idea into a practical application.
Step 2B – Significantly more
As set forth in the discussion in Step 2A, Prong 2, above, the additional elements and additional technical limitation are recited at a high level of generality and are used as tools to implement the abstract idea. They do not integrate the abstract idea into a practical application or add significantly more to the abstract idea.
Dependent claims
Claims 23, 30 and 37 (the set of instructions, which when executed by the one or more processors, causes the one or more processors to perform operations including automatically executing a future transaction upon receipt of a second user command that references the user-designated name), Claims 24, 31 and 38 (the set of instructions, which when executed by the one or more processors, causes the one or more processors to perform operations including automatically executing, upon receipt of a second user command, a future transaction at a predetermined time period using the transaction details of the identified transaction), Claims 25 and 32 (the transaction details comprise one or more of a payee name, a transaction amount, a source account of the user, and a date of completion of the second transaction), Claims 26, 33 and 39 (executing the identified transaction comprises executing the transaction using an online bill payment system), Claims 27, 34 and 40 (the set of instructions, which when executed by the one or more processors, causes the one or more processors to perform operations including automatically populating input fields of the online bill payment system using the transaction details), Claim 41 (further comprising automatically populating input fields of the online bill payment system using the transaction details) and Claims 42 and 43 (the set of instructions, when executed by the one or more processors, causes the one or more processors to perform operations including retrieving, prior to executing the future transaction, the transaction details associated with the user-designated name) contain additional elements (underlined above) that are recited at a high level of generality and used as tools to implement the abstract idea and/or further define and merely add specificity to the abstract idea. Thus, the additional elements do not integrate the abstract idea into a practical application.
As such, Claims 21, 23-28, 30-35 and 37-43 are not patent eligible.
Claim Rejections - 35 USC § 103
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 21, 23-25, 28, 30-32, 35, 37-38 and 42-43 are rejected under 35 U.S.C. 103 as being unpatentable over Wintle et al., US 2022/0245641 A1, (“Wintle”), in view of Wu et al., US 2022/0005016 A1, (“Wu”), in further view of Chatuverdi, US 2021/0406896 A1, (“Chaturvedi”).
Claim 21:
Wintle teaches:
A server computing system, comprising: a machine learning (ML) module including one or more ML algorithms; an application programming interface (API); one or more processors; and a non-transitory memory coupled to the one or more processors, the non- transitory memory including a set of instructions of computer-executable program code, which when executed by the one or more processors, causes the one or more processors to perform operations including: (See Wintle, Claim 1 (A system, comprising: an artificial intelligence (AI) platform including one or more machine learning (ML) models; one or more server computers each having a processor coupled to a memory and in communication with the AI platform; and one or more software components executed by the one or more server computers that are configured to:), Par. 36 (The process may begin by implementing an application programming interface (API) between the payment processing network and the issuer (block 200).), Par. 83 (At least some aspects disclosed can be embodied, at least in part, in software. That is, the techniques may be carried out in a computer system or other data processing system in response to its processor, such as a microprocessor, executing sequences of instructions contained in a memory, such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device.))
storing a plurality of executed transactions in a storage location as stored user financial data; (See Wintle, Par. 19 (Details of the payment device transaction may be stored as payment transaction records in a transaction database within or accessible to the servers 116 of the payment processor 102.), Par. 33 (In embodiments, the AI platform 124 may include at least one machine learning (ML) model 126 and a transaction database 128 comprising historical payment transaction data, as discussed further below.))
training, via one or more ML algorithms based on the stored user financial account data, one or more machine learning models to identify a transaction as a recurring transaction; (See Wintle, Par. 33 (This may be accomplished by processing and analyzing transactions through an artificial intelligence (AI) platform 124 to improve the ability of payment processor 102 to identify recurring transactions and key attributes thereof. In embodiments, the AI platform 124 may include at least one machine learning (ML) model 126 and a transaction database 128 comprising historical payment transaction data, as discussed further below.), Par. 37 (Historical payment transaction data is accessed from the transaction database 128 to train a machine learning (ML) model of the AI platform 124 to predict future recurring transactions from the historical payment transaction data (block 202).)
receiving, from the authenticated client device via the GUI, a user command to execute a transaction using funds from a source account, the transaction including transaction details; (See Wintle, Fig. 1, Par. 19 (The payment processor 102 may refer to an entity that receives transaction authorization requests from the merchant 108, and other entities and provides guarantees of payment.), Par. 23 (The merchant 108 may refer to one or more entities (e.g., operators of retail businesses) that provide goods and/or services, and/or access to goods and/or services, to a cardholder, based on a transaction, such as a payment transaction.), Par. 27 (Once the cardholder 106 presents the account identifier to the merchant 108 for a transaction, a computer of the merchant forwards the account identifier along with other transactional details, such as the payment amount, to the acquirer 104.), Par. 28 (Once the authorization data is received, the issuer 110 determines if the cardholder 106 is authorized to perform the given transaction (e.g., payment, cash deposit/withdrawal, money transfer, balance inquiries), and returns an authorization response message.))
identifying, via the trained one or more machine learning models based on the transaction details, the transaction as a recurring transaction; (See Wintle, Par. 33 (This may be accomplished by processing and analyzing
transactions through an artificial intelligence (AI) platform 124 to improve the ability of payment processor 102 to identify recurring transactions and key attributes thereof. In embodiments, the AI platform 124 may include at least one machine learning (ML) model 126 and a transaction database 128 comprising historical payment transaction data.))
executing, via the API, the identified transaction using the transaction details; and (See Wintle, Par. 33 (An application programming interface (API) 122 is implemented between the payment processor 102 and the issuer 110 to open a new communication channel between the Al platform 124 and the issuer 110. The API 122 may be solely for communicating information relating to the recurring transactions.), Par. 55 (The payment processor 102 checks if the authorization request includes any recurring transactions indicators. For example, the payment processor 102 may check if the recurring transaction includes any recurring identifier parameters.), Par. 56 (The AI platform 124 monitors the consolidated transaction log 328 and retrieves the entry of the newly added transaction details having recurring indicators.), Par. 57 (Thereafter, the payment processor 102 continues with processing the transaction and routes an authorization request with transaction details to the issuer 110 based on normal processing rules.))
Wintle does not expressly disclose, however, Wu teaches:
saving the executed identified transaction in the storage location . . . , and (See Wu, Par. 45 (Trigger model 408 is also trained to identify recurring transactions in transaction data 402, and can reference information from past data model 402 (through tagged data storage 414) to determine that the transaction is recurring. This information about the transaction can be provided to tagged data storage 414, in accordance with an embodiment.), Par. 57 (At step 602, transaction information regarding a transaction is received, for example transaction data 402 received at machine learning models 404 of FIG. 4. At step 604, secondary information regarding the transaction is received-this could be contact information (including names and photos).))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, saving information about identified recurring transactions in a storage location, as taught by Wu. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for saving information about identified recurring transactions in a storage location so as maintain a record of identified recurring transactions for future analysis. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Wu’s saving the identified recurring transactions in a storage location, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Wintle does not expressly disclose, however, Chaturvedi teaches:
causing display of a graphical user interface (GUI) on a user interface of an authenticated client device during execution of a mobile application or desktop application by the authenticated client device; (See Chaturvedi, Par. 46 (Other applications 153 includes a software program, such as a graphical user interface (GUI), executable by a processor that is configured to interface to a user.))
. . . under a user-designated name associated with and specific to the executed identified transaction, (See Chaturvedi, Par. 30 (The payment service module 130, in one implementation, may be adapted to maintain one or more user accounts, merchant accounts, and transaction records in the user accounts database 133. As such, the user accounts database 133 may store account information associated with one or more individual users (e.g., the user associated with communication device 150) and merchants and transaction data associated with transactions.), Par. 48 (The user identifier 155 may include one or more attributes
related to the user of the communication device 150, such as personal information related to the user (e.g., one or more user names, passwords, photograph images, biometric IDs, addresses, phone numbers, social security number, etc.) and banking information and/or funding sources (e.g., one or more banking institutions, credit card issuers, user account numbers, security data and information, etc.).), Par. 64 (The transaction information for a transaction may correspond to the name or other identifier for entities in the transaction, items involved in the transaction.))
classifying the executed identified transaction as a recurring transaction. (See Chaturvedi, Abstract (The server may classify the transaction as a recurrent
transaction with a machine learning-trained classifier based on one or more periodicities associated with the transaction and other data. The transaction processing server may generate a recurrent flag based on the classifying.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, classifying an identified transaction as a recurring transaction, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for classifying an identified transaction as a recurring transaction so as to assist in identifying subsequent transactions as recurring. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s classifying an identified transaction as recurring, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 23:
Wintle, Wu and Chaturvedi teach each and every element of Claim 21 above.
Wintle does not expressly disclose, however, Chaturvedi teaches:
automatically executing a future transaction upon receipt of a second user command that references the user-designated name. (See Chaturvedi, Abstract (The server may classify the transaction as a recurrent transaction with a machine learning-trained classifier based on one or more periodicities associated with the transaction and other data. The transaction processing server may generate a recurrent flag based on the classifying. The transaction processing server may communicate, through the application programming interface to an issuer host device, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device.), Par. 69 (The transaction periodicity forecast module 120 may communicate, through the API 202 to the issuer host device 170, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device 170. If the transaction authentication is successful, the issuer host device 170 can pass monetary funds to the acquirer host 160 associated with the merchant server 140 to obtain payment.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, executing a future transaction based on a second user command, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for executing a future transaction based on a second user command so as to expedite execution of a user’s recurring transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s executing a future transaction based on a second user command, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 24:
Wintle, Wu and Chaturvedi teach each and every element of Claim 21 above.
Wintle does not expressly disclose, however, Chaturvedi teaches:
automatically executing, upon receipt of a second user command, a future transaction at a predetermined time period using the transaction details of the identified transaction. (See Chaturvedi, Abstract (The server may classify the transaction as a recurrent transaction with a machine learning-trained classifier based on one or more periodicities associated with the transaction and other data. The transaction processing server may generate a recurrent flag based on the classifying. The transaction processing server may communicate, through the application programming interface to an issuer host device, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device.), Par. 69 (The transaction periodicity forecast module 120 may communicate, through the API 202 to the issuer host device 170, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device 170. If the transaction authentication is successful, the issuer host device 170 can pass monetary funds to the acquirer host 160 associated with the merchant server 140 to obtain payment.), Par. 84 (The transaction periodicity forecast module 120, using the request generation engine 124, can send a payment request with the recurrent flag set to the issuer host device 170. The payment request can indicate the payment amount, the receiver and buyer as well as flags including the recurrent flag.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, executing a future transaction based on a second user command, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for executing a future transaction based on a second user command so as to expedite execution of a user’s recurring transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s executing a future transaction based on a second user command, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 25:
Wintle, Wu and Chaturvedi teach each and every element of Claim 21 above.
Wintle does not expressly disclose, however, Chaturvedi teaches:
the transaction details comprise one or more of a payee name, a transaction amount, a source account of the user, and a date of completion of the second transaction. (See Chaturvedi, Par. 84 (The transaction periodicity forecast module 120, using the request generation engine 124, can send a payment request with the recurrent flag set to the issuer host device 170. The payment request can indicate the payment amount, the receiver and buyer as well as flags including the recurrent flag.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, a step to include the details of the transaction, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step to include the details of the transaction so provide the transaction details to the user. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s a step to include the details of the transaction, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 28:
Wintle teaches:
A computer program product comprising at least one non-transitory computer readable medium having with a set of instructions of computer-executable program code, which when executed by one or more processors of a server computing system, causes the server computing system to perform operations including: (See Wintle, Claim 14 (A non-transitory computer readable medium having stored thereon instructions to process recurring transaction payments, which when executed by a processor of a computer,
cause the computer to:), Par. 83 (At least some aspects disclosed can be embodied, at least in part, in software. That is, the techniques may be carried out in a computer system or other data processing system in response to its processor, such as a microprocessor, executing sequences of instructions contained in a memory, such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device.))
storing a plurality of executed transactions in a storage location as stored user financial account data; (See Wintle, Par. 19 (Details of the payment device transaction may be stored as payment transaction records in a transaction database within or accessible to the servers 116 of the payment processor 102.), Par. 33 (In embodiments, the AI platform 124 may include at least one machine learning (ML) model 126 and a transaction database 128 comprising historical payment transaction data, as discussed further below.))
training, via the one or more ML algorithms based on the stored user financial account data, one or more machine learning models to identify a financial transaction as a recurring financial transaction; (See Wintle, Par. 33 (This may be accomplished by processing and analyzing transactions through an artificial intelligence (AI) platform 124 to improve the ability of payment processor 102 to identify recurring transactions and key attributes thereof. In embodiments, the AI platform 124 may include at least one machine learning (ML) model 126 and a transaction database 128 comprising historical payment transaction data, as discussed further below.), Par. 37 (Historical payment transaction data is accessed from the transaction database 128 to train a machine learning (ML) model of the AI platform 124 to predict future recurring transactions from the historical payment transaction data (block 202).)
receiving, from the authenticated client device via the GUI, a user command to execute a transaction using funds from a source account, the transaction including transaction details; (See Wintle, Fig. 1, Par. 19 (The payment processor 102 may refer to an entity that receives transaction authorization requests from the merchant 108, and other entities and provides guarantees of payment.), Par. 23 (The merchant 108 may refer to one or more entities (e.g., operators of retail businesses) that provide goods and/or services, and/or access to goods and/or services, to a cardholder, based on a transaction, such as a payment transaction.), Par. 27 (Once the cardholder 106 presents the account identifier to the merchant 108 for a transaction, a computer of the merchant forwards the account identifier along with other transactional details, such as the payment amount, to the acquirer 104.), Par. 28 (Once the authorization data is received, the issuer 110 determines if the cardholder 106 is authorized to perform the given transaction (e.g., payment, cash deposit/withdrawal, money transfer, balance inquiries), and returns an authorization response message.))
identifying, via the trained one or more machine learning models based on the transaction details, the transaction as a recurring transaction; (See Wintle, Par. 33 (This may be accomplished by processing and analyzing
transactions through an artificial intelligence (AI) platform 124 to improve the ability of payment processor 102 to identify recurring transactions and key attributes thereof. In embodiments, the AI platform 124 may include at least one machine learning (ML) model 126 and a transaction database 128 comprising historical payment transaction data.))
executing, via the API, the identified transaction using the transaction details; and (See Wintle, Par. 33 (An application programming interface (API) 122 is implemented between the payment processor 102 and the issuer 110 to open a new communication channel between the Al platform 124 and the issuer 110. The API 122 may be solely for communicating information relating to the recurring transactions.), Par. 55 (The payment processor 102 checks if the authorization request includes any recurring transactions indicators. For example, the payment processor 102 may check if the recurring transaction includes any recurring identifier parameters.), Par. 56 (The AI platform 124 monitors the consolidated transaction log 328 and retrieves the entry of the newly added transaction details having recurring indicators.), Par. 57 (Thereafter, the payment processor 102 continues with processing the transaction and routes an authorization request with transaction details to the issuer 110 based on normal processing rules.))
Wintle does not expressly disclose, however, Wu teaches:
saving the executed identified transaction in the storage location . . . , and (See Wu, Par. 45 (Trigger model 408 is also trained to identify recurring transactions in transaction data 402, and can reference information from past data model 402 (through tagged data storage 414) to determine that the transaction is recurring. This information about the transaction can be provided to tagged data storage 414, in accordance with an embodiment.), Par. 57 (At step 602, transaction information regarding a transaction is received, for example transaction data 402 received at machine learning models 404 of FIG. 4. At step 604, secondary information regarding the transaction is received-this could be contact information (including names and photos).))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, saving information about identified recurring transactions in a storage location, as taught by Wu. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for saving information about identified recurring transactions in a storage location so as maintain a record of identified recurring transactions for future analysis. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Wu’s saving the identified recurring transactions in a storage location, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Wintle does not expressly disclose, however, Chaturvedi teaches:
causing display of a graphical user interface (GUI) on a user interface of an authenticated client device during execution of a mobile application or desktop application by the authenticated client device; (See Chaturvedi, Par. 46 (Other applications 153 includes a software program, such as a graphical user interface (GUI), executable by a processor that is configured to interface to a user.))
. . . under a user-designated name associated with and specific to the executed identified transaction, (See Chaturvedi, Par. 30 (The payment service module 130, in one implementation, may be adapted to maintain one or more user accounts, merchant accounts, and transaction records in the user accounts database 133. As such, the user accounts database 133 may store account information associated with one or more individual users (e.g., the user associated with communication device 150) and merchants and transaction data associated with transactions.), Par. 48 (The user identifier 155 may include one or more attributes
related to the user of the communication device 150, such as personal information related to the user (e.g., one or more user names, passwords, photograph images, biometric IDs, addresses, phone numbers, social security number, etc.) and banking information and/or funding sources (e.g., one or more banking institutions, credit card issuers, user account numbers, security data and information, etc.).), Par. 64 (The transaction information for a transaction may correspond to the name or other identifier for entities in the transaction, items involved in the transaction.))
classifying the executed identified transaction as a recurring transaction. (See Chaturvedi, Abstract (The server may classify the transaction as a recurrent
transaction with a machine learning-trained classifier based on one or more periodicities associated with the transaction and other data. The transaction processing server may generate a recurrent flag based on the classifying.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, classifying an identified transaction as a recurring transaction, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for classifying an identified transaction as a recurring transaction so as to assist in identifying subsequent transactions as recurring. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s classifying an identified transaction as recurring, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 30:
Wintle, Wu and Chaturvedi teach each and every element of Claim 28 above.
Wintle does not expressly disclose, however, Chaturvedi teaches:
automatically executing a future transaction upon receipt of a second user command that references the user-designated name. (See Chaturvedi, Abstract (The server may classify the transaction as a recurrent transaction with a machine learning-trained classifier based on one or more periodicities associated with the transaction and other data. The transaction processing server may generate a recurrent flag based on the classifying. The transaction processing server may communicate, through the application programming interface to an issuer host device, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device.), Par. 69 (The transaction periodicity forecast module 120 may communicate, through the API 202 to the issuer host device 170, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device 170. If the transaction authentication is successful, the issuer host device 170 can pass monetary funds to the acquirer host 160 associated with the merchant server 140 to obtain payment.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, executing a future transaction based on a second user command, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for executing a future transaction based on a second user command so as to expedite execution of a user’s recurring transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s executing a future transaction based on a second user command, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 31:
Wintle, Wu and Chaturvedi teach each and every element of Claim 28 above.
Wintle does not expressly disclose, however, Chaturvedi teaches:
perform operations including automatically executing, upon receipt of a second user command, a future transaction at a predetermined time period using the transaction details of the identified transaction. (See Chaturvedi, Abstract (The server may classify the transaction as a recurrent transaction with a machine learning-trained classifier based on one or more periodicities associated with the transaction and other data. The transaction processing server may generate a recurrent flag based on the classifying. The transaction processing server may communicate, through the application programming interface to an issuer host device, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device.), Par. 69 (The transaction periodicity forecast module 120 may communicate, through the API 202 to the issuer host device 170, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device 170. If the transaction authentication is successful, the issuer host device 170 can pass monetary funds to the acquirer host 160 associated with the merchant server 140 to obtain payment.), Par. 84 (The transaction periodicity forecast module 120, using the request generation engine 124, can send a payment request with the recurrent flag set to the issuer host device 170. The payment request can indicate the payment amount, the receiver and buyer as well as flags including the recurrent flag.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, executing a future transaction based on a second user command, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for executing a future transaction based on a second user command so as to expedite execution of a user’s recurring transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s executing a future transaction based on a second user command, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 32:
Wintle, Wu and Chaturvedi teach each and every element of Claim 28 above.
Wintle does not expressly disclose, however, Chaturvedi teaches:
the transaction details comprise one or more of a payee name, a transaction amount, a source account of the user, and a date of completion of the second transaction. (See Chaturvedi, Par. 84 (The transaction periodicity forecast module 120, using the request generation engine 124, can send a payment request with the recurrent flag set to the issuer host device 170. The payment request can indicate the payment amount, the receiver and buyer as well as flags including the recurrent flag.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, a step to include the details of the transaction, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step to include the details of the transaction so provide the transaction details to the user. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s a step to include the details of the transaction, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 35:
Wintle teaches:
A computer-implemented method implemented by a server computing system, the computer-implemented method comprising: (See Wintle, Claim 1 (A system, comprising: an artificial intelligence (AI) platform including one or more machine learning (ML) models; one or more server computers each having a processor coupled to a memory and in communication with the AI platform; and one or more software components executed by the one or more server computers that are configured to:), Par. 83 (At least some aspects disclosed can be embodied, at least in part, in software. That is, the techniques may be carried out in a computer system or other data processing system in response to its processor, such as a microprocessor, executing sequences of instructions contained in a memory, such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device.))
storing a plurality of executed transactions in a storage location as stored user financial account data; (See Wintle, Par. 19 (Details of the payment device transaction may be stored as payment transaction records in a transaction database within or accessible to the servers 116 of the payment processor 102.), Par. 33 (In embodiments, the AI platform 124 may include at least one machine learning (ML) model 126 and a transaction database 128 comprising historical payment transaction data, as discussed further below.))
training, via one or more ML algorithms of a machine learning (ML) module based on the stored user financial account data, one or more machine learning models to identify a financial transaction as a recurring financial transaction; (See Wintle, Par. 33 (This may be accomplished by processing and analyzing transactions through an artificial intelligence (AI) platform 124 to improve the ability of payment processor 102 to identify recurring transactions and key attributes thereof. In embodiments, the AI platform 124 may include at least one machine learning (ML) model 126 and a transaction database 128 comprising historical payment transaction data, as discussed further below.), Par. 37 (Historical payment transaction data is accessed from the transaction database 128 to train a machine learning (ML) model of the AI platform 124 to predict future recurring transactions from the historical payment transaction data (block 202).)
receiving, from the authenticated client device via the GUI, a user command to execute a transaction using funds from a source account, the transaction including transaction details; (See Wintle, Fig. 1, Par. 19 (The payment processor 102 may refer to an entity that receives transaction authorization requests from the merchant 108, and other entities and provides guarantees of payment.), Par. 23 (The merchant 108 may refer to one or more entities (e.g., operators of retail businesses) that provide goods and/or services, and/or access to goods and/or services, to a cardholder, based on a transaction, such as a payment transaction.), Par. 27 (Once the cardholder 106 presents the account identifier to the merchant 108 for a transaction, a computer of the merchant forwards the account identifier along with other transactional details, such as the payment amount, to the acquirer 104.), Par. 28 (Once the authorization data is received, the issuer 110 determines if the cardholder 106 is authorized to perform the given transaction (e.g., payment, cash deposit/withdrawal, money transfer, balance inquiries), and returns an authorization response message.))
identifying, via the trained one or more machine learning models based on the transaction details, the transaction as a recurring transaction; (See Wintle, Par. 33 (This may be accomplished by processing and analyzing
transactions through an artificial intelligence (AI) platform 124 to improve the ability of payment processor 102 to identify recurring transactions and key attributes thereof. In embodiments, the AI platform 124 may include at least one machine learning (ML) model 126 and a transaction database 128 comprising historical payment transaction data.))
executing, via an application programming interface, the identified transaction using the transaction details; and (See Wintle, Par. 33 (An application programming interface (API) 122 is implemented between the payment processor 102 and the issuer 110 to open a new communication channel between the Al platform 124 and the issuer 110. The API 122 may be solely for communicating information relating to the recurring transactions.), Par. 55 (The payment processor 102 checks if the authorization request includes any recurring transactions indicators. For example, the payment processor 102 may check if the recurring transaction includes any recurring identifier parameters.), Par. 56 (The AI platform 124 monitors the consolidated transaction log 328 and retrieves the entry of the newly added transaction details having recurring indicators.), Par. 57 (Thereafter, the payment processor 102 continues with processing the transaction and routes an authorization request with transaction details to the issuer 110 based on normal processing rules.))
Wintle does not expressly disclose, however, Wu teaches:
saving the executed identified transaction in the storage location . . . , and (See Wu, Par. 45 (Trigger model 408 is also trained to identify recurring transactions in transaction data 402, and can reference information from past data model 402 (through tagged data storage 414) to determine that the transaction is recurring. This information about the transaction can be provided to tagged data storage 414, in accordance with an embodiment.), Par. 57 (At step 602, transaction information regarding a transaction is received, for example transaction data 402 received at machine learning models 404 of FIG. 4. At step 604, secondary information regarding the transaction is received-this could be contact information (including names and photos).))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, saving information about identified recurring transactions in a storage location, as taught by Wu. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for saving information about identified recurring transactions in a storage location so as maintain a record of identified recurring transactions for future analysis. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Wu’s saving the identified recurring transactions in a storage location, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Wintle does not expressly disclose, however, Chaturvedi teaches:
causing display of a graphical user interface (GUI) on a user interface of an authenticated client device during execution of a mobile application or desktop application by the authenticated client device; (See Chaturvedi, Par. 46 (Other applications 153 includes a software program, such as a graphical user interface (GUI), executable by a processor that is configured to interface to a user.))
. . . under a user-designated name associated with and specific to the executed identified transaction, See Chaturvedi, Par. 30 (The payment service module 130, in one implementation, may be adapted to maintain one or more user accounts, merchant accounts, and transaction records in the user accounts database 133. As such, the user accounts database 133 may store account information associated with one or more individual users (e.g., the user associated with communication device 150) and merchants and transaction data associated with transactions.), Par. 48 (The user identifier 155 may include one or more attributes related to the user of the communication device 150, such as personal information related to the user (e.g., one or more user names, passwords, photograph images, biometric IDs, addresses, phone numbers, social security number, etc.) and banking information and/or funding sources (e.g., one or more banking institutions, credit card issuers, user account numbers, security data and information, etc.).), Par. 64 (The transaction information for a transaction may correspond to the name or other identifier for entities in the transaction, items involved in the transaction.))
classifying the executed identified transaction as a recurring transaction. (See Chaturvedi, Abstract (The server may classify the transaction as a recurrent
transaction with a machine learning-trained classifier based on one or more periodicities associated with the transaction and other data. The transaction processing server may generate a recurrent flag based on the classifying.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, classifying an identified transaction as a recurring transaction, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for classifying an identified transaction as a recurring transaction so as to assist in identifying subsequent transactions as recurring. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s classifying an identified transaction as recurring, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 37:
Wintle, Wu and Chaturvedi teach each and every element of Claim 35 above.
Wintle does not expressly disclose, however, Chaturvedi teaches:
automatically executing a future transaction upon receipt of a second user command that references the user-designated name. (See Chaturvedi, Abstract (The server may classify the transaction as a recurrent transaction with a machine learning-trained classifier based on one or more periodicities associated with the transaction and other data. The transaction processing server may generate a recurrent flag based on the classifying. The transaction processing server may communicate, through the application programming interface to an issuer host device, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device.), Par. 69 (The transaction periodicity forecast module 120 may communicate, through the API 202 to the issuer host device 170, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device 170. If the transaction authentication is successful, the issuer host device 170 can pass monetary funds to the acquirer host 160 associated with the merchant server 140 to obtain payment.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, executing a future transaction based on a second user command, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for executing a future transaction based on a second user command so as to expedite execution of a user’s recurring transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s executing a future transaction based on a second user command, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 38:
Wintle, Wu and Chaturvedi teach each and every element of Claim 35 above.
Wintle does not expressly disclose, however, Chaturvedi teaches:
automatically executing, upon receipt of a second user command, a future transaction at a predetermined time period using the transaction details of the identified transaction. (See Chaturvedi, Abstract (The server may classify the transaction as a recurrent transaction with a machine learning-trained classifier based on one or more periodicities associated with the transaction and other data. The transaction processing server may generate a recurrent flag based on the classifying. The transaction processing server may communicate, through the application programming interface to an issuer host device, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device.), Par. 69 (The transaction periodicity forecast module 120 may communicate, through the API 202 to the issuer host device 170, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device 170. If the transaction authentication is successful, the issuer host device 170 can pass monetary funds to the acquirer host 160 associated with the merchant server 140 to obtain payment.), Par. 84 (The transaction periodicity forecast module 120, using the request generation engine 124, can send a payment request with the recurrent flag set to the issuer host device 170. The payment request can indicate the payment amount, the receiver and buyer as well as flags including the recurrent flag.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, executing a future transaction based on a second user command, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for executing a future transaction based on a second user command so as to expedite execution of a user’s recurring transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s executing a future transaction based on a second user command, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 42:
Wintle, Wu and Chaturvedi teach each and every element of Claim 23 above.
Wintle does not expressly disclose, however, Chaturvedi teaches:
retrieving, prior to executing the future transaction, the transaction details associated with the user-designated name. (See Chaturvedi, Abstract (The server may classify the transaction as a recurrent transaction with a machine learning-trained classifier based on one or more periodicities associated with the transaction and other data. The transaction processing server may generate a recurrent flag based on the classifying. The transaction processing server may communicate, through the application programming interface to an issuer host device, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device.), Par. 69 (The transaction periodicity forecast module 120 may communicate, through the API 202 to the issuer host device 170, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device 170. If the transaction authentication is successful, the issuer host device 170 can pass monetary funds to the acquirer host 160 associated with the merchant server 140 to obtain payment.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, executing a future transaction based on a second user command, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for executing a future transaction based on a second user command so as to expedite execution of a user’s recurring transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s executing a future transaction based on a second user command, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 43:
Wintle, Wu and Chaturvedi teach each and every element of Claim 30 above.
Wintle does not expressly disclose, however, Chaturvedi teaches:
retrieving, prior to executing the future transaction, the transaction details associated with the user-designated name. See Chaturvedi, Abstract (The server may classify the transaction as a recurrent transaction with a machine learning-trained classifier based on one or more periodicities associated with the transaction and other data. The transaction processing server may generate a recurrent flag based on the classifying. The transaction processing server may communicate, through the application programming interface to an issuer host device, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device.), Par. 69 (The transaction periodicity forecast module 120 may communicate, through the API 202 to the issuer host device 170, a second transaction request comprising the transaction and the recurrent flag for authenticating the transaction at the issuer host device 170. If the transaction authentication is successful, the issuer host device 170 can pass monetary funds to the acquirer host 160 associated with the merchant server 140 to obtain payment.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above, executing a future transaction based on a second user command, as taught by Chaturvedi. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for executing a future transaction based on a second user command so as to expedite execution of a user’s recurring transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Chaturvedi’s executing a future transaction based on a second user command, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claims 26, 33 and 39 are rejected under 35 U.S.C. 103 as being unpatentable over Wintle et al., US 2022/0245641 A1, (“Wintle”), in view of Wu et al., US 2022/0005016 A1, (“Wu”), in further view of Chatuverdi, US 2021/0406896 A1, (“Chaturvedi”), in further view of Nolte et al., US 10,460,299 B1, (“Nolte”).
Claim 26:
Wintle, Wu and Chaturvedi teach each and every element of Claim 21 above.
Wintle does not expressly disclose, however, Nolte teaches:
executing the transaction using an online bill payment system. (See Nolte, Col. 4, lines 7-8 (Many users utilize an on-line bill pay system that automatically
charges a payment instrument for recurring bills.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above a step for executing a recurring transaction with an online bill payment system, as taught by Nolte. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for executing a recurring transaction with an online bill payment system so as to expedite execution of a user’s recurring transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Nolte’s executing a recurring transaction with an online bill payment system, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 33:
Wintle, Wu and Chaturvedi teach each and every element of Claim 28 above.
Wintle does not expressly disclose, however, Nolte teaches:
executing the transaction using an online bill payment system. (See Nolte, Col. 4, lines 7-8 (Many users utilize an on-line bill pay system that automatically charges a payment instrument for recurring bills.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above a step for executing a recurring transaction with an online bill payment system, as taught by Nolte. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for executing a recurring transaction with an online bill payment system so as to expedite execution of a user’s recurring transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Nolte’s executing a recurring transaction with an online bill payment system, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 39:
Wintle, Wu and Chaturvedi teach each and every element of Claim 38 above.
Wintle does not expressly disclose, however, Nolte teaches:
executing the transaction using an online bill payment system. (See Nolte, Col. 4, lines 7-8 (Many users utilize an on-line bill pay system that automatically
charges a payment instrument for recurring bills.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above a step for executing a recurring transaction with an online bill payment system, as taught by Nolte. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for executing a recurring transaction with an online bill payment system so as to expedite execution of a user’s recurring transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Nolte’s executing a recurring transaction with an online bill payment system, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claims 27, 34 and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Wintle et al., US 2022/0245641 A1, (“Wintle”), in view of Wu et al., US 2022/0005016 A1, (“Wu”), in further view of Chatuverdi, US 2021/0406896 A1, (“Chaturvedi”), in further view of Nolte et al., US 10,460,299 B1, (“Nolte”), in further view of Ivanoff et al., US 2015/0193872 A1, (“Ivanoff”).
Claim 27:
Wintle, Wu, Chaturvedi and Nolte teach each and every element of Claim 26 above.
Wintle does not expressly disclose, however, Ivanoff teaches:
automatically populating input fields of the online bill payment system using the transaction details. (See Ivanoff, Par. 33 (Patient/guarantor interfaces to billing systems, such as to make online bill payments, are fragmented and incomplete.), Par. 48 (The disclosed embodiments may use the extracted data and employ rigorous matching logic to automatically populate an account of a registered guarantor with information (and particularly billing information) for visits of the guarantor and/or associated beneficiaries.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above a step for automatically populating input fields of the online bill payment system, as taught by Ivanoff. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for automatically populating input fields of the online bill payment system so as to expedite execution of a user’s transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Ivanoff’s automatically populating input fields of the online bill payment system, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 34:
Wintle, Wu, Chaturvedi and Nolte teach each and every element of Claim 33 above.
Wintle does not expressly disclose, however, Ivanoff teaches:
perform operations including automatically populating input fields of the online bill payment system using the transaction details. (See Ivanoff, Par. 33 (Patient/guarantor interfaces to billing systems, such as to make online bill payments, are fragmented and incomplete.), Par. 48 (The disclosed embodiments may use the extracted data and employ rigorous matching logic to automatically populate an account of a registered guarantor with information (and particularly billing information) for visits of the guarantor and/or associated beneficiaries.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above a step for automatically populating input fields of the online bill payment system, as taught by Ivanoff. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for automatically populating input fields of the online bill payment system so as to expedite execution of a user’s transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Ivanoff’s automatically populating input fields of the online bill payment system, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claim 40:
Wintle, Wu, Chaturvedi and Nolte teach each and every element of Claim 39 above.
Wintle does not expressly disclose, however, Ivanoff teaches:
automatically populating input fields of the online bill payment system using the transaction details. (See Ivanoff, Par. 33 (Patient/guarantor interfaces to billing systems, such as to make online bill payments, are fragmented and incomplete.), Par. 48 (The disclosed embodiments may use the extracted data and employ rigorous matching logic to automatically populate an account of a registered guarantor with information (and particularly billing information) for visits of the guarantor and/or associated beneficiaries.))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine with the teachings of Wintle discussed above a step for automatically populating input fields of the online bill payment system, as taught by Ivanoff. Wintle teaches a system where transaction data from an authorization request is input into machine learning models to predict a payment transaction comprises a recurring payment transaction. It would be obvious for --Wintle to include a step for automatically populating input fields of the online bill payment system so as to expedite execution of a user’s transactions. Since the claimed invention is merely a combination of old elements, Wintle’s system for identifying recurring transactions and Ivanoff’s automatically populating input fields of the online bill payment system, and in the combination each element would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Conclusion
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 GEORGE PROIOS whose telephone number is (571)272-4573. The examiner can normally be reached M-F 8-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at 303-297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/GEORGE N. PROIOS/Examiner, Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694
Prosecution Insights