Prosecution Insights
Last updated: July 17, 2026
Application No. 18/800,960

DETECTING AN ANOMALOUS ACTIVITY IN A TRANSACTION DATA STRUCTURE

Final Rejection §103
Filed
Aug 12, 2024
Examiner
PHAN, NICHOLAS K
Art Unit
3699
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
American Express Travel Related Services Company, Inc.
OA Round
2 (Final)
52%
Grant Probability
Moderate
3-4
OA Rounds
1y 4m
Est. Remaining
71%
With Interview

Examiner Intelligence

Grants 52% of resolved cases
52%
Career Allowance Rate
69 granted / 134 resolved
-0.5% vs TC avg
Strong +20% interview lift
Without
With
+19.8%
Interview Lift
resolved cases with interview
Typical timeline
3y 3m
Avg Prosecution
23 currently pending
Career history
177
Total Applications
across all art units

Statute-Specific Performance

§101
16.4%
-23.6% vs TC avg
§103
79.4%
+39.4% vs TC avg
§102
3.1%
-36.9% vs TC avg
§112
0.9%
-39.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 134 resolved cases

Office Action

§103
DETAILED ACTION Status of Claims Claims 1, 10, and 19-20 have been amended. Claims 1-20 are currently pending and have been considered by the examiner. 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 . Response to Arguments 112b Rejection: Applicant’s arguments have been considered and have been deemed persuasive by the examiner. Thus, the previously issued 112(b) rejection has been rescinded. Prior Art Rejection: Applicant asserts that the prior art of record fails to explicitly disclose the newly amended claim limitations. The examiner respectfully disagrees based upon the rationale provided in the following prior art rejection. 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. Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pei et al. (US 20220318898 A1) in view of Pei et al. (US 20220318925 A1), hereinafter simply referred to as Pei 2. Regarding Claims 1, 10 and 19, Pei discloses: A computer implemented method, comprising: acquiring, by at least one processor, merchant category data and a plurality of authorized transactions associated with a payment card (See Pei: Para. [0045] – “At Step 202, a transaction record is received. The transaction record may be received by a server application in response to a request from a client device for the transaction record.”; See Pei: Para. [0115] – “The column (314) displays account data from a category field of a transaction record”); training, using the at least one processor, an embedding model (See Pei: Para. [0035] – “The server application (102) includes a transaction model (132), an account embedding model (144), and a match model (152)”) using the merchant category data, wherein the embedding model receives an input merchant category for a transaction and generates a sentence embedding for the input merchant category (See Pei: Para. [0096] – “In one embodiment, the training input A (172) may be name data (from FIG. 1B) that is used for training purposes (e.g., an opposing party name) and the expected output may be a different opposing party name from the sentence created by the training application (103). The training data for the name embedding model (133) may include name data for transactions from multiple entities for which the system (100) (shown in FIG. 1A) is used.”); wherein a merchant category corresponds to a type of a merchant with which the transaction is conducted (The examiner has determined that the aforementioned claim limitation constitutes a recitation of nonfunctional descriptive material. Specifically, the claim limitation merely describes what type of data the merchant category is without functionally limiting the claimed step of training an embedding model. Thus, as the limitation imparts not functional limitation on the claimed step of training, the examiner must assert it is nonfunctional descriptive material and thus the limitation cannot be given patentable weight. See MPEP 2114. However, for purposes of compact prosecution, the examiner cites the following: See Pei: Para. [0026-0027] – “Transactions are stored as transaction records. A transaction record includes data describing a transaction. A transaction record is a text string describing a financial transaction. In one embodiment, a transaction record is for a commercial transaction and includes a name of an opposing party to the transaction, an amount of the transaction, a date of the transaction (which may include a time), and a description of the transaction. The opposing party to the transaction (i.e., opposing party) is at least one other party with which the entity performs the transaction. As such, the opposing party may be the payor or payee depending on whether the transaction is an income (i.e., involves payment to the entity) or an expense (i.e., involves the entity making payment). The description may include the name of the opposing party. The account data (108) is data for the accounts of the multiple entities that use the system (100). An account may be a bookkeeping account that tracks credits and debits for a corresponding entity. Each entity may have a chart of accounts. The term, chart of accounts, corresponds to the standard definition used in the art to refer to the financial accounts in the general ledger of an entity. The chart of accounts is a listing of accounts that are used by the entity. Different accounts may have different tax implications and accounting implications.” – Pei discloses storing transaction records which record data describing a transaction, including the name of the opposing party which can be considered, to one of ordinary skill in the art, functionally analogous to the BRI of the claimed “merchant” (i.e.) an entity involved in performing a transaction with another entity). Thus, the examiner asserts that the name of the merchant constitutes a “type” of merchant given the BRI of claimed term and thus that Pei disclose the BRI of the aforementioned claim limitation.) training, using the at least one processor, an autoencoder (See Pei: Para. [0067] – “The account embedding model (144) generates the account vectors (145) from the account identifiers (142). The account identifiers (142) uniquely identify the accounts of a chart of accounts of an entity. In one embodiment, the account embedding model (144) is an autoencoder that generates the account vector”) using the plurality of authorized transactions, wherein the autoencoder receives transaction data for the transaction and generates a similarity score for the transaction compared to the plurality of authorized transactions (See Pei: Para. [0071] – “The combination of the similarity function (148) and the match model (152) achieves the following in one or more embodiments. The transaction vector (140) and account vector (146) are in the same vector space. Thus, the similarity function (148) may be used to identify approximate matches”; See: Pei: Para. [0103] – “Similar transactions are collected, whereby similarity means satisfying the following conditions: (i) from the same user, (ii) associated with the same account category, and (iii) occurring within 6 months of each other”); and generating, using the at least one processor, a trained machine learning model that is configured to generate transaction scores, wherein the trained machine learning model comprises the trained embedding model and the trained autoencoder (See Pei: Para. [0070] – “The match model (152) generates the match score (160) from the transaction vector (140) and the account vector (146).”). Pei fails to explicitly disclose: flag transaction based on the transaction scores. However, in a similar field of endeavor, Pei 2 discloses: flag transaction based on the transaction scores (See Pei 2: Para. [0151] – “For example, one or more embodiments may determine whether A>B, A=B, A !=B, A<B, etc. The comparison may be performed by submitting A, B, and an opcode specifying an operation related to the comparison into an arithmetic logic unit (ALU) (i.e., circuitry that performs arithmetic and/or bitwise logical operations on the two data values). The ALU outputs the numerical result of the operation and/or one or more status flags related to the numerical result. For example, the status flags may indicate whether the numerical result is a positive number, a negative number, zero, etc. By selecting the proper opcode and then reading the numerical results and/or status flags, the comparison may be executed.”). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to implement the transaction flagging based on transaction score by a trained model functionality disclosed by Pei 2 into the trained model of Pei yielding the predictable result of an increase in the security strength of the invention by flagging suspicious transactions. Regarding Claims 2, 11, and 20, the combination discloses: wherein the merchant category data comprises a plurality of super categories, the method further comprising: acquiring the transaction data associated with a plurality of transactions (See Pei: Para. [0045] – “At Step 202, a transaction record is received. The transaction record may be received by a server application in response to a request from a client device for the transaction record.”; See Pei: Para. [0115] – “The column (314) displays account data from a category field of a transaction record”); determining, using the trained machine learning model, the similarity score between a category of the transaction of the plurality of transactions and the plurality of super categories ;determining a risk score based on the similarity scores using a stored vector comprising risk scores associated with each super category of the plurality of super categories (See Pei: Para. [0071] – “The combination of the similarity function (148) and the match model (152) achieves the following in one or more embodiments. The transaction vector (140) and account vector (146) are in the same vector space. Thus, the similarity function (148) may be used to identify approximate matches”; See: Pei: Para. [0103] – “Similar transactions are collected, whereby similarity means satisfying the following conditions: (i) from the same user, (ii) associated with the same account category, and (iii) occurring within 6 months of each other”); determining the transaction score based on at least the risk score (See Pei: Para. [0070] – “The match model (152) generates the match score (160) from the transaction vector (140) and the account vector (146).”); and in response to determining that the transaction score is out of range, flagging the transaction (See Pei 2: Para. [0151] – “For example, one or more embodiments may determine whether A>B, A=B, A !=B, A<B, etc. The comparison may be performed by submitting A, B, and an opcode specifying an operation related to the comparison into an arithmetic logic unit (ALU) (i.e., circuitry that performs arithmetic and/or bitwise logical operations on the two data values). The ALU outputs the numerical result of the operation and/or one or more status flags related to the numerical result. For example, the status flags may indicate whether the numerical result is a positive number, a negative number, zero, etc. By selecting the proper opcode and then reading the numerical results and/or status flags, the comparison may be executed.”). Regarding Claims 3 and 12, the combination discloses: further comprising: determining an out of pattern index for the transaction; and determining the transaction score as a function of at least the risk score and the out of pattern index (See Pei: Para. [0041] – “The element-wise product encourages a behavior in which positively associated pairs of transactions and categories are embedded to similar locations, and negatively associated pairs are embedded far away from each other. The shared vector space for the transaction and account vectors further allows layers in each of the models to explore patterns and structure.”). Regarding Claims 4 and 13, the combination discloses: wherein the determining the out of pattern index further comprises: determining, using the autoencoder, the similarity score between the transaction and the plurality of authorized transactions, wherein the plurality of authorized transactions and the transaction are associated with a same account (See Pei: Para. [0071] – “The combination of the similarity function (148) and the match model (152) achieves the following in one or more embodiments. The transaction vector (140) and account vector (146) are in the same vector space. Thus, the similarity function (148) may be used to identify approximate matches”; See: Pei: Para. [0103] – “Similar transactions are collected, whereby similarity means satisfying the following conditions: (i) from the same user, (ii) associated with the same account category, and (iii) occurring within 6 months of each other”); and determining the out of pattern index as a function of the similarity score (See Pei: Para. [0041] – “The element-wise product encourages a behavior in which positively associated pairs of transactions and categories are embedded to similar locations, and negatively associated pairs are embedded far away from each other. The shared vector space for the transaction and account vectors further allows layers in each of the models to explore patterns and structure.”). Regarding Claims 5 and 14, the combination discloses: further comprising: inputting a set of features into to the trained machine learning model, wherein the set of features comprises at least the category of the transaction (See Pei: Para. [0052] – “As shown in FIG. 1B, the server application (102) takes, as input, the transaction records (120) and the account identifiers (143). A transaction cycler (122) receives the transaction record. The transaction cycler (122) selects the transaction record (121) from the transaction records (120) as an input for the extractor (124). The transaction cycler (122) may iterate through the transaction records (120) in an order determined from the transaction records (120). For example, the order may be a date order, an amount order (e.g., largest to smallest), an alphabetical order (e.g., of the description or name), etc”). Regarding Claims 6 and 15, the combination discloses: wherein determining the risk score further comprises: generating a vector representation of the category and the super categories based on a determined similarity to one another (See Pei: Para. [0071] – “The combination of the similarity function (148) and the match model (152) achieves the following in one or more embodiments. The transaction vector (140) and account vector (146) are in the same vector space. Thus, the similarity function (148) may be used to identify approximate matches”; See: Pei: Para. [0103] – “Similar transactions are collected, whereby similarity means satisfying the following conditions: (i) from the same user, (ii) associated with the same account category, and (iii) occurring within 6 months of each other”). Regarding Claims 7 and 16, the combination discloses: wherein the transaction score is further based on a transaction value and a recency of the transaction (See Pei: Para. [0056] – “The transaction data (127) includes data from the transaction record (121) that is not part of the name data (125) and the name metadata (126). In one embodiment, the transaction data (127) includes the date (and time) of the transaction, the amount of the transaction, etc., and may be normalized by the extractor (124) for input to the transaction model (132).”). Regarding Claims 8 and 17, the combination discloses: wherein the embedding model comprises a sentence transformers model (See Pei: Para. [0096] – “An iterative backpropagation process is used to minimize the objective function. In one embodiment, the name embedding model (133) is trained using a modified word2vec algorithm. Instead of learning word associations using sentences, the training application (103) for the name embedding model (133) creates “sentences” from groups of opposing party names from transactions that have been assigned to the same account identifier”). Regarding Claims 9 and 18, the combination discloses: further comprising: retraining the sentence transformers model using a data set, wherein the data set comprises transaction categories from different classification systems (See Pei: Para. [0103] – “Similar transactions are collected, whereby similarity means satisfying the following conditions: (i) from the same user, (ii) associated with the same account category, and (iii) occurring within 6 months of each other. Collating the words from the collection of similar transactions produces a sentence. For example, the names of different companies in home improvement and building supply businesses may be combined together to form a sentence. As another example, the names of restaurants and food delivery companies may be combined to form another sentence for meal related collections. From the sentences, word2vec may use a shallow neural network to learn a word embedding such that words in the same context are embedded close by locations.”). 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 NICHOLAS K PHAN whose telephone number is (571)272-6748. The examiner can normally be reached M-F 1 pm-9 pm EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel can be reached at 571-270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /NICHOLAS K PHAN/Examiner, Art Unit 3699
Read full office action

Prosecution Timeline

Aug 12, 2024
Application Filed
Oct 01, 2025
Non-Final Rejection mailed — §103
Jan 02, 2026
Response Filed
May 27, 2026
Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12664539
GENERATING AND MANAGING TOKENIZED ASSETS UTILIZING BLOCKCHAIN MINTING AND A DIGITAL PASSPORT
4y 0m to grant Granted Jun 23, 2026
Patent 12530679
PERFORMING BILATERAL NEGOTIATIONS ON A BLOCKCHAIN
7y 4m to grant Granted Jan 20, 2026
Patent 12530686
DIRECT TRANSACTION DATA ENTRY CODING AND INTEGRATION
3y 11m to grant Granted Jan 20, 2026
Patent 12437301
REAL-TIME UPDATING OF A SECURITY MODEL
4y 9m to grant Granted Oct 07, 2025
Patent 12386989
SYSTEMS AND METHODS FOR BLOCKCHAIN-BASED PAYMENTS
3y 6m to grant Granted Aug 12, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
52%
Grant Probability
71%
With Interview (+19.8%)
3y 3m (~1y 4m remaining)
Median Time to Grant
Moderate
PTA Risk
Based on 134 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month