DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1-6, 9-10, 12-19, and 21-23 are currently pending and rejected.
Claims 7-8, 11, and 20 are canceled.
Claim Rejection – 35 U.S.C. 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-6, 9-10, 12-19, and 21-23 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The rationale for this finding is explained below. In the instant case, the claims are directed towards providing summary of user transactions and prompting user to validate detected potential fraudulent transaction, thus the present claims fall within the Certain Method of Organizing Human Activity grouping. Moreover, the claimed procedure can be performed mentally, thus the present claims also fall within the Mental Processes grouping. The claims do not include limitations that are “significantly more” than the abstract idea because the claims do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Note that the limitations, in the instant claims, are done by the generically recited computer device. The limitations are merely instructions to implement the abstract idea on a computer and require no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry. Therefore, claims 1-6, 9-10, 12-19, and 21-23 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claims 1-6, 9, and 21-22 are directed to a process (i.e., method claims).
Claims 10, 12-15, and 23 are directed to a machine (i.e., device/system claims).
Claims 16-19 are directed to a manufacture (i.e., machine-readable medium claims).
Step 1: The claims 1-6, 9-10, 12-19, and 21-23 are directed to a process, machine, manufacture, or composition matter.
In Alice Corp. Pty. Ltd. v. CLS Bank Intern., 134 S. Ct. 2347 (2014), the Supreme Court applied a two-step test for determining whether a claim recites patentable subject matter. First, we determine whether the claims at issue are directed to one or more patent-ineligible concepts, i.e., laws of nature, natural phenomenon, and abstract ideas. Id. at 2355 (citing Mayo Collaborative Servs. v. Prometheus Labs., Inc., 132 S. Ct. 1289, 1296–96 (2012)). If so, we then consider whether the elements of each claim, both individually and as an ordered combination, transform the nature of the claim into a patent-eligible application to ensure that the patent in practice amounts to significantly more than a patent upon the ineligible concept itself.
Claims 1-9 are directed to a process (i.e., method claims).
Claims 10-15 are directed to a machine (i.e., device/system claims).
Claims 16-20 are directed to a manufacture (i.e., machine-readable medium claims).
Step 2A: The claims are directed to an abstract idea.
Prong One
The present claims are directed towards providing summary of user transactions and prompting user to validate detected potential fraudulent transaction. The concept comprises determining a user has completed a transaction, sending a request to generate a narrative for the transaction, receiving a response indicating that the user would like to generate a narrative for the transaction, obtaining one or more data points associated with the transaction, inputting the one or more data points to a generative artificial intelligence model, receiving a first narrative associated with the transaction, receiving an indication of a potentially fraudulent transaction, sending a second narrative associated with the potentially fraudulent transaction, and causing the user device to display a prompt to validate the potentially fraudulent transaction. Providing summary of user transactions and prompting user to validate detected potential fraudulent transaction are related to managing human transactions, thus the present claims clearly fall within the Certain Method of Organizing Human Activity grouping. Examiner also points out that the present claims, similar to the ineligible claims in Electric Power Group v. Alstom, recite obtaining data, analyzing data, and presenting result of the analysis. The claimed concept can be performed in the human mind and the result can be presenting on paper. As such, the present claims also fall within the Mental Processes grouping. The performance of the claim limitations using generic computer components (i.e., a computing device comprising a processor and a memory) does not preclude the claim limitation from being in the certain methods of organizing human activity grouping or mental processes grouping. Accordingly, the present claims recite an abstract idea.
Prong Two
Independent claims 1, 10, and 16 recite a computing device, a generative artificial intelligence, and a user device as additional elements. The additional elements are claimed to perform basic computer functions, such as detecting a user transaction, transmitting a request, receiving a response, obtaining data associated with the transaction, inputting the data into an AI and obtaining output, receiving indication of a potentially fraudulent transaction, transmitting a message to be displayed on a user device to obtain user validation of the potentially fraudulent transaction. The recitation of the computer elements amounts to mere instruction to implement an abstract concept on computers. Dependent claims 2-6, 9, 12-15, 17-19, and 21-23 do not recite any other additional element. The present claims do not solve a problem specifically arising in the realm of computer networks. Although the present claims utilize a generative artificial intelligence, the claimed invention only uses AI as a tool without improving AI technology. In the recent decision, Recentive Analytics, Inc. v. Fox Corp., the Federal Circuit ruled that “patents do no more than claims the application of generic machine learning to new data environments, without disclosing improvements to the machine learning models to be applied, are patent ineligible under 101”. The present claims do not recite limitation that improve the functioning of computer, effect a physical transformation, or apply the abstract concept in some other meaningful way beyond generally linking the use of the abstract concept to a particular technological environment. As such, the present claims fail to integrate into a practical application.
Step 2B: The claims do not recite additional elements that amount to significantly more than the abstract idea.
As discussed earlier, the present claims only recite a computing device, a generative artificial intelligence, and a user device as additional elements. The additional elements are claimed to perform basic computer functions, such as detecting a user transaction, transmitting a request, receiving a response, obtaining data associated with the transaction, inputting the data into an AI and obtaining output, receiving indication of a potentially fraudulent transaction, transmitting a message to be displayed on a user device to obtain user validation of the potentially fraudulent transaction. According to MPEP 2106.05(d), “performing repetitive calculations”, “receiving, processing, and storing data”, “electronically scanning or extracting data from a physical document”, “electronic recordkeeping”, “storing and retrieving information in memory”, and “receiving or transmitting data over a network, e.g., using the Internet to gather data” are considered well-understood, routine, and conventional functions of computer. The present claims do not improve the functioning of computer. Simply implementing the abstract idea on a generic computer or using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, the present claims are ineligible for patent.
In the response filed on 01/27/2026, Applicant amended the independent claims by removing some limitations and also adding a new feature – “sanitizing, from the one or more data points, personally identifiable information”. Examiner points out that sanitizing PII, or encrypting/masking/obscuring PII, was not only a well-known feature prior to the present invention, it is required by law in certain countries. The amended claims do not specify the data sanitizing technique, and there were already available and well-known techniques. As such, the amended feature does not improve computer or AI function. Therefore, the amended claims cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B.
Claim Rejection – 35 U.S.C. 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.
Claim(s) 1, 3, 4, 6, and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al. (KR 20220108415 A), in view of Mark et al. (Pub. No.: US 2011/0184853) and Ramesh et al. (Pub. No.: 2021/0304204) and Shachar et al. (Pub. No.: US 2023/0306429).
As per claim 1, Kim teaches a method comprising:
determining, by a computing device, that a user completed a transaction (see page 3, “As described above, the sales article, purchase article, and transaction agreement information used in the transaction between the seller and the buyer are provided to the transaction history generating unit 20 through the interface unit 10”; see page 4, “Through this process, the contents of confirmation and agreement between the parties to the transaction can be arranged in the form of a contract”; transaction details are automatically fed into the transaction history generating unit);
sending, based on a determination that the user completed the transaction, a request to generate a narrative for the transaction (see page 3, “The interface unit 10 is configured to obtain various information related to the used goods transaction between the transactions parties and provide it to the transaction detail generation unit 20”, “The transaction history generating unit 20 is configured to generate transaction details based on information through the interface unit 10”);
obtaining, via one or more application programming interfaces (see page 3, “The interface unit 10 is configured to obtain various information related to the used goods transaction between the transactions parties and provide it to the transaction detail generation unit 20”, “The transaction history generating unit 20 is configured to generate transaction details based on information through the interface unit 10”), one or more data points associated with the transaction (see page 4, “The transaction history generating unit 20 inputs sales text/purchase text and transaction agreement information, which is a conversational content, into a deep learning module learning model to be summarized”, “The summary contents that can be confirmed as a transaction may include the name of the product to be transacted, a description of the status of the product, a transaction method (direct transaction, courier transaction), transaction data, transaction amount, and the like”);
inputting the one or more data points into a generative artificial intelligence model trained to generate narratives for each transaction (see page 4, “The transaction history generating unit 20 inputs sales text/purchase text and transaction agreement information, which is a conversational content, into a deep learning module learning model to be summarized…Here, the deep learning module learning module is based on TF-IDF (Term Frequency-Inverse Document Frequency), NLP (Natural Machine Learning) that extracts important paragraphs from documents, Seq2Seq (Sequence to Sequence), Transformers, BERT (Bidirectional Encoder Representations from) Transformers) and the like may be used”, “The summary contents that can be confirmed as a transaction may include the name of the product to be transacted, a description of the status of the product, a transaction method (direct transaction, courier transaction), transaction data, transaction amount, and the like”; the learning module is a generative artificial intelligence);
receiving, from the generative artificial intelligence model and based on the one or more data points, a first narrative associated with the transaction (see page 3, “To this end, the transaction history generating unit 200 uses a pre-trained deep learning module learning model, and the deep learning module learning model generates transaction details by summarizing the information provided from the interface unit 100”; see page 4, “Here, the deep learning module learning module summarizes text-based documents into, for example, 2-3 lines of text”; summarizing transaction is the same as generating transaction narrative).
Examiner notes however, Kim does not teach receiving, in response to the request, an indication to generate a narrative for the transaction.
Mark teaches receiving, in response to the request, an indication to generate a narrative for the transaction (see paragraph 0034, “the consumer 102 not only indicates that she would like to receive audio messages summarizing her financial transactions, but also provides information relating to how she would like to receive such audio messages”).
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify Kim with teaching from Mark to include receiving, in response to the request, an indication to generate a narrative for the transaction. The modification would have been obvious, because it is merely applying a known technique (i.e., receiving a response indicting that the user would like to generate a narrative for the transaction) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., ensure the narrative is actually desired by the user).
Examiner notes however, the combination of Kim and Mark does not teach receiving, by the computing device, an indication of a potentially fraudulent transaction; sending, to a user device, a second narrative associated with the potentially fraudulent transaction; and causing, based on the indication of the potentially fraudulent transaction and based on the second narrative, the user device to display a prompt to validate the potentially fraudulent transaction.
Ramesh teaches receiving, by the computing device, an indication of a potentially fraudulent transaction (see paragraph 0011, 0016, and 0018, “the narrative text generator may show top 3 factors, such as counterparty identification, amount, and time/date/recurrence of the transactions that indicate potential fraud or other prohibited behavior by an account”; see paragraph 0019, “the machine learning model may be built and implemented in a service and/or engine of one or more service providers for detection for fraud”; also see paragraph 0032 and 0043);
sending, to a user device, a second narrative associated with the potentially fraudulent transaction (see paragraph 0025, “The flagged transactions may include a narrative displayable through alert review application 112, such as a textual description of the reason for flagging the transaction(s) by the model”; also see paragraph 0030); and
causing, based on the indication of the potentially fraudulent transaction and based on the second narrative, the user device to display a prompt to validate the potentially fraudulent transaction (see paragraph 0011, “These may be then reviewed by an agent to determine whether the flags may be false positive where the transactions were flagged but do not indicate fraud to a sufficient level to require reporting to a regulatory body”; see paragraph 0018, “an agent may provide further feedback on whether there are any false positives on the data”; see paragraph 0025, “An agent may identify any false positive in the flagging of transactions as potentially prohibited, which may be provided back to service provider server 120 for retraining (e.g., iteratively and/or continuously training) of the machine learning model. The flagged transactions may include a narrative displayable through alert review application 112, such as a textual description of the reason for flagging the transaction(s) by the model”; also see paragraph 0053, “The narrative further shows textual information of the explanation output graph for a machine learning prediction explainer, which allows an agent to quickly review the transaction(s) and determine whether this is a false positive”; also see paragraph 0061-0064).
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify combination of Kim and Mark with teaching from Ramesh to include receiving, by the computing device, an indication of a potentially fraudulent transaction; sending, to a user device, a second narrative associated with the potentially fraudulent transaction; and causing, based on the indication of the potentially fraudulent transaction and based on the second narrative, the user device to display a prompt to validate the potentially fraudulent transaction. The modification would have been obvious, because it is merely applying a known technique (i.e., providing narrative of potentially fraudulent transaction) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., allow user to quickly understand why the potentially fraudulent transaction is flagged).
Examiner further notes the combination of Kim, Mark, and Ramesh does not teach sanitizing, from the one or more data points, personally identifiable information. According to paragraph 0046 of Applicant’s specification, sanitizing means encrypting, masking, or using other process of securing the one or more data points.
Shachar teaches sanitizing, from the one or more data points, personally identifiable information (see paragraph 0052 and 0054, “personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable”; see paragraph 0073 and 0077, “receive financial transactions of a preconfigured period, wherein data of each financial transaction of the financial-transactions comprises masked sensitive Personal Identifiable Information (PII) parameters”; see paragraph 0089, “four financial transactions in which four people, i.e., payors, sent their money to other four people, i.e., payees. Sensitive-PII, such as names were masked or obfuscated”; also see paragraph 0049).
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify combination of Kim, Mark, and Ramesh with teaching from Shachar to include sanitizing, from the one or more data points, personally identifiable information. The modification would have been obvious, because it is merely applying a known technique (i.e., sanitizing, from the one or more data points, personally identifiable information) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., enhance privacy and comply with laws).
As per claim 3, Kim does not teach receiving a confirmation that the potentially fraudulent transaction was fraudulent; and sending, based on receiving the confirmation, an indication that a fraud investigation will be opened.
Ramesh teaches receiving a confirmation that the potentially fraudulent transaction was fraudulent; and sending, based on receiving the confirmation, an indication that a fraud investigation will be opened (see paragraph 0025, “An agent may identify any false positives in the flagging of transaction as potentially prohibited…The flagged transactions may include a narrative displayable through alert review application 112;” see paragraph 0061, “narratives for flagged transactions are determined and output for review, such as to an agent associated with reporting prohibited transaction to a regulatory agency”).
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify Kim with teaching from Ramesh to include receiving a confirmation that the potentially fraudulent transaction was fraudulent; and sending, based on receiving the confirmation, an indication that a fraud investigation will be opened. The modification would have been obvious, because it is merely applying a known technique (i.e., receiving a confirmation whether the flagged transaction is a false positive or not) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., determine whether to contact regulatory body).
As per claim 4, Kim does not teach receiving an indication that the potentially fraudulent transaction was not fraudulent; and sending, to the user device and based on the indication that the potentially fraudulent transaction was not fraudulent, an indication that a fraud investigation will not be opened.
Ramesh teaches receiving an indication that the potentially fraudulent transaction was not fraudulent; and sending, to the user device and based on the indication that the potentially fraudulent transaction was not fraudulent, an indication that a fraud investigation will not be opened (see paragraph 0025, “An agent may identify any false positives in the flagging of transaction as potentially prohibited…The flagged transactions may include a narrative displayable through alert review application 112;” see paragraph 0061, “narratives for flagged transactions are determined and output for review, such as to an agent associated with reporting prohibited transaction to a regulatory agency”).
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify Kim with teaching from Ramesh to include receiving an indication that the potentially fraudulent transaction was not fraudulent; and sending, to the user device and based on the indication that the potentially fraudulent transaction was not fraudulent, an indication that a fraud investigation will not be opened. The modification would have been obvious, because it is merely applying a known technique (i.e., receiving a confirmation whether the flagged transaction is a false positive or not) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., determine whether to contact regulatory body).
As per claim 6, Kim teaches training, based on the one or more data points, the generative artificial intelligence model to generate narratives for transactions (see page 3, “To this end, the transaction history generating unit 200 uses a pre-trained deep learning module learning model, and the deep learning module learning model generates transaction details by summarizing the information provided from the interface unit 100”; see page 4, “Here, the deep learning module learning module summarizes text-based documents into, for example, 2-3 lines of text”; summarizing transaction is the same as generating transaction narrative).
Claim 7 and 8 are canceled.
As per claim 9, Kim does not teach tokenizing the one or more data points.
Ramesh teaches tokenizing the one or more data points (see paragraph 0013 and 0036, “Database 124 may store financial information and tokenization data”).
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify Kim with teaching from Ramesh to include r tokenizing the one or more data points. The modification would have been obvious, because it is merely applying a known technique (i.e., tokenizing data) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., enhance security).
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al. (KR 20220108415 A), in view of Mark et al. (Pub. No.: US 2011/0184853) and Ramesh et al. (Pub. No.: 2021/0304204) and Shachar et al. (Pub. No.: US 2023/0306429), and further in view of Benkreira et al. (Pub. No.: US 2023/0260017).
As per claim 2, Kim does not teach wherein the determining that the user completed the transaction comprises detecting, using a document object model (DOM), one or more elements on a webpage indicating that the user is performing the transaction.
Benkreira teaches wherein the determining that the user completed the transaction comprises detecting, using a document object model (DOM), one or more elements on a webpage indicating that the user is performing the transaction (see paragraph 0036, “DOM elements (e.g., receipt heading, complete purchase button, etc.) and/or text (e.g., ‘thank you for your purchase’, ‘total’, ‘subtotal’, etc.) indicating completion of a transaction).
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify Kim with teaching from Benkreia to include wherein the determining that the user completed the transaction comprises detecting, using a document object model (DOM), one or more elements on a webpage indicating that the user is performing the transaction. The modification would have been obvious, because it is merely applying a known technique (i.e., using DOM to detect completion of transaction) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., use existing technique to determine completion of transaction without human input to save time and manual labor).
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al. (KR 20220108415 A), in view of Mark et al. (Pub. No.: US 2011/0184853) and Ramesh et al. (Pub. No.: 2021/0304204) and Shachar et al. (Pub. No.: US 2023/0306429), and further in view of Bernard et al. (Pub. No.: US 2016/0260176).
As per claim 5, Kim does not teach verifying, based on performing a reverse-lookup of the user’s card number, the user and user information associated with the transaction.
Bernard teaches verifying, based on performing a reverse-lookup of the user’s card number, the user and user information associated with the transaction (see paragraph 0032, “POS system 1106 can be linked to a customer database that is able to look up the user’s email from other information provided by the user (e.g., a phone number, credit card number, loyalty-program membership number, etc.)”).
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify Kim with teaching from Bernard to include verifying, based on performing a reverse-lookup of the user’s card number, the user and user information associated with the transaction. The modification would have been obvious, because it is merely applying a known technique (i.e., performing reverse look up) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., retrieve other user information associated with user’s card number).
Claim(s) 21 and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al. (KR 20220108415 A), in view of Mark et al. (Pub. No.: US 2011/0184853) and Ramesh et al. (Pub. No.: 2021/0304204) and Shachar et al. (Pub. No.: US 2023/0306429), and further in view of Byrne et al. (Pub. No.: US 2020/0175517).
As per claim 21, Kim does not teach obtaining, via one or more application programing interfaces, the one or more data points associated with the transaction, wherein the one or more data points comprise weather conditions at a time and a location of the transaction.
Byrne teaches obtaining, via one or more application programing interfaces, the one or more data points associated with the transaction, wherein the one or more data points comprise weather conditions at a time and a location of the transaction (see paragraph 0016, “a process 100 for fraud detection…graph technology and underly store is used to capture data passed from transactional or operation system, or from a system such as a fraud detection solution…each time Albert or John purchase gas, the system captures the details of that transaction, such as the location and details of the gas station, the time of the transaction, the amount of gas purchased, and any other available data such as weather, related purchases, and so on…over the time, population of the graph in this way results in a time series history of behavior”)
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify Kim with teaching from Byrne to include obtaining, via one or more application programing interfaces, the one or more data points associated with the transaction, wherein the one or more data points comprise weather conditions at a time and a location of the transaction. The modification would have been obvious, because it is merely applying a known technique (i.e., obtaining additional data related to transaction) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., build a time series history of behavior over time).
As per claim 22, Kim does not teach obtaining, via the one or more application programming interfaces, the one or more data points associated with the transaction, wherein the one or more data points comprise a current event at a time and location of the transaction.
Byrne teaches obtaining, via the one or more application programming interfaces, the one or more data points associated with the transaction, wherein the one or more data points comprise a current event at a time and location of the transaction (see paragraph 0004, “A time series of graph data is captured, which corresponds to events occurring at different nodes in the graph”; see paragraph 0016, “a process 100 for fraud detection…graph technology and underly store is used to capture data passed from transactional or operation system, or from a system such as a fraud detection solution…each time Albert or John purchase gas, the system captures the details of that transaction, such as the location and details of the gas station, the time of the transaction, the amount of gas purchased, and any other available data such as weather, related purchases, and so on…over the time, population of the graph in this way results in a time series history of behavior”)
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify Kim with teaching from Byrne to include obtaining, via the one or more application programming interfaces, the one or more data points associated with the transaction, wherein the one or more data points comprise a current event at a time and location of the transaction. The modification would have been obvious, because it is merely applying a known technique (i.e., obtaining additional data related to transaction) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., build a time series history of behavior over time).
Claim(s) 10, 12-19 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim et al. (KR 20220108415 A), in view of Ramesh et al. (Pub. No.: 2021/0304204) and Shachar et al. (Pub. No.: US 2023/0306429).
As per claim 10, Kim teaches a computing device comprising:
one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the computing device to (see page 6, last two paragraphs):
send, based on a determination that a user completed a transaction, a request to generate a narrative for the transaction (see page 3, “The interface unit 10 is configured to obtain various information related to the used goods transaction between the transactions parties and provide it to the transaction detail generation unit 20”, “The transaction history generating unit 20 is configured to generate transaction details based on information through the interface unit 10”);
obtain, via one or more application programming interfaces, one or more data points associated with the transaction, wherein the one or more data points comprise at least one of: a location of the transaction, a day of the transaction, a time of the transaction, weather conditions at the time of the transaction, a total cost of the transaction, a price of one or more items associated with the transaction, or one or more products that were part of the transaction (see page 3, “The interface unit 10 is configured to obtain various information related to the used goods transaction between the transactions parties and provide it to the transaction detail generation unit 20”, “The transaction history generating unit 20 is configured to generate transaction details based on information through the interface unit 10”), one or more data points associated with the transaction (see page 4, “The transaction history generating unit 20 inputs sales text/purchase text and transaction agreement information, which is a conversational content, into a deep learning module learning model to be summarized”, “The summary contents that can be confirmed as a transaction may include the name of the product to be transacted, a description of the status of the product, a transaction method (direct transaction, courier transaction), transaction data, transaction amount, and the like”);
input the one or more data points into a generative artificial intelligence model (see page 4, “The transaction history generating unit 20 inputs sales text/purchase text and transaction agreement information, which is a conversational content, into a deep learning module learning model to be summarized…Here, the deep learning module learning module is based on TF-IDF (Term Frequency-Inverse Document Frequency), NLP (Natural Machine Learning) that extracts important paragraphs from documents, Seq2Seq (Sequence to Sequence), Transformers, BERT (Bidirectional Encoder Representations from) Transformers) and the like may be used”, “The summary contents that can be confirmed as a transaction may include the name of the product to be transacted, a description of the status of the product, a transaction method (direct transaction, courier transaction), transaction data, transaction amount, and the like”; the learning module is a generative artificial intelligence);
receive, from the generative artificial intelligence model and based on the one or more data points, a first narrative associated with the transaction (see page 3, “To this end, the transaction history generating unit 200 uses a pre-trained deep learning module learning model, and the deep learning module learning model generates transaction details by summarizing the information provided from the interface unit 100”; see page 4, “Here, the deep learning module learning module summarizes text-based documents into, for example, 2-3 lines of text”; summarizing transaction is the same as generating transaction narrative);
send, to a user device associated with the user, the first narrative (see page 3, “To this end, the transaction history generating unit 200 uses a pre-trained deep learning module learning model, and the deep learning module learning model generates transaction details by summarizing the information provided from the interface unit 100”; see page 4, “Here, the deep learning module learning module summarizes text-based documents into, for example, 2-3 lines of text”);
store, based on the approval, the first narrative in a database (see page 3, “In an embodiment of the present invention, a smart contract is automatically generated through deep learning for the confirmed contents, a transaction is generated, and the transaction is stored in a block of the block chain”).
Examiner notes, Kim does not teach receive, from the user device, an approval of the first narrative.
Ramesh teaches receive, from the user device, an approval of the first narrative (see paragraph 0025, “An agent may identify any false positives in the flagging of transaction as potentially prohibited…The flagged transactions may include a narrative displayable through alert review application 112;” see paragraph 0061, “narratives for flagged transactions are determined and output for review, such as to an agent associated with reporting prohibited transaction to a regulatory agency”; prior art teaches providing human feedback with regards to the correctness of the narrative).
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify Kim with teaching from Ramesh to include receive, from the user device, an approval of the first narrative. The modification would have been obvious, because it is merely applying a known technique (i.e., receiving a confirmation whether the flagged transaction is a false positive or not) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., determine whether narrative is correct).
Examiner further notes the combination of Kim and Ramesh does not teach sanitizing, from the one or more data points, personally identifiable information. According to paragraph 0046 of Applicant’s specification, sanitizing means encrypting, masking, or using other process of securing the one or more data points.
Shachar teaches sanitizing, from the one or more data points, personally identifiable information (see paragraph 0052 and 0054, “personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable”; see paragraph 0073 and 0077, “receive financial transactions of a preconfigured period, wherein data of each financial transaction of the financial-transactions comprises masked sensitive Personal Identifiable Information (PII) parameters”; see paragraph 0089, “four financial transactions in which four people, i.e., payors, sent their money to other four people, i.e., payees. Sensitive-PII, such as names were masked or obfuscated”; also see paragraph 0049).
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify combination of Kim and Ramesh with teaching from Shachar to include sanitizing, from the one or more data points, personally identifiable information. The modification would have been obvious, because it is merely applying a known technique (i.e., sanitizing, from the one or more data points, personally identifiable information) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., enhance privacy and comply with laws).
Claim 11 is canceled.
Claim 12 is rejected for the same reason as claim 1.
Claim 13 is rejected for the same reason as claim 3.
Claim 14 is rejected for the same reason as claim 4.
Claim 15 is rejected for the same reason as claim 7 and 8.
Claim 16 is rejected for the same reason as claim 10.
Claim 17 is rejected for the same reason as claim 1.
Claim 18 is rejected for the same reason as claim 3.
Claim 19 is rejected for the same reason as claim 4.
Claim 20 is canceled.
As per claim 23, Kim does not teach sanitizing the personally identifiable information comprises removing the personally identifiable information from the one or more data points using a data sanitization process.
Shachar teaches sanitizing the personally identifiable information comprises removing the personally identifiable information from the one or more data points using a data sanitization process (see paragraph 0052, “data anonymization seeks to protect private or sensitive data by deleting or encrypting PII parameters from a database”; see 0054, “personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable”; see paragraph 0073 and 0077, “receive financial transactions of a preconfigured period, wherein data of each financial transaction of the financial-transactions comprises masked sensitive Personal Identifiable Information (PII) parameters”; see paragraph 0089, “four financial transactions in which four people, i.e., payors, sent their money to other four people, i.e., payees. Sensitive-PII, such as names were masked or obfuscated”; also see paragraph 0049).
It would have been obvious to one of ordinary skill in the art at the filing date of the present application to modify Kim with teaching from Shachar to include sanitizing the personally identifiable information comprises removing the personally identifiable information from the one or more data points using a data sanitization process. The modification would have been obvious, because it is merely applying a known technique (i.e., removing the personally identifiable information from the one or more data points using a data sanitization process) to a known method (i.e., generating narrative for transactions) ready to provide predictable result (i.e., enhance privacy and comply with laws).
Response to Remarks
In the response filed on 01/27/2026, Applicant amended the independent claims by removing some limitations and also adding a new feature – “sanitizing, from the one or more data points, personally identifiable information”. Examiner points out that sanitizing PII, or encrypting/masking/obscuring PII, was not only a well-known feature prior to the present invention, it is required by law in certain countries. The amended claims do not specify the data sanitizing technique, and there were already available and well-known techniques.
Rejection under 35 U.S.C. 101
Applicant's arguments filed on 01/27/2026 with regards to rejection under 35 U.S.C. 101 have been fully considered but they are not persuasive.
Applicant argued that “the human mind is not equipped to obtain data points via application programming interface, sanitize personally identifiable information from those data points, or input the sanitized data points into a generative artificial intelligence model to generate narratives”. Examiner disagrees. First, obtaining data via an API is merely an extra-solution utilizing existing data exchange protocols. Human could obtain the same data via paper form or using any basic communication tools prior to computer. The recitation of API merely amounts to implementing an abstract concept in a computer environment. Second, the present claims are not solely rejected under “Mental Processes” grouping. They are also rejected under “Certain Methods of Organizing Human Activities”. Third, the claim language does not specify any data sanitization technique, and as such, it reads on all the pre-computer era techniques for masking/obscuring sensitive information. Fourth, inputting data into a generative AI without specifying improvement to the AI is not sufficient to overcome rejection under 35 U.S.C. 101, according to the Recentive v. Fox decision.
Applicant then argued the present claims “include technical details directed to improving data security when processing transaction data using generative AI models”. Examiner disagrees and points out that the only limitation related to data security is the amended feature - “sanitizing, from the one or more data points, personally identifiable information”. As discussed earlier, neither the claim language nor the specification specifies the data sanitization technique. Sanitizing data in financial industry was not only well-known, it is required by law in certain countries. This feature is recited in high level of generality, and as such, it is not sufficient to improve computer function.
Applicant further argued that unlike the claims in Recentive Analytics, the present claims “recite specific data security operations (e.g., sanitizing, from the one or more data points, personally identifiable information) performed before the data is input into the generative AI model. Examiner disagrees and points out that masking sensitive PII prior to feeding data into AI was a well-known practice. For example, Shachar et al. (Pub. No.: US 2023/0306429) teaches this limitation (see paragraph 0052 and 0054, “personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable”; see paragraph 0073 and 0077, “receive financial transactions of a preconfigured period, wherein data of each financial transaction of the financial-transactions comprises masked sensitive Personal Identifiable Information (PII) parameters”; see paragraph 0089, “four financial transactions in which four people, i.e., payors, sent their money to other four people, i.e., payees. Sensitive-PII, such as names were masked or obfuscated”; also see paragraph 0049). Sanitizing data without even specifying specific technique is insufficient to indicate improvement in computer or AI technology.
Finally, Applicant argued that like the claims in BASCOM, the current claims include elements that clearly operate in an unconventional and non-generic method, resulting in the technical improvement discussed above. Examiner disagrees. The BASCOM court ruled that an inventive concept may be found in the non-conventional and non-generic arrangement of the additional elements, i.e. the installation of a filtering tool at a specific location, remote from the end-users, with customizable filtering features specific to each end user. In this case, the additional elements – a computing device and a user device – are not in unconventional arrangement. The claim language requires any specific and unconventional connection between the devices. The specification discloses typical data transmission protocols, “such as TCP/IP, Ethernet, FTP, HTTP and the like”. Therefore, the BASCOM rationale does not apply to the present claims.
For these reasons, the amended claims do not recite limitations that are sufficient to overcome rejection under 35 U.S.C. 101. Examiner maintains the ground of rejection.
Rejection under 35 U.S.C. 103
Examiner cites a new prior art, Shachar et al. (Pub. No.: US 2023/0306429), to address the amended feature. Updated rejection is provided in this Office Action.
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 HAO FU whose telephone number is (571)270-3441. The examiner can normally be reached 9:00 AM - 6:00 PM PST.
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, Christine M Behncke can be reached at (571) 272-8103. 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.
/HAO FU/Primary Examiner, Art Unit 3695
FEB-2026