DETAILED ACTION
Status of Application
This action is a Final Rejection. This action is in response to the amendment and response filed on November 10, 2025.
Claims 1, 2, 4, 6, 11, 16, and 20 have been amended.
Claim 21 has been added.
Claim 15 has been canceled.
Claims 1-14 and 16-21 are pending and rejected.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . 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.
Response to Arguments
Regarding the rejection under 35 U.S.C. 112(b), the rejection was been withdrawn in light of Applicant’s amendments.
Regarding the rejection under 35 U.S.C. 101, Applicant argues that claim 1 provides a practical application because “the claimed features solve the technical problem of metadata that is included in transactions only being semi-human readable, due to heavy word abbreviation necessary due to the fixed-width nature of ACH specs. This information is not helpful when presented in receipts or in activity feeds because users cannot identify what the transactions are for.” Remarks at 11-12. However, the claims are using a general purpose computing device that is programmed to identify transaction data, which is part of the abstract idea.
Applicant further argues that “[w]hen taken as a whole, these features, along with the others in the claim, recite a method for providing user-readable information to a user on a receipt, by utilizing a trained AI model to interpret the computer-readable format of the information.” Remarks at 13. However, when viewed as a whole, the claims are using a computer platform and an AI model to determine transaction information and present it on a user device. The computer platform and AI model are being used as tools to implement the claimed abstract idea.
Applicant further points to paragraph 0019 of the Specification as disclosing a technological improvement. Remarks at 13-14. However, the described improvement is an improvement to the business process and not to the technology.
Applicant further argues that “[a]mended claim 1 recites an ordered combination of additional elements that are not well-understood, routine, or conventional, and that cause the amended claim to amount to an inventive concept under Step 2B.” Remarks at 15. However, the Office action does not allege that the additional elements are well understood, routine, or conventional.
Claim Interpretation
Applicant should be aware that there is claim language that does not serve to differentiate the claims from the prior art and/or provide an additional element that can be a consideration for eligibility1. See MPEP 2103(c).
Nonfunctional Descriptive Material
Nonfunctional descriptive material is generally not given patentable weight. See MPEP 2111.05. Any difference related merely to the meaning and information conveyed through labels (i.e., the type of the item) which does not explicitly alter or impact the steps of the method is nonfunctional descriptive material and does not patentably distinguish the claimed invention from the prior art in terms of patentability.
The following limitations include nonfunctional descriptive material:
Claim 1: “causing, by the payment service computing platform, information indicative of the entity and the type of the transaction to be presented via the payment application executing on a user device of the user, wherein the information is presented (i) in a graphical user interface associated with an activity feed, a statement, or a receipt and (ii) in a user-readable format instead of the computer-readable format”
Claim 3: “provide a computer-readable object as output”
Claims 6 and 16: “causing information indicative of the one or more attributes to be presented via the payment application executing on a user device of the user, wherein the information is presented (i) in a graphical user interface and (ii) in a user-readable format instead of the computer-readable format”
Claim 9: “generating the prompt by including, in the prompt, requests for the trained AI model to: determine the one or more attributes from the portion of the transaction data; and provide a computer-readable object as output”
Claim 12: “at least one of: storing, in a data store, an association between the portion of the transaction data and the one or more attributes; or retraining the trained AI model based at least in part on the association”
Claim 19: “generating the prompt by including in the prompt an example prompt and a correct AI-generated answer to the example prompt”
Note Regarding Claim Amendments
The amendment to claim 1 includes “a payment card transaction” while the amendments to claims 6 and 16 include “a payment transaction.” If Applicant intended for claims 6 and 16 to instead recite “a payment card transaction,” this should be corrected.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-14 and 16-21 are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Does the Claim Fall within a Statutory Category? (see MPEP 2106.03)
Yes, with respect to claims 1-5 and 16-20, which recite a method and, therefore, are directed to the statutory class of process.
Yes, with respect to claims 6-14 and 21, which recite a system and, therefore, are directed to the statutory class of machine or manufacture.
Step 2A, Prong One: Is a Judicial Exception Recited? (see MPEP 2106.04(a))
The following claims identify the limitations that recite the abstract idea in regular text and that recite additional elements in bold:
1. A computer-implemented method comprising:
receiving, by a payment service computing platform, transaction data associated with users of a payment application provided by the payment service computing platform, wherein the transaction data is received in a computer-readable format;
providing, by the payment service computing platform, a prompt to a trained artificial intelligence (AI) model, wherein the prompt includes a portion of the transaction data that represents a transaction associated with a user of the users;
determining, by the payment service computing platform and based on the trained AI model processing the prompt, an entity, other than the user, associated with the transaction and a type of the transaction, wherein the type of transaction is one of an Automated Clearing House (ACH) transaction, a payment card transaction, a peer-to-peer transaction, a wire transfer, or an Automated Teller Machine (ATM) transaction; and
causing, by the payment service computing platform, information indicative of the entity and the type of the transaction to be presented via the payment application executing on a user device of the user, wherein the information is presented (i) in a graphical user interface associated with an activity feed, a statement, or a receipt and (ii) in a user-readable format instead of the computer-readable format.
2. The computer-implemented method of claim 1, wherein:
the transaction data comprises at least one of: ACH transaction data that represents ACH transactions associated with the users; or card transaction data that represents card transactions associated with the users;
the computer-readable format comprises at least one of: a first computer-readable format associated with the ACH transaction data; or a second computer-readable format associated with the card transaction data;
the first computer-readable format is different than the second computer-readable format; and
the trained AI model is configured to process prompts that include the ACH transaction data in the first computer-readable format and prompts that include the card transaction data in the second computer-readable format.
3. The computer-implemented method of claim 1, further comprising generating, by the payment service computing platform, the prompt by including, in the prompt, requests for the trained AI model to:
determine the entity and the type of the transaction from the portion of the transaction data;
explain steps performed and/or reasoning for determining the entity and the type of the transaction from the portion of the transaction data; and
provide a computer-readable object as output.
4. The computer-implemented method of claim 1, further comprising:
receiving, by the payment service computing platform, a validation that the entity determined using the trained AI model is correct and that the type of the transaction determined using the trained AI model is correct; and
determining, by the payment service computing platform and based on the validation, that the entity determined using the trained AI model is correct and that the type of the transaction determined using the trained AI model is correct,
wherein the causing of the information to be presented via the payment application executing on the user device is based on the determining that the entity determined using the trained AI model is correct and that the type of the transaction determined using the trained AI model is correct.
5. The computer-implemented method of claim 1, further comprising:
extracting, by the payment service computing platform and from the transaction data, a string of alphanumeric characters that represents the transaction; and
transforming, by the payment service computing platform, the string of alphanumeric characters into the portion of the transaction data,
wherein the portion of the transaction data is an embedding that comprises a string of numbers.
6. A system comprising:
one or more processors; and
memory storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
receiving transaction data associated with users of a payment application, wherein the transaction data is received in a computer-readable format;
providing a prompt to a trained artificial intelligence (AI) model, wherein the prompt includes a portion of the transaction data that represents a transaction associated with a user of the users;
determining, based at least in part on the trained AI model processing the prompt, one or more attributes of the transaction, wherein the one or more attributes include at least a type of transaction that is one of an Automated Clearing House (ACH) transaction, a payment card transaction, a peer-to-peer transaction, a wire transfer, or an Automated Teller Machine (ATM) transaction; and
causing information indicative of the one or more attributes to be presented via the payment application executing on a user device of the user, wherein the information is presented(i) in a graphical user interface and (ii) in a user-readable format instead of the computer-readable format.
7. The system of claim 6, wherein:
the computer-readable format comprises at least one of: a first computer-readable format; or a second computer-readable format different than the first computer-readable format; and
the trained AI model is configured to process prompts that include the transaction data in the first computer-readable format and prompts that include the transaction data in the second computer-readable format.
8. The system of claim 6, wherein the one or more attributes comprise an entity other than the user.
9. The system of claim 6, the operations further comprising generating the prompt by including, in the prompt, requests for the trained AI model to:
determine the one or more attributes from the portion of the transaction data; and
provide a computer-readable object as output.
10. The system of claim 9, wherein the computer-readable object comprises a JavaScript Object Notation (JSON) object.
11. The system of claim 6, the operations further comprising:
receiving a validation that the one or more attributes determined using the trained AI model are correct; and
determining, based at least in part on the validation, that the one or more attributes determined using the trained AI model are correct,
wherein the causing of the information to be presented via the payment application executing on the user device is based at least in part on the determining that the one or more attributes determined using the trained AI model are correct.
12. The system of claim 6, the operations further comprising at least one of: storing, in a data store, an association between the portion of the transaction data and the one or more attributes; or retraining the trained AI model based at least in part on the association.
13. The system of claim 6, the operations further comprising:
determining, by accessing a data store using the portion of the transaction data, that an association between the portion of the transaction data and the one or more attributes is not stored in the data store,
wherein the providing of the prompt to the trained AI model is based on the determining that the association is not stored in the data store.
14. The system of claim 6, the operations further comprising:
extracting, from the transaction data, a string of alphanumeric characters that represents the transaction; and
transforming the string of alphanumeric characters into the portion of the transaction data,
wherein the portion of the transaction data is an embedding that comprises a string of numbers.
16. A computer-implemented method comprising:
receiving, by a payment service computing platform, transaction data associated with users of a payment application, wherein the transaction data is received in a computer-readable format;
providing, by the payment service computing platform, a prompt to a trained artificial intelligence (AI) model, wherein the prompt includes a portion of the transaction data that represents a transaction associated with a user of the users;
determining, by the payment service computing platform and based at least in part on the trained AI model processing the prompt, one or more attributes of the transaction, wherein the one or more attributes include at least a type of transaction that is one of an Automated Clearing House (ACH) transaction, a payment transaction, a peer-to-peer transaction, a wire transfer, or an Automated Teller Machine (ATM) transaction; and
causing, by the payment service computing platform, information indicative of the one or more attributes to be presented via the payment application executing on a user device of the user, wherein the information is presented (i) in a graphical user interface and (ii) in a user-readable format instead of the computer-readable format.
17. The computer-implemented method of claim 16, further comprising:
providing, by the payment service computing platform, the portion of the transaction data as input to a second trained AI model;
determining, by the payment service computing platform and based on the second trained AI model processing the portion of the transaction data, that the transaction is potentially fraudulent; and
causing, by the payment service computing platform, an alert to be presented via a display of a second user device of an authorized user to review the transaction for fraud.
18. The computer-implemented method of claim 16, further comprising:
providing, by the payment service computing platform, the portion of the transaction data as input to a second trained AI model;
determining, by the payment service computing platform and based on the second trained AI model processing the portion of the transaction data, that the transaction is noncompliant with terms of use of the payment application; and
causing, by the payment service computing platform, an alert to be presented via a display of a second user device of an authorized user to review the transaction for noncompliance with the terms of use.
19. The computer-implemented method of claim 16, further comprising generating the prompt by including in the prompt an example prompt and a correct AI-generated answer to the example prompt.
20. The computer-implemented method of claim 16, wherein the transaction data comprises at least one of: ACH transaction data that represents ACH transactions associated with the users; or card transaction data that represents card transactions associated with the users.
21. The system of claim 16, the operations further comprising generating the prompt by including in the prompt an example prompt and a correct AI-generated answer to the example prompt.
Yes. But for the recited additional elements as shown above in bold, the remaining limitations of the claims recite certain methods of organizing human activity. The claims are directed to identifying and displaying transaction information. This type of method of organizing human activity is a commercial interaction such as legal obligations, sales activities or behaviors, and business relations.
The claims also recite mental processes. For example, receiving transaction data involves observation, determining attributes of a transaction involves evaluation, and causing attributes to be displayed involves judgment and observation.
Thus, the claims recite an abstract idea.
Step 2A, Prong Two: Is the Abstract Idea Integrated into a Practical Application? (see MPEP 2106.04(d))
No. The claims as a whole merely use a computer as a tool to perform the abstract idea. The computing components (i.e., additional elements that are in bold above) are recited at a high level of generality and are merely invoked as a tool to implement the steps. For example, only a programmed general purpose computing device (i.e., payment service computing platform) is needed to implement the claimed process. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Additionally, there is no improvement to the functioning of a computer or technology. Therefore, the abstract idea is not integrated into a practical application.
Step 2B: Does the Claim Provide an Inventive Concept? (see MPEP 2106.05)
No. As discussed with respect to Step 2A, Prong 2, the additional elements in the claims, both individually and in combination, amount to no more than tools to perform the abstract idea. Merely performing the abstract idea using a computer cannot provide an inventive concept. Therefore, the claims do not provide an inventive concept.
As such, the claims are not patent eligible.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 5-10, 12, 14, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jin et al., U.S. Patent Application Publication No. 2022/0121649 A1; Wanage et al., U.S. Patent Application Publication Number 2024/0378604 A1; and Blakesley et al., U.S. Patent Application Publication Number 2021/0295280 A1.
Claim 1:
Jin teaches:
receiving, by a payment service computing platform, transaction data associated with users of a payment application provided by the payment service computing platform, wherein the transaction data is received in a computer-readable format (see at least Jin, paragraph 0181 (“The method 1700 starts at block 1701. At block 1702, the pre-processor 1302 receives a text string including raw data for a transaction. At block 1704, the pre-processor 1302 matches the text string to a plurality of entries in a first corpus, for example, matching the text string to a plurality of locations within a location corpus to extract location information from the text string. At block 1706, the pre-processor 1302 compares a portion of the text string to entries in a second corpus, for example, identifying a candidate entity from the text string based on a similarity score with respect to a plurality of entities within an entity corpus.”)).
providing, by the payment service computing platform, a prompt to a trained artificial intelligence (AI) model, wherein the prompt includes a portion of the transaction data that represents a transaction associated with a user of the users (see at least Jin, paragraph 0182 (“In response to the similarity score of the identified candidate entity being less than a threshold score, the system 1300 may perform blocks 1708 through 1714.”); paragraph 0183 (“At block 1708, the language model 1304 tokenizes the text string to create a sequence of tokens. At block 1710, the language model 1304 applied the masked language model 1308 to the sequence of tokens to generate a sequence of vectors. Each of the vectors may correspond to one of the tokens and may be encoded with information regarding one or more of the surrounding tokens in the sequence of tokens.”)).
determining, by the payment service computing platform and based on the trained AI model processing the prompt, an entity, other than the user, associated with the transaction… (see at least Jin, paragraph 0184 (“At block 1712, the bidirectional parser 1310 bidirectionally parses the sequence of vectors to identify tokens indicative of entity information. At block 1714, the bidirectional parser 1310 generates entity information using the tokens indicative of entity information. At block 1716, the post-processor 1316 generates normalized transaction data including the extracted location information and one of the identified candidate entity or the generated entity information. The method 1700 ends at block 1718. Though the example applications described with reference to of FIGS. 17A and 17B relate to location information and entity information, the parsing techniques implemented are applicable to other types of information/data.”)).
Jin does not explicitly teach, but Wanage, however, does teach:
…and a type of the transaction, wherein the type of transaction is one of an Automated Clearing House (ACH) transaction, a payment card transaction, a peer-to-peer transaction, a wire transfer, or an Automated Teller Machine (ATM) transaction (see at least Wanage, paragraph 0079 (“At operation 612, the machine learning component 28, via the model application engine 408, in a first instance applies a transaction categorization model to the selected raw transaction data 604 to infer and/or identify a category for each respective transaction, for example, from various features of each respective transaction. The machine learning component 28, via the data preparation engine 404, labels the respective transaction with the inferred/identified category. For example, and without limitation, each transaction may include one or more data elements or features indicative of a type of transaction, such as an ATM withdrawal, ATM deposit, paycheck deposit, check deposit, wire transfer, mobile transfer, point-of-sale (POS) transaction, etc.”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wanage’s method of determining a transaction type with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of efficiently determining information about the origin of a transaction in order to provide a user with a brief overview of the transaction. The type of transaction may be useful to a user who may want to quickly determine whether a transaction may be fraudulent.
Jin does not explicitly teach, but Blakesley, however, does teach:
causing, by the payment service computing platform, information indicative of the entity and the type of the transaction to be presented via the payment application executing on a user device of the user, wherein the information is presented (i) in a graphical user interface associated with an activity feed, a statement, or a receipt and (ii) in a user-readable format instead of the computer-readable format (see at least Blakesley, Figures 4-6 (Each figure shows an interface that displays an optimized digital receipt with transaction information on a user device.)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Blakesley’s optimized digital receipt with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of providing transaction information to a user in an easy to read format.
Claim 2:
Jin further teaches:
the transaction data comprises at least one of: ACH transaction data that represents ACH transactions associated with the users; or card transaction data that represents card transactions associated with the users; the computer-readable format comprises at least one of: a first computer-readable format associated with the ACH transaction data; or a second computer-readable format associated with the card transaction data; the first computer-readable format is different than the second computer-readable format; and the trained AI model is configured to process prompts that include the ACH transaction data in the first computer-readable format and prompts that include the card transaction data in the second computer-readable format (see at least Jin, paragraph 0046 (“As used herein, the term “transactions” may include any of various types of activities related to accounts, including but not limited to: financial transactions (e.g., ACH transfers, credit card transactions, debit card transactions, other types of payments or money transfers, etc.), updating account information, setting up alerts, etc.” Note: By accepting ACH, credit card, debit card etc. transaction data, the system and MLM inherently accept either computer readable format.)).
Claim 5:
Jin further teaches:
extracting, by the payment service computing platform and from the transaction data, a string of alphanumeric characters that represents the transaction; and transforming, by the payment service computing platform, the string of alphanumeric characters into the portion of the transaction data, wherein the portion of the transaction data is an embedding that comprises a string of numbers (see at least Jin, paragraphs 0181-0184).
Claim 6:
Jin teaches:
one or more processors; and memory storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: (see at least Jin, Figure 11 and associated text).
receiving transaction data associated with users of a payment application, wherein the transaction data is received in a computer-readable format (see at least Jin, paragraph 0181 (“The method 1700 starts at block 1701. At block 1702, the pre-processor 1302 receives a text string including raw data for a transaction. At block 1704, the pre-processor 1302 matches the text string to a plurality of entries in a first corpus, for example, matching the text string to a plurality of locations within a location corpus to extract location information from the text string. At block 1706, the pre-processor 1302 compares a portion of the text string to entries in a second corpus, for example, identifying a candidate entity from the text string based on a similarity score with respect to a plurality of entities within an entity corpus.”)).
providing a prompt to a trained artificial intelligence (AI) model, wherein the prompt includes a portion of the transaction data that represents a transaction associated with a user of the users (see at least Jin, paragraph 0182 (“In response to the similarity score of the identified candidate entity being less than a threshold score, the system 1300 may perform blocks 1708 through 1714.”); paragraph 0183 (“At block 1708, the language model 1304 tokenizes the text string to create a sequence of tokens. At block 1710, the language model 1304 applied the masked language model 1308 to the sequence of tokens to generate a sequence of vectors. Each of the vectors may correspond to one of the tokens and may be encoded with information regarding one or more of the surrounding tokens in the sequence of tokens.”)).
determining, based at least in part on the trained AI model processing the prompt, one or more attributes of the transaction (see at least Jin, paragraph 0184 (“At block 1712, the bidirectional parser 1310 bidirectionally parses the sequence of vectors to identify tokens indicative of entity information. At block 1714, the bidirectional parser 1310 generates entity information using the tokens indicative of entity information. At block 1716, the post-processor 1316 generates normalized transaction data including the extracted location information and one of the identified candidate entity or the generated entity information. The method 1700 ends at block 1718. Though the example applications described with reference to of FIGS. 17A and 17B relate to location information and entity information, the parsing techniques implemented are applicable to other types of information/data.”)).
Jin does not explicitly teach, but Wanage, however, does teach:
wherein the one or more attributes include at least a type of transaction that is one of an Automated Clearing House (ACH) transaction, a payment card transaction, a peer-to-peer transaction, a wire transfer, or an Automated Teller Machine (ATM) transaction (see at least Wanage, paragraph 0079 (“At operation 612, the machine learning component 28, via the model application engine 408, in a first instance applies a transaction categorization model to the selected raw transaction data 604 to infer and/or identify a category for each respective transaction, for example, from various features of each respective transaction. The machine learning component 28, via the data preparation engine 404, labels the respective transaction with the inferred/identified category. For example, and without limitation, each transaction may include one or more data elements or features indicative of a type of transaction, such as an ATM withdrawal, ATM deposit, paycheck deposit, check deposit, wire transfer, mobile transfer, point-of-sale (POS) transaction, etc.”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wanage’s method of determining a transaction type with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of efficiently determining information about the origin of a transaction in order to provide a user with a brief overview of the transaction. The type of transaction may be useful to a user who may want to quickly determine whether a transaction may be fraudulent.
Jin does not explicitly teach, but Blakesley, however, does teach:
causing information indicative of the one or more attributes to be presented via the payment application executing on a user device of the user, wherein the information is presented (i) in a graphical user interface and (ii) in a user-readable format instead of the computer-readable format (see at least Blakesley, Figures 4-6 (Each figure shows an interface that displays an optimized digital receipt with transaction information on a user device.)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Blakesley’s optimized digital receipt with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of providing transaction information to a user in an easy to read format.
Claim 7:
Jin further teaches:
the computer-readable format comprises at least one of: a first computer-readable format; or a second computer-readable format different than the first computer-readable format; and the trained AI model is configured to process prompts that include the transaction data in the first computer-readable format and prompts that include the transaction data in the second computer-readable format (see at least Jin, paragraph 0046 (“As used herein, the term “transactions” may include any of various types of activities related to accounts, including but not limited to: financial transactions (e.g., ACH transfers, credit card transactions, debit card transactions, other types of payments or money transfers, etc.), updating account information, setting up alerts, etc.” Note: By accepting ACH, credit card, debit card etc. transaction data, the system and MLM inherently accept either computer readable format.); paragraph 0138; paragraph 0139).
Claim 8:
Jin further teaches:
wherein the one or more attributes comprise an entity other than the user (see at least Jin, paragraph 0146 (An example of an identified entity is SAPPS); paragraph 0184 (“. Though the example applications described with reference to of FIGS. 17A and 17B relate to location information and entity information, the parsing techniques implemented are applicable to other types of information/data.”)).
Claim 9:
Jin further teaches:
generating the prompt by including, in the prompt, requests for the trained AI model to: determine the one or more attributes from the portion of the transaction data; and provide a computer-readable object as output (see at least Jin, paragraph 0182 (“In response to the similarity score of the identified candidate entity being less than a threshold score, the system 1300 may perform blocks 1708 through 1714.”); paragraph 0183 (“At block 1708, the language model 1304 tokenizes the text string to create a sequence of tokens. At block 1710, the language model 1304 applied the masked language model 1308 to the sequence of tokens to generate a sequence of vectors. Each of the vectors may correspond to one of the tokens and may be encoded with information regarding one or more of the surrounding tokens in the sequence of tokens.”)).
Claim 10:
Jin further teaches:
wherein the computer-readable object comprises a JavaScript Object Notation (JSON) object (see at least Jin, paragraph 0069 (“The returned results can be represented data format such as JSON, XML, or any suitable format.”)).
Claim 12:
Jin further teaches:
at least one of: storing, in a data store, an association between the portion of the transaction data and the one or more attributes; or retraining the trained AI model based at least in part on the association (see at least Jin, paragraphs 0049-0050 (data storage); paragraph 0163 (“The masked language model 1308 may further update the model parameters with back propagation after calculating the loss.”)).
Claim 14:
Jin further teaches:
extracting, from the transaction data, a string of alphanumeric characters that represents the transaction; and transforming the string of alphanumeric characters into the portion of the transaction data, wherein the portion of the transaction data is an embedding that comprises a string of numbers (see at least Jin, paragraphs 0181-0184).
Claim 16:
Jin teaches:
receiving, by a payment service computing platform, transaction data associated with users of a payment application, wherein the transaction data is received in a computer-readable format (see at least Jin, paragraph 0181 (“The method 1700 starts at block 1701. At block 1702, the pre-processor 1302 receives a text string including raw data for a transaction. At block 1704, the pre-processor 1302 matches the text string to a plurality of entries in a first corpus, for example, matching the text string to a plurality of locations within a location corpus to extract location information from the text string. At block 1706, the pre-processor 1302 compares a portion of the text string to entries in a second corpus, for example, identifying a candidate entity from the text string based on a similarity score with respect to a plurality of entities within an entity corpus.”)).
providing, by the payment service computing platform, a prompt to a trained artificial intelligence (AI) model, wherein the prompt includes a portion of the transaction data that represents a transaction associated with a user of the users (see at least Jin, paragraph 0182 (“In response to the similarity score of the identified candidate entity being less than a threshold score, the system 1300 may perform blocks 1708 through 1714.”); paragraph 0183 (“At block 1708, the language model 1304 tokenizes the text string to create a sequence of tokens. At block 1710, the language model 1304 applied the masked language model 1308 to the sequence of tokens to generate a sequence of vectors. Each of the vectors may correspond to one of the tokens and may be encoded with information regarding one or more of the surrounding tokens in the sequence of tokens.”)).
determining, by the payment service computing platform and based at least in part on the trained AI model processing the prompt, one or more attributes of the transaction (see at least Jin, paragraph 0184 (“At block 1712, the bidirectional parser 1310 bidirectionally parses the sequence of vectors to identify tokens indicative of entity information. At block 1714, the bidirectional parser 1310 generates entity information using the tokens indicative of entity information. At block 1716, the post-processor 1316 generates normalized transaction data including the extracted location information and one of the identified candidate entity or the generated entity information. The method 1700 ends at block 1718. Though the example applications described with reference to of FIGS. 17A and 17B relate to location information and entity information, the parsing techniques implemented are applicable to other types of information/data.”)).
Jin does not explicitly teach, but Wanage, however, does teach:
wherein the one or more attributes include at least a type of transaction that is one of an Automated Clearing House (ACH) transaction, a payment transaction, a peer-to-peer transaction, a wire transfer, or an Automated Teller Machine (ATM) transaction (see at least Wanage, paragraph 0079 (“At operation 612, the machine learning component 28, via the model application engine 408, in a first instance applies a transaction categorization model to the selected raw transaction data 604 to infer and/or identify a category for each respective transaction, for example, from various features of each respective transaction. The machine learning component 28, via the data preparation engine 404, labels the respective transaction with the inferred/identified category. For example, and without limitation, each transaction may include one or more data elements or features indicative of a type of transaction, such as an ATM withdrawal, ATM deposit, paycheck deposit, check deposit, wire transfer, mobile transfer, point-of-sale (POS) transaction, etc.”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Wanage’s method of determining a transaction type with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of efficiently determining information about the origin of a transaction in order to provide a user with a brief overview of the transaction. The type of transaction may be useful to a user who may want to quickly determine whether a transaction may be fraudulent.
Jin does not explicitly teach, but Blakesley, however, does teach:
causing, by the payment service computing platform, information indicative of the one or more attributes to be presented via the payment application executing on a user device of the user, wherein the information is presented (i) in a graphical user interface and (ii) in a user-readable format instead of the computer-readable format (see at least Blakesley, Figures 4-6 (Each figure shows an interface that displays an optimized digital receipt with transaction information on a user device.)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Blakesley’s optimized digital receipt with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of providing transaction information to a user in an easy to read format.
Claim 20:
Jin further teaches:
wherein the transaction data comprises at least one of: ACH transaction data that represents ACH transactions associated with the users; or card transaction data that represents card transactions associated with the users (see at least Jin, paragraph 0046 (“As used herein, the term “transactions” may include any of various types of activities related to accounts, including but not limited to: financial transactions (e.g., ACH transfers, credit card transactions, debit card transactions, other types of payments or money transfers, etc.), updating account information, setting up alerts, etc.”)).
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Jin et al., U.S. Patent Application Publication No. 2022/0121649 A1; Wanage et al., U.S. Patent Application Publication Number 2024/0378604 A1; Blakesley et al., U.S. Patent Application Publication Number 2021/0295280 A1; and Scenna et al., U.S. Patent Application Publication Number 2025/0078171 A1.
Claim 3:
Jin further teaches:
generating, by the payment service computing platform, the prompt by including, in the prompt, requests for the trained AI model to: determine the entity and the type of the transaction from the portion of the transaction data; … provide a computer-readable object as output (see at least Jin, paragraph 0182 (“In response to the similarity score of the identified candidate entity being less than a threshold score, the system 1300 may perform blocks 1708 through 1714.”); paragraph 0183 (“At block 1708, the language model 1304 tokenizes the text string to create a sequence of tokens. At block 1710, the language model 1304 applied the masked language model 1308 to the sequence of tokens to generate a sequence of vectors. Each of the vectors may correspond to one of the tokens and may be encoded with information regarding one or more of the surrounding tokens in the sequence of tokens.”); paragraph 0184 (“At block 1712, the bidirectional parser 1310 bidirectionally parses the sequence of vectors to identify tokens indicative of entity information. At block 1714, the bidirectional parser 1310 generates entity information using the tokens indicative of entity information. At block 1716, the post-processor 1316 generates normalized transaction data including the extracted location information and one of the identified candidate entity or the generated entity information. The method 1700 ends at block 1718. Though the example applications described with reference to of FIGS. 17A and 17B relate to location information and entity information, the parsing techniques implemented are applicable to other types of information/data.”)).
Jin does not explicitly teach, but Scenna, however, does teach:
explain steps performed and/or reasoning for determining the entity and the type of the transaction from the portion of the transaction data (see at least Scenna, paragraph 0020 (“In some embodiments, the user interface tool may include a first user interface element that, when selected by the user, activates a first modality in which a more detailed explanation of the particular result is generated using a generative artificial intelligence model. For instance, in some embodiments, selection of the first user interface element by the user may cause the explanation (e.g., question and answer) generated by the software application to be provided as an input to the generative artificial intelligence model. Selection of the first user interface element by the user may also cause a natural language prompt associated with the first modality to be provided as an input to the generative artificial intelligence model. As an example, the natural language prompt associated with the first modality may read, “Based on the provided question and answer, please reformulate the answer in a way that is easy to understand for novice users. Provide more context and explain in depth.” The generative artificial intelligence model may output a more detailed explanation of the particular result determined by the software application based, at least in part, on the inputs (that is, the natural language prompt associated with the first modality and the explanation generated by the software application).”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Scenna’s method of requesting the AI model to provide an explanation of the results with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of making the outputted information easy to understand for novice users. Additionally, the information could be used for retraining the model.
Claims 4 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Jin et al., U.S. Patent Application Publication No. 2022/0121649 A1; Wanage et al., U.S. Patent Application Publication Number 2024/0378604 A1; Blakesley et al., U.S. Patent Application Publication Number 2021/0295280 A1; and Weir et al., U.S. Patent Application Publication Number 2005/0182774 A1.
Claim 4:
Jin does not explicitly teach, but Weir, however, does teach:
receiving, by the payment service computing platform, a validation that the entity determined using the trained AI model is correct and that the type of the transaction determined using the trained AI model is correct; and determining, by the payment service computing platform and based on the validation, that the entity determined using the trained AI model is correct and that the type of the transaction determined using the trained AI model is correct, wherein the causing of the information to be presented via the payment application executing on the user device is based on the determining that the entity determined using the trained AI model is correct and that the type of the transaction determined using the trained AI model is correct (see at least Weir, Figure 9; paragraph 0164 (“FIG. 9 shows a sample screen layout 90 for use in the record reconciling process. This screen is displayed after initial receipt of the transaction file and validating the file for data errors.”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Weir’s method of validating the transaction data before displaying it to a user with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of providing accurate information to a user.
Claim 11:
Jin does not explicitly teach, but Weir, however, does teach:
receiving a validation that the one or more attributes determined using the trained AI model are correct; and determining, based at least in part on the validation, that the one or more attributes determined using the trained AI model are correct, wherein the causing of the information to be presented via the payment application executing on the user device is based at least in part on the determining that the one or more attributes determined using the trained AI model are correct (see at least Weir, Figure 9; paragraph 0164 (“FIG. 9 shows a sample screen layout 90 for use in the record reconciling process. This screen is displayed after initial receipt of the transaction file and validating the file for data errors.”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Weir’s method of validating the transaction data before displaying it to a user with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of providing accurate information to a user.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Jin et al., U.S. Patent Application Publication No. 2022/0121649 A1; Wanage et al., U.S. Patent Application Publication Number 2024/0378604 A1; Blakesley et al., U.S. Patent Application Publication Number 2021/0295280 A1; and Evenson et al., U.S. Patent Number 12,002,076 B1.
Claim 13:
Jin does not explicitly teach, but Evenson, however, does teach:
determining, by accessing a data store using the portion of the transaction data, that an association between the portion of the transaction data and the one or more attributes is not stored in the data store, wherein the providing of the prompt to the trained AI model is based on the determining that the association is not stored in the data store (see at least Evenson, column 12, lines 15-21 (“The workflow management service 138 may also determine whether any transaction data 126 is missing from the aggregate contract data object 116, based on the change tracking data 128, and send instruction(s) to cause the contract engine 112 to send service call(s) 118 requesting that the missing transaction data 126 be generated.”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Evenson’s method of requesting missing transaction data with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of obtaining data that does not already exist and is needed.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Jin et al., U.S. Patent Application Publication No. 2022/0121649 A1; Wanage et al., U.S. Patent Application Publication Number 2024/0378604 A1; Blakesley et al., U.S. Patent Application Publication Number 2021/0295280 A1; and Shah et al., U.S. Patent Application Publication Number 2024/0303662 A1.
Claim 17:
Jin does not explicitly teach, but Shah, however, does teach:
providing, by the payment service computing platform, the portion of the transaction data as input to a second trained AI model; determining, by the payment service computing platform and based on the second trained AI model processing the portion of the transaction data, that the transaction is potentially fraudulent; and causing, by the payment service computing platform, an alert to be presented via a display of a second user device of an authorized user to review the transaction for fraud (see at least Shah, paragraph 0004 (“A method, apparatus, non-transitory computer readable medium, and system for identifying fraudulent activity in non-fungible token (NFT) exchanges are described. One or more aspects of the method, apparatus, non-transitory computer readable medium, and system include obtaining transaction data for non-fungible tokens (NFTs); generating, using a graph component, a transaction graph based on the transaction data, wherein the transaction graph includes nodes corresponding to blockchain addresses and nodes corresponding to individual NFTs; identifying, using a cycle component, a cycle of the transaction graph; predicting, using a machine learning model a fraudulent activity based on the cycle; and transmitting an alert indicating the predicted fraudulent activity.”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Shah’s method of using a machine learning model to identify fraud with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of identifying transactions that may be fraudulent in order to prevent additional fraud and recover any stolen funds due to fraud.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Jin et al., U.S. Patent Application Publication No. 2022/0121649 A1; Wanage et al., U.S. Patent Application Publication Number 2024/0378604 A1; Blakesley et al., U.S. Patent Application Publication Number 2021/0295280 A1; and Simons et al., U.S. Patent Application Publication Number 2019/0379642 A1.
Claim 18:
Jin does not explicitly teach, but Simons, however, does teach:
providing, by the payment service computing platform, the portion of the transaction data as input to a second trained AI model; determining, by the payment service computing platform and based on the second trained AI model processing the portion of the transaction data, that the transaction is noncompliant with terms of use of the payment application; and causing, by the payment service computing platform, an alert to be presented via a display of a second user device of an authorized user to review the transaction for noncompliance with the terms of use (see at least Simons, paragraph 0023 (“use of unconventional and non-routine computer operations to establish a secure communication channel between parties of a (potential) transaction which can be automatically analyzed (e.g., using machine learning) to ensure compliance with governmental regulations, terms of use, or other restrictions”)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Simons’ method of using machine learning to ensure compliance with terms of use with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of identifying any transactions that involve a breach of the terms of use so that proper measures can be taken.
Claims 19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Jin et al., U.S. Patent Application Publication No. 2022/0121649 A1; Wanage et al., U.S. Patent Application Publication Number 2024/0378604 A1; Blakesley et al., U.S. Patent Application Publication Number 2021/0295280 A1; and Deep Learning, Isaak Kamau, https://community.deeplearning.ai/t/how-to-feed-model-output-data-back-for-training/282652 (Feb. 2023).
Claim 19:
Jin does not explicitly teach, but Deep Learning, however, does teach:
generating the prompt by including in the prompt an example prompt and a correct AI-generated answer to the example prompt (see at least Deep Learning, pages 2-3 (4. Collect feedback data: Collect feedback data on the predictions made by your model. This feedback data should consist of input-output pairs, where the input is the data that your model made a prediction on, and the output is the correct result. For example, if your model is a image classifier, the feedback data could consist of images and their correct classifications. 5. Use the feedback data to retrain the model: Finally, you can use the feedback data to retrain your model. This will help the model learn from its mistakes and improve its predictions. You can repeat this process iteratively to continuously improve the performance of your model.)).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Deep Learning’s method of using a machine learning model’s output data as feedback for retraining the model with Jin’s parsing of transaction data. One of ordinary skill in the art would have been motivated to incorporate this feature for the purpose of retraining the model so that its accuracy is improved.
Claim 21:
Claim 21 is rejected using the same rationale that was used for the rejection of claim 19.
Relevant Prior Art
The following references are relevant to Applicant’s invention:
Avagyan et al., U.S. Patent Application Publication Number 2018/0246943 A1. This reference teaches data extraction and transformation.
Bodalia et al., U.S. Patent Application Publication Number 2022/0076234 A1. This reference teaches transaction identification.
Email Communications
Per MPEP 502.03, Applicant may authorize email communications by filing Form PTO/SB/439, available at https://www.uspto.gov/sites/default/files/documents/sb0439.pdf, via the USPTO patent electronic filing system.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ELIZABETH H ROSEN whose telephone number is (571)270-1850 and email address is elizabeth.rosen@uspto.gov. The examiner can normally be reached Monday - Friday, 10 AM ET - 7 PM ET.
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, Michael Anderson, can be reached at 571-270-0508. 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.
/ELIZABETH H ROSEN/Primary Examiner, 3693
1 See MPEP 2106.04(d)(2) (“Examiners should keep in mind that in order to qualify as a "treatment" or "prophylaxis" limitation for purposes of this consideration, the claim limitation in question must affirmatively recite an action that effects a particular treatment or prophylaxis for a disease or medical condition. An example of such a limitation is a step of "administering amazonic acid to a patient" or a step of "administering a course of plasmapheresis to a patient." If the limitation does not actually provide a treatment or prophylaxis, e.g., it is merely an intended use of the claimed invention or a field of use limitation, then it cannot integrate a judicial exception under the "treatment or prophylaxis" consideration. For example, a step of "prescribing a topical steroid to a patient with eczema" is not a positive limitation because it does not require that the steroid actually be used by or on the patient, and a recitation that a claimed product is a "pharmaceutical composition" or that a "feed dispenser is operable to dispense a mineral supplement" are not affirmative limitations because they are merely indicating how the claimed invention might be used.”)