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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 4/21/26 has been entered.
Response to Arguments
In light of amendments, the examiner is using new citations to maintain art rejection. Please see 103 section below.
In light of the amendments, the examiner maintains the 101 rejections.
On page 10 the Applicant argues “it would not have been obvious to incorporate the item-identifying information of Griffith in the payment token or corresponding token legend of Nagasundaram. Further, even assuming arguendo that one were to incorporate the item-identifying information of Griffith into the payment token and/or token legend of Nagasundaram, the remaining aspects of the proposed combination would not have been obvious.” The examiner draws the Applicant’ attention to Fig. 5 of Nagasundaram:
PNG
media_image1.png
376
476
media_image1.png
Greyscale
The citation from Nagasundaram ¶[0152] states “The token translation module 133 may comprise code which can be used by the processor to update the transaction token 510 to translate a data field 512 into a new updated data field 522 based on the contextual information interpreted by the token interpretation module 131.” Here it is obvious that contextual information which includes identifying merchant information is incorporated, and that the data is updated. The examiner therefore respectfully disagrees with the argument.
On page 11 the applicant states “claims require ‘…deterministically identify the entity ... based on the probabilistic confidence indicator.’ But the ‘probabilistic confidence indicator’ of the Action's proposed combination is a likelihood that a payment account was automatically selected correctly for the identified item of Griffith, and the automatically selected payment account is mapped to Applicant's recited ‘entity’…” First Neuenschwander is used for inputting the entity feedback data to the entity service and no validation is required for that. Second, the argument. Second, Nagasundaram is exclusively used for the entity identification deterministically. In the mapping the examiner has mapped the token issuer as the entity and Nagasundaram in ¶ [0148] states “The token legend 134 may indicate the payment network associated with the identifier comprising "40" corresponds to payment processor "A," and the token issuer associated with the token issuer identifier "01" corresponds to token issuer.” The examiner therefore respectfully disagrees with the argument
Regarding 101, on page 12 the applicant states “Examples of claims that do not recite mental processes because they cannot be practically performed in the human mind include:” The cited examples are not used in the claim language and are not technical similar to the current application. On page 13 the applicant further state “The claims integrate any alleged judicial exception into a practical application” The claim language and the rejection in the 101 section below states that the limitations as written do not impose any meaningful limitation on the abstract idea and therefore do not integrate the abstract idea into a practical application. ANN are not recited in the claim language in claim 3, and if amended to include explicit training of a neural network, examiner can remove the 101 for claim 3.
Claim Rejections - 35 USC § 101
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter without significantly more. The claims as whole, considering all claim elements both individually and in combination, do not amount to significantly more than an abstract idea.
Independent claims 1, 8 and 15 recite “inputting unstructured transaction data corresponding to a financial transaction to a natural language processor (NLP) to generate NLP output comprising a portion of the unstructured transaction data that includes identifying information for a merchant participant in the financial transaction; inputting the NLP output to an entity service; inputting entity feedback data to the entity service; based on the NLP output and the entity feedback data, generating a probabilistic confidence indicator via the entity service, the probabilistic confidence indicator meeting or exceeding a threshold for standardized matching of an entity to the financial transaction; and based on the probabilistic confidence indicator: (i) associating the entity with one or more of the financial transaction and the NLP output in an entity identification database, and (ii) configuring a feed-forward lookup table to deterministically identify the entity in connection with a second financial transaction based on the NLP output, the configuration including - generating token mappings between the entity and one or both of: (a) unstructured data relating to the financial transaction or (b) the NLP output, updating the feed-forward lookup table to include the token mappings, the feed- forward lookup table being configured to match token mappings against unstructured financial transaction data and provide resultant outputs directly or indirectly to the entity service.”
The bolded limitations as drafted cover a mental process when a human receives encoded financial transaction that includes the name of the merchant scribbled on a paper, that also lists possible banks that t could correspond to, reads the transaction to a second human who lookups in a table in his notebook that the coded transaction refers to one of the banks is above a threshold of .5 and says “with high probability this transaction is for Bank of America”, the human then adds Bank of America to his notebook table and matches the second transaction to the same bank.
This judicial exception is not integrated into a practical application. In particular claim 1. 8 and 15 recites additional element of processor, which is a form of generic computer equipment. In the as-filed Specifications ¶0062] recite The first processor214 may comprise suitable logic, circuitry, and interfaces that may be configured to determine an executable operation of the exemplary electronic device202 based on executable instructions stored in the first memory206 or commands provided by the user. The first processor214 may be configured to sense, extract, and detect, collect data and/or receive speech signals for a data analysis and machine learning operation, through the sensing unit216 and the input unit218 in the exemplary electronic device202. Accordingly, the first processor214 may collect information for processing, storing in the first memory206 or transmitting to the external devices, such as the CMS110, a remote server, or another electronic device. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
The additional elements of NLP, due to a lack of specificity are considered as general-purpose elements and as such do not integrate the abstract idea into a practical application as they do not impose any meaningful limitation on practicing the abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional element of using a computer is noted as a general computer. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claims are not patent eligible.
Claims 2, 9 and 16 recite wherein the NLP output is associated with the entity in the entity identification database. This amounts to the human finding the bank in his notebook table. No additional limitations are present.
Claims 3, 10 and 17 recite further comprising, based on the probabilistic confidence indicator and via the one or more transceivers and/or processors, retraining the NLP using the NLP output for generation of additional NLP output corresponding to a third financial transaction. This amounts to the human looking at another transaction and verifying that the bank is found in the database in notebook. Retraining is mapped to mathematical operations to achieve desired results. No additional limitations are present.
Claims 4, 11 and 18 recite wherein the entity feedback data comprises a recurring transaction indicator for whether the financial transaction is part of an installment payment plan. This amounts to the note having an asterisk on it to indicate it refers to a recurring transaction.
Claim 5, 12 and 19 recite wherein the entity feedback data comprises input from an account holder corresponding to the financial transaction, the input from the account holder relating the entity to one or both of the NLP output and the financial transaction. This amounts to the human receiving on the note in addition to the financial information possible bank names. No additional limitations are present.
Claims 6, 13 and 20, recite wherein the entity feedback data comprises merchant metadata for a plurality of merchants, the plurality of merchants including the entity. This amounts to the human receiving on the note in addition to the financial information possible bank names. No additional limitations are present.
Claims 7 and 14 recite wherein the entity is a merchant, further comprising analyzing, via the one or more transceivers and/or processors, the entity feedback data to identify a pattern of behavior of the merchant and adjusting the probabilistic confidence indicator by increasing confidence with respect to the merchant based on the pattern. This amounts to the human receiving on the note of a transaction with a restaurant on which is written “great service”, and the human updates the table in his notebook to indicate a confidence of .8 with that restaurant. No additional limitations are present.
Claim Rejections - 35 USC § 103
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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 5-6 8-10, 12-13, 15-17, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Griffith (US 20200005270 A1) in further view of Neuenschwander (US 20220005063 A1) and Nagasundaram (US 20250225515 A1).
With respect to claims 1 8 and 15, Griffith teaches
(Claim 1) A computer-implemented method for entity standardization comprising, via one or more transceivers and/or processors (Griffith ¶[0005] In an aspect of the invention, a system includes: a processor, a computer readable memory and a computer readable storage medium associated with a computing device; program instructions to receive transaction information for a transaction, wherein the transaction information identifies one or more items in the transaction and a user profile; program instructions to apply natural language (NLC) and machine learning techniques):
(Claim 8) A system for entity standardization, the system comprising one or more processors individually or collectively programmed to (Griffith ¶[0005] In an aspect of the invention, a system includes: a processor, a computer readable memory and a computer readable storage medium associated with a computing device; program instructions to receive transaction information for a transaction, wherein the transaction information identifies one or more items in the transaction and a user profile; program instructions to apply natural language (NLC) and machine learning techniques):
(Claim 15) A non-transitory computer-readable storage media having computer-executable instructions for entity standardization stored thereon, wherein when executed by at least one processor the computer-executable instructions cause the at least one processor to (Griffith ¶[0005] In an aspect of the invention, a system includes: a processor, a computer readable memory and a computer readable storage medium associated with a computing device; program instructions to receive transaction information for a transaction, wherein the transaction information identifies one or more items in the transaction and a user profile; program instructions to apply natural language (NLC) and machine learning techniques):
inputting unstructured transaction data corresponding to a financial transaction to a natural language processor (NLP) to generate NLP output comprising a portion of the unstructured transaction data that includes identifying information for a merchant participant in the financial transaction (Griffith ¶[0005] In an aspect of the invention, a system includes: a processor, a computer readable memory and a computer readable storage medium associated with a computing device; program instructions to receive transaction information for a transaction, wherein the transaction information identifies one or more items in the transaction and a user profile; program instructions to apply natural language (NLC) and machine learning techniques to classify each of the one or more items based on the user profile and contextual information, ¶[0014] For example, contextual information may include transaction location, transaction merchant information (e.g., merchant name, merchant type, etc.), user calendar information, user intent, user historical payment selection choices, etc. In this way, the determination of which account to charge may be personalized and adjusted over time as a user's account selection habits are tracked and learned.);
based on the NLP output and the entity feedback data, generating a probabilistic confidence indicator via the entity service, the probabilistic confidence indicator meeting or exceeding a threshold for standardized matching of an entity to the financial transaction (Griffith ¶[0084] Process 600 may also include prompting the user to confirm or modify account selections when the confidence score is below a threshold (step 640). For example, the payment processing system 215 may present account selections based on the accounts with the highest confidence scores for each item. The payment processing system 215 may prompt the user to confirm or modify the selected accounts to charge (e.g., the accounts with the highest confidence scores). If the user modifies or overrides an account selection, the payment processing system 215 may save the information identifying the override to refine the confidence scoring algorithm for future use. In embodiments, the payment processing system 215 may only prompt the user to confirm or modify a selected payment account [entity] when the confidence score does not satisfy a threshold (e.g., is below the threshold). That is, step 640 may be omitted entirely if the confidence scores for the selected payment accounts for all items in the transactions satisfy the threshold.); and
based on the probabilistic confidence indicator: (i) associating the entity with one or more of the financial transaction and the NLP output in an entity identification database (Griffith ¶[0084] Process 600 may also include prompting the user to confirm or modify account selections when the confidence score is below a threshold (step 640). For example, the payment processing system 215 may present account selections based on the accounts with the highest confidence scores for each item. The payment processing system 215 may prompt the user to confirm or modify the selected accounts to charge (e.g., the accounts with the highest confidence scores). If the user modifies or overrides an account selection, the payment processing system 215 may save the information identifying the override to refine the confidence scoring algorithm for future use. In embodiments, the payment processing system 215 may only prompt the user to confirm or modify a selected payment account [entity] when the confidence score does not satisfy a threshold (e.g., is below the threshold). That is, step 640 may be omitted entirely if the confidence scores for the selected payment accounts for all items in the transactions satisfy the threshold.)
Griffith does not explicitly disclose however Neuenschwander teaches inputting the NLP output to an entity service (Neuenschwander ¶ Claim 1. a database for receiving authorization data from the financial institution computer system, the authorization data including data associated with transactions made by the selected consumer with a plurality of merchants, each record of the authorization data including at least a field identifying the selected consumer [entity feedback data] and a field containing raw data [unstructured data ]corresponding to an associated transaction; a merchant identification system [entity service] coupled to the database, for identifying from the raw data of each record of the authorization data a selected merchant involved [entity identified] with the associated transaction with the selected consumer; an aggregator system for receiving the identified selected merchant from the merchant identified system);
inputting entity feedback data to the entity service (Neuenschwander ¶ Claim 1. a database for receiving authorization data from the financial institution computer system, the authorization data including data associated with transactions made by the selected consumer with a plurality of merchants, each record of the authorization data including at least a field identifying the selected consumer [entity feedback data] and a field containing raw data [unstructured]corresponding to an associated transaction; a merchant identification system [entity service] coupled to the database, for identifying from the raw data of each record of the authorization data a selected merchant involved [entity identified] with the associated transaction with the selected consumer; an aggregator system for receiving the identified selected merchant from the merchant identified system);
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify NLP system of Griffith to include the entity determination of Neuenschwander in order to validate merchants and business entities with unstructured data.
None of Griffith and Neuenschwander explicitly disclose however Nagasundaram teaches (ii) configuring a feed-forward lookup table to deterministically identify the entity in connection with a second financial transaction based on the NLP output, the configuration including - generating token mappings between the entity and one or both of: (a) unstructured data relating to the financial transaction or (b) the NLP output, updating the feed-forward lookup table to include the token mappings, the feed- forward lookup table being configured to match token mappings against unstructured financial transaction data and provide resultant outputs directly or indirectly to the entity service (Nagasundaram ¶ [0148] Any other suitable method for determining the token legend may be used as well including many fewer or more digits, information included in a message instead of the transaction token, etc. Accordingly, the token interpretation module may obtain the appropriate token format and may parse the transaction token into relevant data fields identified by the token legend. Here, for example, the first four digits of the transaction token may include a payment network identifier of 2 digits ("40") and the token issuer [entity] identifier of 2 digits ("01"). Thus, the token interpretation module may use the determined token legend to serve as a lookup table which the token interpretation module can utilize to interpret information stored within the transaction token format. The token legend 134 may indicate the payment network associated with the identifier comprising "40" corresponds to payment processor "A," and the token issuer associated with the token issuer identifier "01" corresponds to token issuer "T." Thus, the transaction token may use the token legend 134 to interpret the transaction token as being issued by token issuer T and being associated with payment network A. Thus, the merchant computer may determine contextual information about a transaction token without querying a third party token vault or other central transaction entity.)
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify NLP system of Griffith in view of the entity determination of Neuenschwander to include lookup of Nagasundaram in order to increase the security of a transaction ([0045], Nagasundaram)
With respect to claims 2, 9 and 16 Neuenschwander further teaches wherein the NLP output is associated with the entity in the entity identification database (Neuenschwander ¶ [0130] According to one embodiment, upon receiving the de-identified transactions, the OPS transmits all un-identified “raw” merchant names (i.e., those that cannot be recognized within the OPS's current database) to the OMS 211 in order to be “cleansed,” categorized, and validated via a merchant identification process. Those merchant names that are successfully associated with an existing validated merchant are returned to the respective OPS and subsequently stored within the OPS. Alternatively, the process of Predict Merchant Model (14113) may be applied as explained below.)
With respect to claims 3, 10 and 17 Griffith further teaches further comprising, based on the probabilistic confidence indicator and via the one or more transceivers and/or processors, retraining the NLP using the NLP output for generation of additional NLP output corresponding to a third financial transaction (Griffith ¶[0068] This “override” feature sends information identifying manually selected accounts back into learning model and training data set such that the payment processing system 215 may update its classification algorithms to more accurately classify this item (and related items) in the future. In this way, the payment processing system 215 “learns” correct classifications for items over time and improves its accuracy. In embodiments, the payment processing system 215 learns for the individual user specifically and not as a coarse grain classification whereby “printer paper” should appropriately be charged to a company card. ¶[0076] In embodiments, the payment processing system 215 may store account scoring criteria that defines weightings and scoring parameters/techniques for scoring payment accounts based on classification information for an item, contextual information, training data, user profile information, etc. As described herein, the criteria may be periodically updated based on machine learning techniques in which the scoring criteria is refined as user habits are learned or change over time. Additionally, or alternatively, the payment processing system 215 may store training data, such as historical account payment selection data. The payment processing system 215 may implement a contextual analyzer to analyze and factor in contextual data into the scoring of payment accounts.)
With respect to claim 5, 12 and 19 , Griffith teaches wherein the entity feedback data comprises input from an account holder corresponding to the financial transaction, the input from the account holder relating the entity to one or both of the NLP output and the financial transaction (Griffith ¶[0084] Process 600 may also include prompting the user to confirm or modify account selections when the confidence score is below a threshold (step 640). For example, the payment processing system 215 may present account selections based on the accounts with the highest confidence scores for each item. The payment processing system 215 may prompt the user to confirm or modify the selected accounts to charge (e.g., the accounts with the highest confidence scores). If the user modifies or overrides an account selection, the payment processing system 215 may save the information identifying the override to refine the confidence scoring algorithm for future use. In embodiments, the payment processing system 215 may only prompt the user to confirm or modify a selected payment account when the confidence score does not satisfy a threshold (e.g., is below the threshold). That is, step 640 may be omitted entirely if the confidence scores for the selected payment accounts for all items in the transactions satisfy the threshold.).
With respect to claims 6, 13 and 20, Neuenschwander further teaches wherein the entity feedback data comprises merchant metadata for a plurality of merchants, the plurality of merchants including the entity (Neuenschwander ¶[0066] Merchant Identification Table: a data table or file in the TMS associating information relating to unidentified merchant names which have been analyzed via the merchant identification process and associated with known or validated merchants recognized by the TMS, including but not limited to: an unidentified merchant key, an unidentified merchant name, a validated merchant key, a validated merchant name, a merchant category, an identity assurance rating, etc.).
Claims 4, 11 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Griffith , Neuenschwander, Nagasundaram in further view of Dotter (US 20200074565 A1).
With respect to claims 4, 11 and 18 Griffith, Neuenschwander and Nagasundaram don’t explicitly disclose however, Dotter teaches wherein the entity feedback data comprises a recurring transaction indicator for whether the financial transaction is part of an installment payment plan (Dotter ¶[0055] For example, different occurrences of a repeating transaction may be associated with the same service provider 108, website, and/or other entity; may occur on or around the same time, periodically (e.g., at or around the same time each day; on the same day and/or within a few days each week, month, quarter, year, or other time period; or the like); may be associated with the same or similar (e.g., within a predefined percentage or amount) transaction amount; and/or have one or more other similarities. An enterprise transaction module 104 may be configured to select one or more repeating transactions having at least a threshold number of similarities, may only select one or more repeating transactions having one or more required similarities, or the like. In one embodiment, an enterprise transaction module 104 may provide an interface (e.g., a graphical user interface (GUI), an application programming interface (API), a command line interface (CLI), and/or another interface) allowing a user (e.g., an end user on a hardware device 102, an administrator of a backend server 110, or the like) to select or otherwise define one or more rules for the enterprise transaction module 104 to identify one or more repeating transactions, such as a rule defining a threshold number of similarities for a repeated transaction, a rule requiring one or more similarities for a repeated transaction, a rule allowing one or more differences for a repeated transaction, or the like.)
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify NLP system of Griffith in view of the entity determination of Neuenschwander in view of lookup of Nagasundaram to include recurring transactions of Dotter in order to improve the speed of data retrieval operations ([0079, Dotter).
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Griffith, Neuenschwander and Nagasundaram in further view of Hoogs (US 20060015377 A1).
With respect to claims 7 and 14 Griffith, Neuenschwander and Nagasundaram don’t explicitly disclose however, Hoogs teaches wherein the entity is a merchant, further comprising analyzing, via the one or more transceivers and/or processors, the entity feedback data to identify a pattern of behavior of the merchant and adjusting the probabilistic confidence indicator by increasing confidence with respect to the merchant based on the pattern (Hoogs ¶ 0005] In one embodiment of the invention, a method for detecting business behavioral patterns related to a business entity is provided. The method comprises determining a model for business behavioral patterns in which the likelihood of a particular business behavioral pattern is associated with the occurrence of a qualitative event and a quantitative metric. The method further comprises extracting a first data set from a first data source and a second data set from a second data source. The first data set represents the occurrence of the qualitative event associated with the business entity. The second data set represents the quantitative metric associated with the business entity. Then a first confidence attribute and a first temporal attribute associated with the qualitative event are determined. Similarly, a second confidence attribute and a second temporal attribute associated with the quantitative metric is determined. Finally, the likelihood of the particular business behavior pattern is evaluated by running the model based on the first data set, the second data set, the first confidence attribute, the first temporal attribute, the second confidence attribute and the second temporal attribute.)
It would have been obvious to one of ordinary skill in the art prior to the effective filing date of the invention to modify NLP system of Griffith in view of the entity determination of Neuenschwander in view of lookup of Nagasundaram to include patterns of behavior of Hoogs in order to integrate qualitative and quantitative information to infer risk ([0004], Hoogs).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ATHAR N PASHA whose telephone number is (408)918-7675. The examiner can normally be reached on Monday-Thursday Alternate Fridays, 7:30-4:30 PT.
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, Daniel Washburn can be reached on (571)272-5551. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ATHAR N PASHA/Primary Examiner, Art Unit 2657
Prosecution Insights