DETAILED ACTION
Status of Claims
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to the response to the amendment filed on 12/22/2025.
Claims 1, 3, 6, 15, 17, 20, and 22 have been amended.
Claim 2, 7-8, and 16 has been cancelled.
Claim 23-24 has been added.
Claims 10-14 have been withdrawn from consideration.
Claims 1, 3-6, 9, 15, and 17-24 are currently pending and have been examined.
The previous 112(b) rejections have been withdrawn due to applicant’s amendments.
Response to Arguments
Applicant's arguments filed 12/22/2025 have been fully considered but they are not persuasive.
With regards to 101, Applicant argues #1:
Without acquiescing to the correctness of the rejection and solely for the purpose of advancing prosecution, claim 1 has been amended… To be sure, at least the above-emphasized elements explicitly relate to an improvement to computer technology, and more specifically to electronic transaction processing via a plurality of transaction routes within a network of computing devices, which does not merely recite "commercial or legal interactions," "including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations." M.P.E.P. § 2106.04(a)(2)(II).
Thus, even assuming, arguendo, the claims recite an abstract idea, which Applicant refutes, the claims are instead directed to an "improve[ment to] the functioning of a computer or... another technology or technical field," such that the claims are patent eligible under Step 2A Prong One and/or Prong Two. M.P.E.P. § 2106.04(d)(1). To be sure, aside from generally reciting "commercial or legal interactions" or purportedly "performing record keeping task for tracking transaction information" and "sending the transactions via transaction routes to other computer systems to be processed" (for which the Office Action appears to cite all of the claimed operations/steps; see Office Action, pgs. 8-10), the claims recite additional elements other than merely including "a processor, memory, a second and third computing device, and machine learning model." Office Action, pg. 10; see also M.P.E.P. §2106.04(a), requiring that a prima facie analysis under § 101 "should determine whether a claim recites an abstract idea by (1) identifying the specific limitation(s) in the claim under examination that the examiner believes recites an abstract idea, and (2) determining whether the identified limitations(s)fall within at least one of the groupings of abstract ideas listed above" (emphasis added).
Indeed, rather than generally reciting only a "record keeping task for tracking transaction information," at least the above-emphasized elements instead recite specific, technical aspects in the context of a computer network for electronic processing, thereby yielding improved fault tolerance and dynamic processing according to transaction route health. See, e.g., Specification, paras. [0025]-[0026]. Such selective processing among a plurality of transaction routes (e.g., each having one or more associated computing devices) and dynamic transaction data adaptation by a transaction platform to yield an improved likelihood of success via a selected electronic transaction route do not have a traditional financial analogue (nor do they merely recite a "record keeping task" nor "sending the transactions ... to other computer systems to be processed") and instead address a technical problem that exists in the realm of electronic transaction processing. Accordingly, counter to the assertion the claims "do not mount to a practical application or technical improvement," at least such aspects reflect an improvement to the technical field of electronic transaction processing. Office Action, pg. 3.
Additionally, at least the above-quoted elements of claim 1 reflect a configuration of elements that does not merely constitute a generic computer arrangement. Rather, as noted above, at least such additional elements reflect an improvement in the functioning of a computer (e.g., a transaction platform in conjunction with associated computing devices) or an improvement to other technology or technical field, thereby integrating any such alleged abstract idea into a practical application under Step 2A Prong Two. See M.P.E.P. § 2106.04(d)(I).
Thus, for at least the foregoing reasons, Applicant respectfully submits that any alleged judicial exception is integrated "into a practical application of that exception," such that "the claim is not directed to the judicial exception . .. and thus is eligible" under Step 2A Prong Two. M.P.E.P. § 2106.04(II)(A)(2).
Examiners response:
With respect to applicant’s arguments that the claims do not reflect “a traditional financial analogue”, and are indicative of a configuration of elements that result in a technical improvement, the Examiner respectfully disagrees. The courts have used the phrases "fundamental economic practices" or "fundamental economic concepts" to describe concepts relating to the economy and commerce, such as agreements between people in the form of contracts, legal obligations, and business relations. The term "fundamental" is used in the sense of being foundational or basic, and not in the sense of necessarily being "old" or "well-known." See, e.g., In re Smith, 815 F.3d 816, 818-19, 118 USPQ2d 1245, 1247 (Fed. Cir. 2016) (see MPEP 2106.04(a)(2)). “The Supreme Court’s decisions make it clear that judicial exceptions need not be old or long-prevalent, and that even newly discovered or novel judicial exceptions are still exceptions.” (MPEP 2106.04(I)). Further, the Examiner fails to see how the claims amount to a technical or significantly more than the abstract idea, as the limitations are directed toward several steps for processing a transaction, while the claims may be generating and using rules to determine what data and which routes are likely to be successful to process the transaction, this is further describing abstract concepts relating to sales activities and business activities for processing the transaction. Alice shows it’s well within in a computer’s capabilities to perform these task, and thus the claims are ineligible for the same reasons. In Alice, the Courts walked through the test and found:
The Court identified the additional elements in the claim, e.g., by noting that the method claims recited steps of using a computer to "create electronic records, track multiple transactions, and issue simultaneous instructions", and that the product claims recited hardware such as a "data processing system" with a "communications controller" and a "data storage unit" (573 U.S. at 224-26, 110 USPQ2d at 1984-85);
PNG
media_image1.png
18
19
media_image1.png
Greyscale
The Court considered the additional elements individually, noting that all the computer functions were "‘well-understood, routine, conventional activit[ies]’ previously known to the industry," each step "does no more than require a generic computer to perform generic computer functions", and the recited hardware was "purely functional and generic" (573 U.S. at 225-26, 110 USPQ2d at 1984-85); and
Akin to Alice, the claims are performing record keeping task for tracking transaction information to analyze to generate rules and send the transactions to be processed accordingly. See also, Performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims.");.
For the reasons above, applicant’s arguments are not persuasive.
With regards to 101, Applicant argues #2:
Additionally, under Step 2B, the M.P.E.P. notes an "inventive concept may be found in the non-conventional and non-generic arrangement of components that are individually well- known and conventional." M.P.E.P. § 2106.05 (emphasis added). Indeed, even though, as noted by the Office Action, the claims recite a "processor," "memory," and "computing devices," the claims recite a specific configuration of such elements that perform a specific, non- conventional, and non-generic set of operations (e.g., as performed, at least in part, by the claimed "transaction platform") that thus constitute a system that is not well-understood, routine, and conventional, which is therefore further patent eligible under Step 2B of the subject matter eligibility analysis. See M.P.E.P. § 2106.05(d)(I)(2), noting "if [an] element is not widely prevalent or in common use, or is otherwise beyond those elements recognized in the art or by the courts as being well-understood, routine or conventional, then the element will in most cases favor eligibility" (emphasis added); see also M.P.E.P. § 2106.05(d)(I)(3), noting "the combination of additional elements may amount to an inventive concept."
As such, Applicant respectfully submits claim 1 recites a system comprising a particular configuration of elements that thus yields an improvement to electronic transaction processing and, more specifically, within the context of a network of computing devices each having an associated transaction route, which amounts to significantly more than any purported judicial exception. Accordingly, claim 1 therefore recites patent eligible subject matter. Independent claim 15 recites similar elements as claim 1 and is therefore patent eligible for at least similar reasons. Finally, the dependent claims each depend from claim 1 or claim 15, and are therefore also allowable for at least similar reasons.
Accordingly, Applicant respectfully submits that the claims recite statutory subject matter for at least the foregoing reasons and respectfully requests that the Examiner withdraw the rejection and issue a Notice of Allowance at the Examiner's earliest convenience.
Examiners response:
The Examiner respectfully disagrees, claim 1 for example is directed towards a system comprising a processer and memory which performing record keeping task for tracking transaction information to analyze to generate rules and send the transactions to be processed, sending the transactions via transaction routes to other computer systems to be processed. The Examiner fails to see how this is an inventive configuration or amounts to significantly more. That is to say, the claims do not have an inventive concept found in the non-conventional and non-generic arrangement of the additional elements as was for example Bascom. Additionally, several Court decisions ion MPEP 2106.05(d), show it’s well within a computer’s capability to send and receive data over a network to between the system and second and third computing devices, as this is merely describing the technical environment in which the idea is being limited to and therefor does not amount to significantly more (see MPEP 20106.05(h)) and MPEP 2106.05(f) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone);.
For the reasons above, the 101 rejection of claims 1, 3-6, 9, 15, and 17-24 is hereby maintained.
With regards to 102, Applicant argues:
Amended claim 1 recites, inter alia, “in response to determining approval to utilize the trans Without acquiescing to the correctness of the rejection and solely for the purpose of advancing prosecution, claim 1 has been amended to recite, inter alia, "accessing, by a transaction platform, transaction completion information associated with a set of transactions of a transaction platform, wherein each transaction of the set of transactions was transmitted using a specific transaction route of a set of transaction routes; identifying, by the transaction platform and based on the transaction completion information, a first categorized subset of transactions from the set of transactions and a second categorized subset of transactions from the set of transactions, wherein the first subset of transactions comprises successful transactions for the specific transaction route and the second subset of transactions comprises unsuccessful transactions for the specific transaction route; generating, by the transaction platform and for the specific transaction route, a transaction rule that comprises adapting, based on a difference between the first categorized subset of transactions and the second categorized subset of transactions, a transaction to improve a likelihood of success via the specific transaction route ...; in response to determining approval to utilize the transaction rule for transaction processing, generating, by the transaction platform, an association between the transaction rule and the specific transaction route; ... determining to process the transaction via the specific transaction route from the set of transaction routes; and in response to determining to process the transaction via the specific transaction route: processing, by the transaction platform, the indicated transaction according to the generated transaction rule based on the association between the transaction rule and the specific transaction route, thereby adapting an attribute of the indicated transaction to improve a likelihood of success for processing the transaction rule via the specific transaction route; and submitting, by the transaction platform to a second computing device associated with the transaction route, the processed transaction for processing via the specific transaction route."
As noted above, Applicant appreciates the indication that the amended claim language appears to overcome the current art of record and, indeed, Koren, as presently understood, fails to anticipate at least the above-quoted aspects of amended claim 1. Accordingly, Applicant respectfully requests withdrawal of the § 102 rejections and that the Examiner issue a Notice of Allowance at the Examiner's earliest convenience.
Claim 15 has been amended to recite similar aspects recites as the above-discussed
elements of claim 1 and is therefore also allowable over Koren for at least similar reasons. For example, claim 15 recites, inter alia, "accessing, by the transaction platform, transaction completion information associated with a set of transactions of the transaction platform, wherein each transaction of the set of transactions was transmitted using a specific transaction route of a set of transaction routes; identifying, by the transaction platform and based on the transaction completion information, a first categorized subset of transactions from the set of transactions and a second categorized subset of transactions from the set of transactions, wherein the first subset of transactions comprises successful transactions for the specific transaction route and the second subset of transactions comprises unsuccessful transactions for the specific transaction route; generating, by the transaction platform and for the specific transaction route, a transaction rule for a set of transaction rules that comprises adapting, based on a difference between the first categorized subset of transactions and the second categorized subset of transactions, a transaction to improve a likelihood of success via the specific transaction route ... ; generating, by the transaction platform, an association between the transaction rule and the specific transaction route; determining to process a transaction via the specific transaction route from the set of transaction routes; and in response to determining to process the transaction via the specific transaction route: processing, by the transaction platform, the identified transaction according to the generated transaction rule based on the association between the transaction rule and the specific transaction route, thereby adapting an attribute of the identified transaction to improve a likelihood of success for processing the transaction rule via the specific transaction route; and submitting, by the transaction platform to a first computing device of the transaction route, the processed transaction for processing via the transaction route." Thus, Applicant respectfully submits claim 15 is allowable over Koren for at least the foregoing reasons.
Finally, the dependent claims each depend from one of allowable claims 1 or 15, and are therefore also allowable for at least similar reasons. Accordingly, Applicant respectfully requests that the Examiner withdraw the § 102 rejections and issue a Notice of Allowance at the Examiner's earliest convenience.
Examiners response:
The Examiner respectfully disagrees, upon further review of the Koren reference, Koren, in [0042], [0045], [0090], [0093], [0115-0120], [0138], and [0150]teaches the system retrieving from a plurality of data sources that can be used to train various models or derived various rules for processing the transaction and determining an optimal route. For example, a user history database 1952 can store user history information for specific users. In another example, the user history database 1952 can store transaction information and associate that transaction information with user personas… historical statistics (e.g., authorization rate on the issuer level and acquirer level on specific same risk level/segment); history of the specific user (e.g., related to acquirer used, payment method used and to successful completion of 3DS); purchase intent (in some embodiments the system is configured to analyze each transaction for a user (e.g., single user, group of users, similar users, etc.) as at least part of determining a payment intent, which enables the system to recognize a new transaction attempt (e.g., when there was a failed attempt for the same intent), and treat the new transaction accordingly (e.g., re-route, new payment method, etc.) to avoid another failure); risk—for example, the system can be configured to avoid entering card scheme fraud programs if there is a reduced likelihood of success;, and further In some embodiments, the system can implement outlier models and/or classification models to identify operations having higher risk and/or operations having low risk and characteristics of valid transactions… Transaction information can also be organized based on logical groupings to facilitate modeling… The models and processing rules can be derived from historic transaction information, successful, and/or failed executions… For example, the system can use the models to determine if a specific PSP will block a higher risk transaction whether not or an issuer receiving transaction from an acquirer from specific country is likely to block a transaction. The system can identify different routings, and selections of systems, where another route makes the transaction likely to succeed., anticipates the newly amended language in the accessing… and identifying limitations of the independent claims. The remaining amended limitations stand rejected as shown in the cited paragraphs in the 102 rejection below. For the reasons above, applicant’s arguments are not persuasive.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1, 3-6, 9, 15, and 17-24 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the processed transaction" in the 20th line of the claim. There is insufficient antecedent basis for this limitation in the claim.
Claim 15 recites the limitation "the processed transaction" in the 16th line of the claim. There is insufficient antecedent basis for this limitation in the claim.
Claims 3-6, 9, and 17-24 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite by virtue of being dependent on claims 1 and 15, respectively.
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, 3-6, 9, 15, and 17-24 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more, and fails step 2 of the analysis because the focus of the claims is not on the devices themselves or a practical application but rather directed towards an abstract idea, the analysis is provided below.
Step 1 (Statutory Categories) - The claims pass step 1 of the subject matter eligibility test (see MPEP 2106(III)) as the claims are directed towards a system, and method.
Step 2A – Prong One (Do the claims recite an abstract idea?) -
The idea is recited in the claim 1, in part, by:
accessing transaction completion information associated with a set of transactions of a transaction platform, wherein each transaction of the set of transactions was transmitted using a specific transaction route of a set of transaction routes;
identifying, based on the transaction completion information, a first categorized sub set of transactions from the set of transactions and a second categorized sub set of transactions from the set of transactions, wherein each transaction of the set of transactions was transmitted using a specific transaction route of a set of transaction routes;
generating for the specific route, a transaction rule that comprises adapting, based on a difference between the first categorized subset of transactions and the second categorized subset of transactions, a transaction to improve a likelihood of success via the specific transaction route, the adapting comprising at least one of:
adding an attribute to the processed transaction;
removing an attribute from the processed transaction; and
modifying an attribute of the processed transaction;
in response to determining approval to utilize the transaction rule for transaction processing, generating an association between the transaction rule and the specific transaction route;
receiving an indication of a transaction;
determining to process the transaction via the specific transaction route from the set of transaction routes; and
in response to determining to process the transaction via the specific transaction route:
processing the indicated transaction according to the generated transaction rule based on the association between the transaction rule and the specific transaction route, thereby adapting an attribute of the indicated transaction to improve a likelihood of success for processing the transaction rule via the specific transaction route; and
submitting the processed transaction for processing via the specific transaction route.
Claim 15, while varying in score, recites a similar idea, in part by:
accessing transaction completion information associated with a set of transactions of the transaction platform, wherein each transaction of the set of transactions was transmitted using a specific transaction route of a set of transaction routes;
identifying, based on the transaction completion information, a first categorized subset of transactions from the set of transactions and a second categorized subset of transactions from the set of transactions, wherein the first subset of transactions comprises successful transactions for the specific transaction route and the second subset of transactions comprises unsuccessful transactions for the specific transaction route;
generating for the specific transaction route, a transaction rule for a set of transaction rules that comprises adapting, based a difference on the first categorized subset of transactions and the second categorized subset of transactions, a transaction to improve a likelihood of success via the specific transaction route, the adapting comprising at least one of:
adding an attribute to the processed transaction;
removing an attribute from the processed transaction; and
modifying an attribute of the processed transaction;
generating an association between the transaction rule and the specific transaction route;
determining to process a transaction to via the specific transaction route from the set of transaction routes; and
in response to determining to process the transaction via the specific transaction route:
processing the identified transaction according to the generated transaction rule based on the association between the transaction rule and the specific transaction route, thereby adapting an attribute of the identified transaction to improve a likelihood of success for processing the transaction rule via the specific transaction route; and
submitting the processed transaction for processing via the transaction route.
The steps recited above under Step 2A Prong One of the analysis under the broadest reasonable interpretation covers commercial or legal interactions (including marketing or sales activities or behaviors; business relations) but for the recitation of generic computer components. That is other than reciting a processer, memory, a transaction platform, a second and third computing device, and machine learning model nothing in the claim elements are directed towards anything other than, commercial or legal interactions for analyzing transactions to generate rules for modifying attributes of transactions for transaction routes and submitting the transactions for processing accordingly. If a claim limitation, under its broadest reasonable interpretation, covers commercial or legal interactions, then it falls within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas. Accordingly, the claims recite an abstract idea.
Step 2A – Prong Two (Does the claim recite additional elements that integrate the judicial exception into a practical application?) - This judicial exception is not integrated into a practical application. In particular, the claims only recite the additional elements of a processer, memory, a transaction platform, a second and third computing device, and machine learning model, with the machine learning model being optionally (by use of or)claimed in claim 9, and is recited at highly generic level such that it amounts to a generic computer component. The additional elements are recited at a high level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components and limits the idea to computing environment. Mere instructions to apply the judicial exception using generic computer components and limiting the judicial exception to a particular environment are not indicative of a practical application (see MPEP 20106.05(f) and MPEP 20106.05(h)). Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed towards an abstract idea.
Step 2B (Does the claim recite additional elements that amount to significantly more than the judicial exception?) - The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, as discussed above, with respect to integration of the abstract idea into a practical application, the additional elements of using a processer, memory, a transaction platform, a second and third computing device, and machine learning model to perform the steps recited above under Step 2A Prong One of the analysis amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The additional elements have been considered separately, and as an ordered combination, and do not add significantly more (also known as an “inventive concept”) to the judicial exception. Further, MPEP 2106.05(d)(ii) provides that Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information);, receiving and transmitting data over a network (see buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) ("The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims.") are well-understood routine and conventional, similar to the instant application claims which recites accessing and analyzing transaction data to generate rules (i.e. performing repetitive calculations), and processing the transaction accordingly. Thus, the claims are not patent eligible.
The dependent claims have been given the full analysis including analyzing the additional limitations both individually and in combination as a whole. For instance, claims 3-6, 9 and 17-24 are all steps that fall within the “Certain Methods of Organizing Human Activities” groupings of abstract ideas, further defining the abstract idea and technical environment in which the idea is being limited to. As explained above with respect to the use of machine learning in claim 9, as a matter of claim interpretation, the machine learning is optionally claimed and not require, and even if positively recited, would not amount to significantly for than the abstract the idea as the machine learning model is recited at a highly generic level such that it could be considered a generic computer component performing repetitive calculations and generally linking the idea to the computer environment, similar to ineligible claim 2 of Example 47 in the July 2024 Subject Matter Eligibility Examples. The Dependent claims when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 for the same reasoning as above and the additional recited limitations fail to establish that the claims are not directed to an abstract idea. The additional limitations of the dependent claims when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 3-6, 9, 15, and 17-24 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Koren, et al. (US Patent Application Publication 20220327504), “Koren”.
As per claim 1, Koren discloses:
A system comprising: [0009]
at least one processor; and [0009]
memory storing instructions that, when executed by the at least one processor, causes the system to perform a set of operations, the set of operations comprising: [0105]
accessing, by a transaction platform, transaction completion information associated with a set of transactions of a transaction platform, wherein each transaction of the set of transactions was transmitted using a specific transaction route of a set of transaction routes; [0090], [0138] Returning to FIG. 19, a variety of data sources can be used by the different engines. For example, at 1950 are shown a plurality of data sources that can be used to train various models or derived various rules for processing the transaction and determining an optimal route. For example, a user history database 1952 can store user history information for specific users. In another example, the user history database 1952 can store transaction information and associate that transaction information with user personas… In further embodiments, the machine models can be trained on any one more of the following factors: historical statistics (e.g., authorization rate on the issuer level and acquirer level on specific same risk level/segment); history of the specific user (e.g., related to acquirer used, payment method used and to successful completion of 3DS); purchase intent (in some embodiments the system is configured to analyze each transaction for a user (e.g., single user, group of users, similar users, etc.) as at least part of determining a payment intent, which enables the system to recognize a new transaction attempt (e.g., when there was a failed attempt for the same intent), and treat the new transaction accordingly (e.g., re-route, new payment method, etc.) to avoid another failure); risk—for example, the system can be configured to avoid entering card scheme fraud programs if there is a reduced likelihood of success; merchant policies—such as minimum volume commitments; fees—minimizing the transaction fee during execution; issuer availability (e.g., the level of support of 3DS and the current up-time of the vendor); and network effect from other merchants, among a number of other options.
identifying, by the transaction platform and based on the transaction completion information, a first categorized subset of transactions from the set of transactions and a second categorized subset of transactions from the set of transactions, wherein the first subset of transactions comprises successful transactions for the specific transaction route and the second subset of transactions comprises unsuccessful transactions for the specific transaction route; [0042], [0045] [0093], [0115-0120], [0150] In various embodiments, the system 110 can include behavior based models which incorporate persona characteristics associated with how a known valid user behaves. Further models can be trained on how known invalid or fraudulent users behave, and still others can be trained on data that incorporates known valid and known fraudulent users and associated information. In one example, the system can include classifier networks that analyze a given transaction and classify behavior characteristics as matching or not matching valid user behavior, and/or that output a likelihood a transaction is valid… In various embodiments, the system is configured to permit any one or more or any combination of the following optimizations, and implementation any one or more or any combination of the following analyses:… For all type of 3DS, the system can be configured to define a threshold % of overall decrease to successful execution (e.g., conversion (or none)), in order to implement execution in improved security protocols for an analyzed execution/communication path (e.g., successful execution of 3DS protocols of any version, among other options)… In some embodiments, the system can implement outlier models and/or classification models to identify operations having higher risk and/or operations having low risk and characteristics of valid transactions… Transaction information can also be organized based on logical groupings to facilitate modeling… The models and processing rules can be derived from historic transaction information, successful, and/or failed executions… For example, the system can use the models to determine if a specific PSP will block a higher risk transaction whether not or an issuer receiving transaction from an acquirer from specific country is likely to block a transaction. The system can identify different routings, and selections of systems, where another route makes the transaction likely to succeed.
generating, by the transaction platform and for the specific transaction route, a transaction rule that comprises adapting, based on a difference between the first categorized subset of transactions and the second categorized subset of transactions, a transaction to improve a likelihood of success via the specific transaction route, the adapting comprising at least one of: [0093], [0115-0120], [0131], [0150] The system can analyze and/or model payment modalities using intent connections to identify what did not work for unsuccessful executions and what did work for the successful one. Further, each payment gateway, processor, acquirer, network (e.g., verification services) can be analyzed to determine what contexts cause failure and what changes permitted success. The system can build processing rules based on success and failure criteria for each participant/system in a route, as well as machine learning models that can output a likelihood of success based on input transactions properties… In some embodiments, the system can implement outlier models and/or classification models to identify operations having higher risk and/or operations having low risk and characteristics of valid transactions… The models and processing rules can be derived from historic transaction information, successful, and/or failed executions. Transaction information can also be organized based on logical groupings to facilitate modeling… The models and processing rules can be derived from historic transaction information, successful, and/or failed executions.
adding an attribute to the processed transaction;1
removing an attribute from the processed transaction; and2
modifying an attribute of the processed transaction; and [0008], [0059] In determining likelihood of success, the system can be configured to execute various machine learning models and/or processing rules. The models and processing rules can be derived from historic transaction information, successful, and/or failed executions. Further, the model and processing rules can be derived from intent based analysis of historic transactions. For example, intent linking of transactions enables the system to evaluate multiple attempts at a purchase based on intent and evaluate how changes to transaction information enable a successful result. Similarly, the system can train machine learning models for each decision point in a processing route to determine a selection of systems, a selection of information to pass to the various systems, and/or a selection of security protocols to engage or avoid during processing to achieve the highest likelihood of success. In various embodiments, the decision points within a processing route include the respective participant systems, opportunities to trigger or avoid additional security measures, and also include opportunities to filter, enhance, or format transaction information passed to the various participant systems, among other options… For example, the system is configured to identify when a credit card submission for payment includes an address that does not match an address on file. By identifying the discrepancy, the system can modify the information provided downstream to remove the inconsistency and improve the likelihood of successful processing.
in response to determining approval to utilize the transaction rule for transaction processing, generating, by the transaction platform, an association between the transaction rule and the specific transaction route; [0059], [0093], [0115-0120], [0131-0132], [0150] In determining likelihood of success, the system can be configured to execute various machine learning models and/or processing rules. The models and processing rules can be derived from historic transaction information, successful, and/or failed executions. Further, the model and processing rules can be derived from intent based analysis of historic transactions. For example, intent linking of transactions enables the system to evaluate multiple attempts at a purchase based on intent and evaluate how changes to transaction information enable a successful result. Similarly, the system can train machine learning models for each decision point in a processing route to determine a selection of systems, a selection of information to pass to the various systems, and/or a selection of security protocols to engage or avoid during processing to achieve the highest likelihood of success… The system can analyze and/or model payment modalities using intent connections to identify what did not work for unsuccessful executions and what did work for the successful one. Further, each payment gateway, processor, acquirer, network (e.g., verification services) can be analyzed to determine what contexts cause failure and what changes permitted success. The system can build processing rules based on success and failure criteria for each participant/system in a route, as well as machine learning models that can output a likelihood of success based on input transactions properties… In some embodiments, the system can implement outlier models and/or classification models to identify operations having higher risk and/or operations having low risk and characteristics of valid transactions
receiving , by the transaction platform from a first computing device, an indication of a transaction; [0132-0133] According to some embodiments, the system assigns the different transactions or the same attempts in the same transaction identify, a unique intent ID that is later used by the system for reports and understanding the success per intent. By determining successful operations based on intent, the system is able to optimize subsequent routing, processing, and communication based on the entire path (including re-execution) and not just the success per transaction that conventional systems are limited to… For example, if a transaction content is presented, the system identifies a matched intent, similar circumstances to a failed execution, and re-routes or dynamically selects a new processing pathway
determining to process the transaction via the specific transaction route from the set of transaction routes; and see fig. 18, [0041], [0161], [0147] Shown in FIG. 18 are options for processing re-execution. For example, in bank decline transactions the system can analyze a number of options for selecting an optimal routing of a re-execution or resubmission of a transaction. For example, the system can determine that triggering enhanced security post authorization will result in a successful operation. Further, the system can identify when providing additional data (e.g., fraud analysis determination, transaction history, purchaser characteristic analysis, etc.) improves the likelihood success for the operation and act accordingly. In various embodiments, the system leverages the determination of an optimal routing to suggest corrections to purchaser the user interface. For example, in response to a failure the system can initiate decline recovery operations (e.g., 1802). FIG. 18 illustrates a number of example considerations when attempting the execution of a transaction, specifically bank declined transactions. Shown at 1803 is an example interface displayed to a purchaser upon entering transaction information that results in a failure. The system can identify options that are predicted to result in an approved transaction (e.g., 1804 or 1806)… The system can then determine an optimal routing of transaction to achieve the highest probability of successfully completing a valid transaction, and for example, while balancing the execution load imposed by the selected route. In further example, the system is configured to balance availability of enhanced security measure/systems. According to one example, the system can determine in real time, availability of 3DS systems or ACH systems for a processing route. While an initial determination may have selected a route that employed ACH to improve the likelihood of success, the system can determine that ACH system unavailability will actually result in failure, and re-route to a different processor, or substitute another security approach (e.g., 3DS protocol with exemption), among other options… In various embodiments, the system leverages machine learning models of prior transactions to determine what state, security, intermediary systems, and outcome will occur for each and/or any of the potential routes from 1502 to 1512.
in response to determining to process the transaction via the specific transaction route: processing, by the transaction platform, the indicated transaction according to the generated transaction rule based on the association between the transaction rule and the specific transaction route, thereby adapting an attribute of the indicated transaction to improve a likelihood of success for processing the transaction rule via the specific transaction route; and [0047], [0059], [0131-0133] According to some embodiments, the system assigns the different transactions or the same attempts in the same transaction identify, a unique intent ID that is later used by the system for reports and understanding the success per intent. By determining successful operations based on intent, the system is able to optimize subsequent routing, processing, and communication based on the entire path (including re-execution) and not just the success per transaction that conventional systems are limited to… For example, if a transaction content is presented, the system identifies a matched intent, similar circumstances to a failed execution, and re-routes or dynamically selects a new processing pathway. In one example, the system triggers 3DS challenge/response enhanced security, where the failure was based on not meeting security requirements, in another, the system avoids 3DS challenge/response protocols, as the initiator abandoned such validation, in still others, the system can request the initiator select a new payment vehicle to avoid issues/pitfalls presented in prior execution or predicted issues/pitfalls… For example, the system is configured to identify when a credit card submission for payment includes an address that does not match an address on file. By identifying the discrepancy, the system can modify the information provided downstream to remove the inconsistency and improve the likelihood of successful processing… According to some embodiments, the system is configured to develop operational models based on “Intent”—a unique linking protocol that can connect between attempts of purchasing by the same individual across multiple devices, across different accounts, across different payment methods, and across different network connections. In some examples, the system is configured to build an intent based model where the system detects that the individual was not able to complete a purchase, and what subsequent actions or change in circumstance permit the transaction to be executed. According to various embodiments, the trained models are used in evaluating the efficiency of various communication pathways from an initiator, through intermediary systems, to a payment issuer, enabling the selection of the most efficient communication path and successful execution.
submitting, by the transaction platform, to a second computing device associated with the transaction route, the processed transaction for processing via the specific transaction route. see fig. 18, [0041], [0161] Shown in FIG. 18 are options for processing re-execution. For example, in bank decline transactions the system can analyze a number of options for selecting an optimal routing of a re-execution or resubmission of a transaction. For example, the system can determine that triggering enhanced security post authorization will result in a successful operation. Further, the system can identify when providing additional data (e.g., fraud analysis determination, transaction history, purchaser characteristic analysis, etc.) improves the likelihood success for the operation and act accordingly. In various embodiments, the system leverages the determination of an optimal routing to suggest corrections to purchaser the user interface. For example, in response to a failure the system can initiate decline recovery operations (e.g., 1802). FIG. 18 illustrates a number of example considerations when attempting the execution of a transaction, specifically bank declined transactions. Shown at 1803 is an example interface displayed to a purchaser upon entering transaction information that results in a failure. The system can identify options that are predicted to result in an approved transaction (e.g., 1804 or 1806)… The system can then determine an optimal routing of transaction to achieve the highest probability of successfully completing a valid transaction, and for example, while balancing the execution load imposed by the selected route. In further example, the system is configured to balance availability of enhanced security measure/systems. According to one example, the system can determine in real time, availability of 3DS systems or ACH systems for a processing route. While an initial determination may have selected a route that employed ACH to improve the likelihood of success, the system can determine that ACH system unavailability will actually result in failure, and re-route to a different processor, or substitute another security approach (e.g., 3DS protocol with exemption), among other options.
As per claim 3, Koren discloses:
wherein: the generated transaction rule comprises an association with the specific transaction route based on determining a first success rate of the subset of first transactions is higher than a second success rate of the subset second transactions; and [0050], [0059], [0093], [0131] Analysis at 210 can also include historic analysis and/or processing rules that impact the determination of an optimized route (including, for example, likelihood of success, processing burden, etc.) or that are implemented to weight selection of specific routes, which can be used to permit new dynamic routing selections. If a candidate route is not optimal for returning a successful transaction 212NO, process 200 continues at 214 with dynamic routing or re-routing of the transactions to deliver the highest likelihood of success, improved efficiency, etc., and processing can be completed at 216. If a candidate route for the transaction is optimal 216YES, the processing for the transaction is completed at 216. According to various embodiments, the steps of process 200 can be executed in different order and/or various steps omitted or consolidated for execution… The system can analyze and/or model payment modalities using intent connections to identify what did not work for unsuccessful executions and what did work for the successful one. Further, each payment gateway, processor, acquirer, network (e.g., verification services) can be analyzed to determine what contexts cause failure and what changes permitted success. The system can build processing rules based on success and failure criteria for each participant/system in a route, as well as machine learning models that can output a likelihood of success based on input transactions properties. Transaction information can also be organized based on logical groupings to facilitate modeling… The models and processing rules can be derived from historic transaction information, successful, and/or failed executions.
processing the transaction according to the generated transaction rule comprises processing the transaction using the specific transaction route based on the association. [0132-0133] According to some embodiments, the system assigns the different transactions or the same attempts in the same transaction identify, a unique intent ID that is later used by the system for reports and understanding the success per intent. By determining successful operations based on intent, the system is able to optimize subsequent routing, processing, and communication based on the entire path (including re-execution) and not just the success per transaction that conventional systems are limited to. The system is able to optimize across and report on the overall customer journey and experience (e.g., succeed immediately vs attempted multiple time until success, or multiple time failure, among other options)… For example, if a transaction content is presented, the system identifies a matched intent, similar circumstances to a failed execution, and re-routes or dynamically selects a new processing pathway. In one example, the system triggers 3DS challenge/response enhanced security, where the failure was based on not meeting security requirements, in another, the system avoids 3DS challenge/response protocols, as the initiator abandoned such validation, in still others, the system can request the initiator select a new payment vehicle to avoid issues/pitfalls presented in prior execution or predicted issues/pitfalls.
As per claim 4, Koren discloses:
wherein: the first categorized subset of transactions comprises a subset of transactions associated with a first attribute; and [0100-0101], [0115-0120] , see also [0154] In various embodiments, the system is configured to permit any one or more or any combination of the following optimizations, and implementation any one or more or any combination of the following analyses: [0116] For all type of 3DS, the system can be configured to define a threshold % of overall decrease to successful execution (e.g., conversion (or none)), in order to implement execution in improved security protocols for an analyzed execution/communication path (e.g., successful execution of 3DS protocols of any version, among other options); [0117] The system can be configured to evaluate across multiple participant systems (e.g., merchants, intermediaries, services, etc.) in the same industry but also in different industries in order to make sure that the optimization of the communication path/system selection includes modeling within and without various industries. In some embodiments, the system can implement outlier models and/or classification models to identify operations having higher risk and/or operations having low risk and characteristics of valid transactions. In further example, the system can identify greater efficiency in triggering enhanced security in higher risk setting, rather than in lower risk settings yielding different execution path even for similar operations… Transaction information can also be organized based on logical groupings to facilitate modeling… The models can be trained so that the prediction on security implementation can also be based on the specific context of a transaction (e.g., valid or fraudulent, low risk, high risk, low value, high value, origination, timing, history, user characteristic, etc.).
the second categorized subset of transactions comprises a subset of transactions associated with a second attribute. [0100-0101], [0115-0120], see also [0154] In various embodiments, the system is configured to permit any one or more or any combination of the following optimizations, and implementation any one or more or any combination of the following analyses: [0116] For all type of 3DS, the system can be configured to define a threshold % of overall decrease to successful execution (e.g., conversion (or none)), in order to implement execution in improved security protocols for an analyzed execution/communication path (e.g., successful execution of 3DS protocols of any version, among other options); [0117] The system can be configured to evaluate across multiple participant systems (e.g., merchants, intermediaries, services, etc.) in the same industry but also in different industries in order to make sure that the optimization of the communication path/system selection includes modeling within and without various industries. In some embodiments, the system can implement outlier models and/or classification models to identify operations having higher risk and/or operations having low risk and characteristics of valid transactions. In further example, the system can identify greater efficiency in triggering enhanced security in higher risk setting, rather than in lower risk settings yielding different execution path even for similar operations… Transaction information can also be organized based on logical groupings to facilitate modeling… The models can be trained so that the prediction on security implementation can also be based on the specific context of a transaction (e.g., valid or fraudulent, low risk, high risk, low value, high value, origination, timing, history, user characteristic, etc.).
As per claim 5, Koren discloses:
wherein: the generated transaction rule comprises an association with the first attribute based on determining a first success rate of transactions having the first attribute is higher than a second success rate of transactions having the second attribute; and [0012], [0130-0133], According to various embodiments, system method includes any one or more or any combination of the following so the method further comprises: analyzing security options for the plurality of processing routes to determine the at least one route having a highest probability of success; determining the at least one route having the highest probability of success based on evaluation of enhanced security protocols for each processor, payment method, intermediary, and acquirer system of the plurality of routes; determining enhanced security protocols negatively impact successful operation; selecting an alternative routing to eliminate enhanced security protocols… The system can analyze and/or model payment modalities using intent connections to identify what did not work for unsuccessful executions and what did work for the successful one. Further, each payment gateway, processor, acquirer, network (e.g., verification services) can be analyzed to determine what contexts cause failure and what changes permitted success. The system can build processing rules based on success and failure criteria for each participant/system in a route, as well as machine learning models that can output a likelihood of success based on input transactions properties.
the transaction is processed according to the generated transaction rule based on determining the transaction has the first transaction attribute. [0012], [0130-0133], The system can analyze and/or model payment modalities using intent connections to identify what did not work for unsuccessful executions and what did work for the successful one. Further, each payment gateway, processor, acquirer, network (e.g., verification services) can be analyzed to determine what contexts cause failure and what changes permitted success. The system can build processing rules based on success and failure criteria for each participant/system in a route, as well as machine learning models that can output a likelihood of success based on input transactions properties… According to various embodiments, the system is configured to identify a matched intent, which triggers elimination of the prior routing to avoid repeating the same decision (an execution failure). For example, if a transaction content is presented, the system identifies a matched intent, similar circumstances to a failed execution, and re-routes or dynamically selects a new processing pathway. In one example, the system triggers 3DS challenge/response enhanced security, where the failure was based on not meeting security requirements, in another, the system avoids 3DS challenge/response protocols, as the initiator abandoned such validation, in still others, the system can request the initiator select a new payment vehicle to avoid issues/pitfalls presented in prior execution or predicted issues/pitfalls.
As per claim 6, Koren discloses:
wherein the subset of transactions associated with the first attribute and the subset of transaction associated with the second attribute are both associated with the same transaction route. [0078], [0093], [0110-0115] The system can also include a routing path engine 1910 configured to determine a probability that payment ecosystem accepts the transaction on a specific route, which can be based on historical success rates. According to one example, the engine is configured to evaluate usages of authentication protocols such as 3DS. In further example, the engine is configured to evaluate routing options without authentication. In various embodiments, the routing path engine is a ML engine trained on transactions data with each of and/or combinations of cardholder/issuer/global historical success rates per route. Once trained, the model is configured to output for a given transaction input, a score per each possible route, and the system can use the score to select the route with the highest possible score. Further the score can be used in conjunction with the outputs of the other engines and/or the routes analyzed by the engine can be filtered based on outputs of the other engines… In some embodiments, the system can implement outlier models and/or classification models to identify operations having higher risk and/or operations having low risk and characteristics of valid transactions. In further example, the system can identify greater efficiency in triggering enhanced security in higher risk setting, rather than in lower risk settings yielding different execution path even for similar operations… Transaction information can also be organized based on logical groupings to facilitate modeling.
As per claim 9, Koren discloses:
wherein determining approval comprises one or more of: [0059], [0070]
receiving user approval of the generated transaction rule; or approving the generated transaction rule using a machine learning model, wherein the machine learning model was trained according to a set of historical transaction rules. [0059], [0070], see also [0134] In determining likelihood of success, the system can be configured to execute various machine learning models and/or processing rules. The models and processing rules can be derived from historic transaction information, successful, and/or failed executions. Further, the model and processing rules can be derived from intent based analysis of historic transactions… According to various embodiments, the system models each system/participant on a route as processing nodes (e.g., merchant, PSP, processor, acquire network, issuer or bank) that each have options tailored to their preferences and/or rules. The models can be configured to output selections of transaction information for each system/processor to account for the tailored rules that may apply, customizations in processing, and the system can change or manipulate how the rules are going to result in a decision at each one of those points.
As per claim 15, Koren discloses:
A method for maintaining transaction rules of a transaction platform, comprising: [0037]
accessing , by the transaction platform, transaction completion information associated with a set of transactions of the transaction platform, wherein each transaction of the set of transactions was transmitted using a specific transaction route of a set of transaction routes; [0090], [0138] Returning to FIG. 19, a variety of data sources can be used by the different engines. For example, at 1950 are shown a plurality of data sources that can be used to train various models or derived various rules for processing the transaction and determining an optimal route. For example, a user history database 1952 can store user history information for specific users. In another example, the user history database 1952 can store transaction information and associate that transaction information with user personas… In further embodiments, the machine models can be trained on any one more of the following factors: historical statistics (e.g., authorization rate on the issuer level and acquirer level on specific same risk level/segment); history of the specific user (e.g., related to acquirer used, payment method used and to successful completion of 3DS); purchase intent (in some embodiments the system is configured to analyze each transaction for a user (e.g., single user, group of users, similar users, etc.) as at least part of determining a payment intent, which enables the system to recognize a new transaction attempt (e.g., when there was a failed attempt for the same intent), and treat the new transaction accordingly (e.g., re-route, new payment method, etc.) to avoid another failure); risk—for example, the system can be configured to avoid entering card scheme fraud programs if there is a reduced likelihood of success; merchant policies—such as minimum volume commitments; fees—minimizing the transaction fee during execution; issuer availability (e.g., the level of support of 3DS and the current up-time of the vendor); and network effect from other merchants, among a number of other options.
identifying, by the transaction platform and based on the transaction completion information, a first categorized subset of transactions from the set of transactions and a second categorized subset of transactions from the set of transactions, wherein the first subset of transactions comprises successful transactions for the specific transaction route and the second subset of transactions comprises unsuccessful transactions for the specific transaction route; [0042], [0045] [0093], [0115-0120], [0150] In various embodiments, the system 110 can include behavior based models which incorporate persona characteristics associated with how a known valid user behaves. Further models can be trained on how known invalid or fraudulent users behave, and still others can be trained on data that incorporates known valid and known fraudulent users and associated information. In one example, the system can include classifier networks that analyze a given transaction and classify behavior characteristics as matching or not matching valid user behavior, and/or that output a likelihood a transaction is valid… In various embodiments, the system is configured to permit any one or more or any combination of the following optimizations, and implementation any one or more or any combination of the following analyses:… For all type of 3DS, the system can be configured to define a threshold % of overall decrease to successful execution (e.g., conversion (or none)), in order to implement execution in improved security protocols for an analyzed execution/communication path (e.g., successful execution of 3DS protocols of any version, among other options)… In some embodiments, the system can implement outlier models and/or classification models to identify operations having higher risk and/or operations having low risk and characteristics of valid transactions… Transaction information can also be organized based on logical groupings to facilitate modeling… The models and processing rules can be derived from historic transaction information, successful, and/or failed executions… For example, the system can use the models to determine if a specific PSP will block a higher risk transaction whether not or an issuer receiving transaction from an acquirer from specific country is likely to block a transaction. The system can identify different routings, and selections of systems, where another route makes the transaction likely to succeed.
generating, by the transaction platform and for the specific transaction route, a transaction rule for a set of transaction rules that comprises adapting, based on a difference between the first categorized subset of transactions and the second categorized subset of transactions, a transaction to improve a likelihood of success via the specific transaction route, the adapting comprising least one of: [0093], [0115-0120], [0131], [0150] The system can analyze and/or model payment modalities using intent connections to identify what did not work for unsuccessful executions and what did work for the successful one. Further, each payment gateway, processor, acquirer, network (e.g., verification services) can be analyzed to determine what contexts cause failure and what changes permitted success. The system can build processing rules based on success and failure criteria for each participant/system in a route, as well as machine learning models that can output a likelihood of success based on input transactions properties… In some embodiments, the system can implement outlier models and/or classification models to identify operations having higher risk and/or operations having low risk and characteristics of valid transactions… The models and processing rules can be derived from historic transaction information, successful, and/or failed executions. Transaction information can also be organized based on logical groupings to facilitate modeling… The models and processing rules can be derived from historic transaction information, successful, and/or failed executions.
adding an attribute to the processed transaction; 3
removing an attribute from the processed transaction; and4
modifying an attribute of the processed transaction; [0008], [0059] In determining likelihood of success, the system can be configured to execute various machine learning models and/or processing rules. The models and processing rules can be derived from historic transaction information, successful, and/or failed executions. Further, the model and processing rules can be derived from intent based analysis of historic transactions. For example, intent linking of transactions enables the system to evaluate multiple attempts at a purchase based on intent and evaluate how changes to transaction information enable a successful result. Similarly, the system can train machine learning models for each decision point in a processing route to determine a selection of systems, a selection of information to pass to the various systems, and/or a selection of security protocols to engage or avoid during processing to achieve the highest likelihood of success. In various embodiments, the decision points within a processing route include the respective participant systems, opportunities to trigger or avoid additional security measures, and also include opportunities to filter, enhance, or format transaction information passed to the various participant systems, among other options… For example, the system is configured to identify when a credit card submission for payment includes an address that does not match an address on file. By identifying the discrepancy, the system can modify the information provided downstream to remove the inconsistency and improve the likelihood of successful processing.
generating, by the transaction platform, an association between the transaction rule and the specific transaction route; [0059], [0093], [0115-0120], [0131], [0150] In determining likelihood of success, the system can be configured to execute various machine learning models and/or processing rules. The models and processing rules can be derived from historic transaction information, successful, and/or failed executions. Further, the model and processing rules can be derived from intent based analysis of historic transactions. For example, intent linking of transactions enables the system to evaluate multiple attempts at a purchase based on intent and evaluate how changes to transaction information enable a successful result. Similarly, the system can train machine learning models for each decision point in a processing route to determine a selection of systems, a selection of information to pass to the various systems, and/or a selection of security protocols to engage or avoid during processing to achieve the highest likelihood of success… The system can analyze and/or model payment modalities using intent connections to identify what did not work for unsuccessful executions and what did work for the successful one. Further, each payment gateway, processor, acquirer, network (e.g., verification services) can be analyzed to determine what contexts cause failure and what changes permitted success. The system can build processing rules based on success and failure criteria for each participant/system in a route, as well as machine learning models that can output a likelihood of success based on input transactions properties… In some embodiments, the system can implement outlier models and/or classification models to identify operations having higher risk and/or operations having low risk and characteristics of valid transactions
determining to process a transaction via the specific transaction route from the set of transaction routes; and [0059], [0093], [0115-0120], [0131-0132], [0150] In determining likelihood of success, the system can be configured to execute various machine learning models and/or processing rules. The models and processing rules can be derived from historic transaction information, successful, and/or failed executions. Further, the model and processing rules can be derived from intent based analysis of historic transactions. For example, intent linking of transactions enables the system to evaluate multiple attempts at a purchase based on intent and evaluate how changes to transaction information enable a successful result. Similarly, the system can train machine learning models for each decision point in a processing route to determine a selection of systems, a selection of information to pass to the various systems, and/or a selection of security protocols to engage or avoid during processing to achieve the highest likelihood of success… The system can analyze and/or model payment modalities using intent connections to identify what did not work for unsuccessful executions and what did work for the successful one. Further, each payment gateway, processor, acquirer, network (e.g., verification services) can be analyzed to determine what contexts cause failure and what changes permitted success. The system can build processing rules based on success and failure criteria for each participant/system in a route, as well as machine learning models that can output a likelihood of success based on input transactions properties… In some embodiments, the system can implement outlier models and/or classification models to identify operations having higher risk and/or operations having low risk and characteristics of valid transactions
in response to determining to process the transaction via the specific transaction route: processing, by the transaction platform, the identified transaction according to the generated transaction rule based on the association between the transaction rule and the specific transaction route, thereby adapting an attribute of the identified transaction to improve a likelihood of success for processing the transaction rule via the specific transaction route; 0047], [0059], [0131-0133] According to some embodiments, the system assigns the different transactions or the same attempts in the same transaction identify, a unique intent ID that is later used by the system for reports and understanding the success per intent. By determining successful operations based on intent, the system is able to optimize subsequent routing, processing, and communication based on the entire path (including re-execution) and not just the success per transaction that conventional systems are limited to… For example, if a transaction content is presented, the system identifies a matched intent, similar circumstances to a failed execution, and re-routes or dynamically selects a new processing pathway. In one example, the system triggers 3DS challenge/response enhanced security, where the failure was based on not meeting security requirements, in another, the system avoids 3DS challenge/response protocols, as the initiator abandoned such validation, in still others, the system can request the initiator select a new payment vehicle to avoid issues/pitfalls presented in prior execution or predicted issues/pitfalls… For example, the system is configured to identify when a credit card submission for payment includes an address that does not match an address on file. By identifying the discrepancy, the system can modify the information provided downstream to remove the inconsistency and improve the likelihood of successful processing… According to some embodiments, the system is configured to develop operational models based on “Intent”—a unique linking protocol that can connect between attempts of purchasing by the same individual across multiple devices, across different accounts, across different payment methods, and across different network connections. In some examples, the system is configured to build an intent based model where the system detects that the individual was not able to complete a purchase, and what subsequent actions or change in circumstance permit the transaction to be executed. According to various embodiments, the trained models are used in evaluating the efficiency of various communication pathways from an initiator, through intermediary systems, to a payment issuer, enabling the selection of the most efficient communication path and successful execution.
submitting, , by the transaction platform to a first computing device of the transaction route, the processed transaction for processing via the transaction route; . see fig. 18, [0041], [0161] Shown in FIG. 18 are options for processing re-execution. For example, in bank decline transactions the system can analyze a number of options for selecting an optimal routing of a re-execution or resubmission of a transaction. For example, the system can determine that triggering enhanced security post authorization will result in a successful operation. Further, the system can identify when providing additional data (e.g., fraud analysis determination, transaction history, purchaser characteristic analysis, etc.) improves the likelihood success for the operation and act accordingly. In various embodiments, the system leverages the determination of an optimal routing to suggest corrections to purchaser the user interface. For example, in response to a failure the system can initiate decline recovery operations (e.g., 1802). FIG. 18 illustrates a number of example considerations when attempting the execution of a transaction, specifically bank declined transactions. Shown at 1803 is an example interface displayed to a purchaser upon entering transaction information that results in a failure. The system can identify options that are predicted to result in an approved transaction (e.g., 1804 or 1806)… The system can then determine an optimal routing of transaction to achieve the highest probability of successfully completing a valid transaction, and for example, while balancing the execution load imposed by the selected route. In further example, the system is configured to balance availability of enhanced security measure/systems. According to one example, the system can determine in real time, availability of 3DS systems or ACH systems for a processing route. While an initial determination may have selected a route that employed ACH to improve the likelihood of success, the system can determine that ACH system unavailability will actually result in failure, and re-route to a different processor, or substitute another security approach (e.g., 3DS protocol with exemption), among other options.
As per claim 21, Koren discloses:
determining approval for utilizing the transaction rule to process transactions of the transaction platform. [0059], [0070], see also [0134] In determining likelihood of success, the system can be configured to execute various machine learning models and/or processing rules. The models and processing rules can be derived from historic transaction information, successful, and/or failed executions. Further, the model and processing rules can be derived from intent based analysis of historic transactions… According to various embodiments, the system models each system/participant on a route as processing nodes (e.g., merchant, PSP, processor, acquire network, issuer or bank) that each have options tailored to their preferences and/or rules. The models can be configured to output selections of transaction information for each system/processor to account for the tailored rules that may apply, customizations in processing, and the system can change or manipulate how the rules are going to result in a decision at each one of those points.
As per claim 22, Koren discloses:
determining, based on the set of transaction rules and after submitting the transaction for processing via the specific transaction route, a fallback transaction route for the transaction; [0067], [0160-0163] In further embodiments, the system can determine that providing additional authentication information (e.g., enhancing security) will result in a successful transaction (e.g., initially or as a re-submission)… According to another aspect, optimal routing can include analysis and operations to ensure failed transactions are re-executed successfully. According to one embodiment, the system can implement machine learning models trained on failed transactions that are re-executed successfully… In other examples, the system can predict on the use of the new payment modality, the use of different, and/or security protocols the use of a new processor, among other options. The various machine learning models discussed above can also be trained on re-execution data specifically to predict on an optimal route after a failed transaction. In addition, process and rules derived from re-execution data can also be employed to select an optimal route, in addition to and/or instead of machine learning models, among other options.
processing the transaction according to a transaction rule associated with the fallback transaction route, thereby generating a second processed transaction; and [0160-163] According to another aspect, optimal routing can include analysis and operations to ensure failed transactions are re-executed successfully. According to one embodiment, the system can implement machine learning models trained on failed transactions that are re-executed successfully... In other examples, the system can predict on the use of the new payment modality, the use of different, and/or security protocols the use of a new processor, among other options. The various machine learning models discussed above can also be trained on re-execution data specifically to predict on an optimal route after a failed transaction. In addition, process and rules derived from re-execution data can also be employed to select an optimal route, in addition to and/or instead of machine learning models, among other options… Shown in FIG. 18 are options for processing re-execution. For example, in bank decline transactions the system can analyze a number of options for selecting an optimal routing of a re-execution or resubmission of a transaction. For example, the system can determine that triggering enhanced security post authorization will result in a successful operation. Further, the system can identify when providing additional data (e.g., fraud analysis determination, transaction history, purchaser characteristic analysis, etc.) improves the likelihood success for the operation and act accordingly. In various embodiments, the system leverages the determination of an optimal routing to suggest corrections to purchaser the user interface. For example, in response to a failure the system can initiate decline recovery operations (e.g., 1802).
submitting, to a third computing device of the fallback transaction route, the second processed transaction for processing via the fallback transaction route. [0160-0163] According to another aspect, optimal routing can include analysis and operations to ensure failed transactions are re-executed successfully. According to one embodiment, the system can implement machine learning models trained on failed transactions that are re-executed successfully... In other examples, the system can predict on the use of the new payment modality, the use of different, and/or security protocols the use of a new processor, among other options. The various machine learning models discussed above can also be trained on re-execution data specifically to predict on an optimal route after a failed transaction. In addition, process and rules derived from re-execution data can also be employed to select an optimal route, in addition to and/or instead of machine learning models, among other options… Shown in FIG. 18 are options for processing re-execution. For example, in bank decline transactions the system can analyze a number of options for selecting an optimal routing of a re-execution or resubmission of a transaction. For example, the system can determine that triggering enhanced security post authorization will result in a successful operation. Further, the system can identify when providing additional data (e.g., fraud analysis determination, transaction history, purchaser characteristic analysis, etc.) improves the likelihood success for the operation and act accordingly. In various embodiments, the system leverages the determination of an optimal routing to suggest corrections to purchaser the user interface. For example, in response to a failure the system can initiate decline recovery operations (e.g., 1802).
As per claim 23, Koren discloses:
determining, based on the set of transaction rules and after submitting the transaction for processing via the specific transaction route, a fallback transaction route for the transaction; [0067], [0160-0163] In further embodiments, the system can determine that providing additional authentication information (e.g., enhancing security) will result in a successful transaction (e.g., initially or as a re-submission)… According to another aspect, optimal routing can include analysis and operations to ensure failed transactions are re-executed successfully. According to one embodiment, the system can implement machine learning models trained on failed transactions that are re-executed successfully… In other examples, the system can predict on the use of the new payment modality, the use of different, and/or security protocols the use of a new processor, among other options. The various machine learning models discussed above can also be trained on re-execution data specifically to predict on an optimal route after a failed transaction. In addition, process and rules derived from re-execution data can also be employed to select an optimal route, in addition to and/or instead of machine learning models, among other options.
processing the transaction according to a transaction rule associated with the fallback transaction route, thereby generating a second processed transaction; and [0160-163] According to another aspect, optimal routing can include analysis and operations to ensure failed transactions are re-executed successfully. According to one embodiment, the system can implement machine learning models trained on failed transactions that are re-executed successfully... In other examples, the system can predict on the use of the new payment modality, the use of different, and/or security protocols the use of a new processor, among other options. The various machine learning models discussed above can also be trained on re-execution data specifically to predict on an optimal route after a failed transaction. In addition, process and rules derived from re-execution data can also be employed to select an optimal route, in addition to and/or instead of machine learning models, among other options… Shown in FIG. 18 are options for processing re-execution. For example, in bank decline transactions the system can analyze a number of options for selecting an optimal routing of a re-execution or resubmission of a transaction. For example, the system can determine that triggering enhanced security post authorization will result in a successful operation. Further, the system can identify when providing additional data (e.g., fraud analysis determination, transaction history, purchaser characteristic analysis, etc.) improves the likelihood success for the operation and act accordingly. In various embodiments, the system leverages the determination of an optimal routing to suggest corrections to purchaser the user interface. For example, in response to a failure the system can initiate decline recovery operations (e.g., 1802).
submitting, to a second computing device of the fallback transaction route, the second processed transaction for processing via the fallback transaction route. [0160-0163] According to another aspect, optimal routing can include analysis and operations to ensure failed transactions are re-executed successfully. According to one embodiment, the system can implement machine learning models trained on failed transactions that are re-executed successfully... In other examples, the system can predict on the use of the new payment modality, the use of different, and/or security protocols the use of a new processor, among other options. The various machine learning models discussed above can also be trained on re-execution data specifically to predict on an optimal route after a failed transaction. In addition, process and rules derived from re-execution data can also be employed to select an optimal route, in addition to and/or instead of machine learning models, among other options… Shown in FIG. 18 are options for processing re-execution. For example, in bank decline transactions the system can analyze a number of options for selecting an optimal routing of a re-execution or resubmission of a transaction. For example, the system can determine that triggering enhanced security post authorization will result in a successful operation. Further, the system can identify when providing additional data (e.g., fraud analysis determination, transaction history, purchaser characteristic analysis, etc.) improves the likelihood success for the operation and act accordingly. In various embodiments, the system leverages the determination of an optimal routing to suggest corrections to purchaser the user interface. For example, in response to a failure the system can initiate decline recovery operations (e.g., 1802).
As per claim 24, Koren discloses:
wherein the transaction is processed via the fallback transaction route in response to at least one of: a timeout associated with the specific transaction route; or a failure of the specific transaction route. [0160-0163] According to another aspect, optimal routing can include analysis and operations to ensure failed transactions are re-executed successfully. According to one embodiment, the system can implement machine learning models trained on failed transactions that are re-executed successfully... In other examples, the system can predict on the use of the new payment modality, the use of different, and/or security protocols the use of a new processor, among other options. The various machine learning models discussed above can also be trained on re-execution data specifically to predict on an optimal route after a failed transaction. In addition, process and rules derived from re-execution data can also be employed to select an optimal route, in addition to and/or instead of machine learning models, among other options… Shown in FIG. 18 are options for processing re-execution. For example, in bank decline transactions the system can analyze a number of options for selecting an optimal routing of a re-execution or resubmission of a transaction. For example, the system can determine that triggering enhanced security post authorization will result in a successful operation. Further, the system can identify when providing additional data (e.g., fraud analysis determination, transaction history, purchaser characteristic analysis, etc.) improves the likelihood success for the operation and act accordingly. In various embodiments, the system leverages the determination of an optimal routing to suggest corrections to purchaser the user interface. For example, in response to a failure the system can initiate decline recovery operations (e.g., 1802).
As per claims 16-20, claim 16-20 recite substantially similar limitations to those found in claims 2-5 respectively. Therefor claim(s) 16-20 are rejected under the same art and rationale as claims 2-5. Furthermore, Koren discloses method [0037].
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY S CUNNINGHAM II whose telephone number is (313)446-6564. The examiner can normally be reached Mon-Fri 8:30am-4pm.
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 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.
GREGORY S. CUNNINGHAM II
Primary Examiner
Art Unit 3694
/GREGORY S CUNNINGHAM II/Primary Examiner, Art Unit 3694
1 This limitation is optional
2 This limitation is optional
3 This limitation is optional
4 This limitation is optional