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
This action is in reply to the application filed on 09/04/2025.
Claims 1, 3, 10, 12 and 19 are currently amended.
Claims 1-20 are currently pending and have been examined.
Response to Arguments
Applicant's arguments filed 09/04/2025 have been fully considered but they are not persuasive.
Regarding 35 U.S.C. §103 applicant argues that the Dotter reference “does not teach or fairly suggest "based on the NLP output and the recurring transaction indicator, 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; based on the probabilistic confidence indicator, associating the entity with one or more of the financial transaction and the NLP output in an entity identification database; generating token mappings between the entity and one or both of: (i) unstructured data relating to the financial transaction or (ii) the NLP output; and updating a 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," as recited in amended independent claim 1.” (response at 11).
Examiner assets that Dotter is relied on to teach “inputting a recurring transaction indicator to the entity service;” and not "based on the NLP output and the recurring transaction indicator, 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; based on the probabilistic confidence indicator, associating the entity with one or more of the financial transaction and the NLP output in an entity identification database; generating token mappings between the entity and one or both of: (i) unstructured data relating to the financial transaction or (ii) the NLP output; and updating a 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," For the argues elements the Borean and Neuenschwander are relied upon.
For at least the reasons stated above applications arguments regarding the 103 rejection is not persuasive.
Applicant argues the 35 U.S.C. §101 rejection starting 12 of the response.
Applicant argues that claims are similar to example 47 specifically “examples of the present application are directed to a feed-forward and feed- backward system which evolves over time by consuming volumes of transactions (including unstructured data), determining through probabilistic analyses and various feedback which string(s) of the unstructured data are sufficiently linked to standardized entities to justify a deterministic mapping therebetween, and speeding future processing through updating deterministic front-end components with the consequent mappings. (See Specification, paras. [0098]-[0099]) The learning mechanisms recited in the claims evolve the system and progressively improve efficiency at least in part by shifting processing responsibilities from probabilistic to deterministic components over time. (Paras. [0149], [0175]) (response at 15).
Examiner respectfully disagrees, the argued claims do not include the machine learning of example 47, and does not preform the practical application of dropping malicious network packets in real time.
For at least the reasons stated above applicant’s argument regarding 35 U.S.C. §101 are not persuasive.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
In the instant case, claims 1, 11 and 19 are directed to a method, system, and non-transitory computer-readable recording medium.
Abstract ideas are in bold below, and represents “matching financial information” which is a grouped under “Certain methods of organizing human activity — fundamental economic practices” in prong one of step 2A (MPEP 2106.04(a)).
A computer-implemented method for entity standardization comprising, via one or more transceivers and/or processors:
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;
inputting the NLP output to an entity service;
inputting a recurring transaction indicator to the entity service;
based on the NLP output and the recurring transaction indicator, 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;
based on the probabilistic confidence indicator, associating the entity with one or more of the financial transaction and the NLP output in an entity identification database;
generating token mappings between the entity and one or both of: (i) unstructured data relating to the financial transaction or (ii) the NLP output; and
updating a 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.
Claim 1 recites “matching financial information” which is a grouped under “Certain methods of organizing human activity — fundamental economic practices” in prong one of step 2A (MPEP 2106.04(a)). Claim 1 recites “inputting unstructured transaction data corresponding to a financial transaction to a … to generate … output comprising a portion of the unstructured transaction data”, “inputting the … output to an entity service”, “inputting a recurring transaction indicator to the entity service”, “based on the … output and the recurring transaction indicator, 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”, “based on the probabilistic confidence indicator, associating the entity with one or more of the financial transaction and the … output in an entity identification ….” Accordingly, the claim recites an abstract idea.
The additional elements of claim 1 such as “A computer-implemented method for entity standardization comprising, via one or more transceivers and/or processors”, “… natural language processor (NLP) …NLP …”, “…database”, “…token…” is accomplished, therefore it amounts to no more than “apply it” (MPEP 2106.05(f)(1)). Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration into a practical application, the additional elements amount to no more than mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of “matching financial information”.
Hence, claims 1, 11 and 19 are not patent eligible.
Claims 2, 11, and 20 recite “wherein the … output is associated with the entity in the entity identification database.” However, this does no more than describe the abstract idea. The additional elements of “NLP.” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use.
Claims 3 and 12 recite “configuring a lookup table to deterministically identify the entity in connection with a second, later financial transaction based on the … output.” However, this does no more than describe the abstract idea. The additional elements of “…NPL...” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use.
Claim 4 recites “retraining the … for generation of additional NLP output for a second financial transaction based on the … output.” However, this does no more than describe the abstract idea. The additional elements of “…NPL…” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use.
Claim 5 recites “locating the recurring transaction indicator, the recurring transaction indicator comprising a value populating a data field assigned for use with transactions under installment payment plans by a standardized financial transaction format.” However, this does no more than describe the abstract idea.
Claims 6 and 15 recite “wherein the recurring transaction indicator is representative of a likelihood that the financial transaction is under an installment payment plan, further comprising, via the one or more transceivers and/or processors, generating the recurring transaction indicator …based on data regarding the financial transaction and data regarding at least one previous financial transaction associated with one or more entities corresponding to the financial transaction.” However, this does no more than describe the abstract idea. The additional elements of “…automatically …” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use.
Claims 7 and 16 recite “wherein the generation of the recurring transaction indicator includes identification of a pattern with respect to one or more of recency, frequency and monetary-value between the financial transaction and the at least one previous financial transaction.” However, this does no more than describe the abstract idea.
Claims 8 and 17 recite “wherein the entity is a merchant, the identified pattern relates to the behavior of the merchant in connection with installment payment plans, and the generation of the probabilistic confidence indicator includes increasing confidence with respect to the merchant based on the pattern.” However, this does no more than describe the abstract idea.
Claims 9 and 18 recite “wherein the entity is an account holder, the identified pattern relates to the likely participation of the account holder in the installment payment plan, and the generation of the probabilistic confidence indicator includes increasing confidence with respect to the account holder based on the pattern.” However, this does no more than describe the abstract idea.
Claim 13 recites “wherein the one or more processors are further individually or collectively programmed to retrain the … for generation of additional … output for a second financial transaction based on the … output.” However, this does no more than describe the abstract idea. The additional elements of “…NPL….” does no more than use a computer as a tool to perform an abstract idea and do no more than generally link the abstract idea to a particular field of use.
Claim 14 recites “locate the recurring transaction indicator, the recurring transaction indicator comprising a value populating a data field assigned for use with transactions under installment payment plans by a standardized financial transaction format” However, this does no more than describe the abstract idea
The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not affect an improvement to another technology or technical field, the claims do not amount to an improvement to the functioning of a computer system itself, and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
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 (i.e., changing from AIA to pre-AIA ) 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-12, and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Borean (US 2015/0120679 A1) in view of Dotter (US 2020/0074565 A1) and Neuenschwander et al. (US 2022/005063 A1)
Regarding claims 1, 10 and 19
Borean teaches:
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; (See at least Borean [0025] - [0028] “0025] The entity matching server 110 obtains associated data of an individual from one or more identities 108A-N. In one embodiment, the associated data may be unstructured data, or structured data. The unstructured data which may contain information on the individual. The information is extracted from the associated data to obtain extracted information. A standardization of unstructured data based on the extracted information is standardized obtained from the one or more identities 108A-N. …[0026] … The extracted information includes at least one of (i) an information associated with a name, …(v) interaction information (e.g., a purchase reference, a purchase completion date, a purchase location). …The information extracting module 206 extracts information from the associated data to obtain extracted information. The entity matching server 110 further includes an extracted information standardizing module that standardizes the extracted information to obtain standardized extracted information. In one embodiment, the standardized extracted information is obtained by at least one of (i) removing one or more noise words from the information, (ii) standardizing case, or (iii) standardizing references associated with the extracted information. In one embodiment, the references associated with the information include (i) city names, (ii) states/provinces, (iii) units of measures, and (iv) one or more terms associated with a name. For example, CM=Centimeter, name terms INC=Incorporated. [0027]… the entity matching server 110 employs pre-processing of associated data using techniques and knowledge engineering techniques (e.g., a deterministic reasoning to derive information (i.e. determining gender based on name lists), a semantic reasoning and a machine learning but are not limited to the embodiments mentioned herein) to discover one or more additional information which helps in a entity resolution process. In one embodiment, the entity resolution is process of matching one instance of an entity to another (e.g., matching two customer records together). The outcome of the entity resolution process is a decision that states if the two records are a match (i.e., they are the same), a non-match or a maybe-match. [0028] In one embodiment, the additional information may include a name list, and roles of the entity (e.g., prospect, customer, employee, etc.). The unstructured data may be analyzed using natural language programming (NLP) and/or machine learning classification techniques using missing physical address elements, likes, topics written about, relationship information from profile descriptions. The confidence level identifying module 210 that calculates a confidence level for the additional information. In one embodiment, the confidence level is derived based on at least one of (i) a quality, or (ii) an origin of the associated data. …”
inputting the NLP output to an entity service; (See at least Borean [0027] The additional information obtaining module 208 that obtains additional information associated with the one or more identities based on the extracted information. In one embodiment, the entity matching server 110 employs pre-processing of associated data using techniques and knowledge engineering techniques (e.g., a deterministic reasoning to derive information (i.e. determining gender based on name lists), a semantic reasoning and a machine learning but are not limited to the embodiments mentioned herein) to discover one or more additional information which helps in a entity resolution process. In one embodiment, the entity resolution is process of matching one instance of an entity to another (e.g., matching two customer records together). The outcome of the entity resolution process is a decision that states if the two records are a match (i.e., they are the same), a non-match or a maybe-match.
based on the NLP output and the recurring transaction indicator, 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 (See at least Borean : [0029] and [0029]: [0028] In one embodiment, the additional information may include a name list, and roles of the entity (e.g., prospect, customer, employee, etc.). The unstructured data may be analyzed using natural language programming (NLP) and/or machine learning classification techniques using missing physical address elements, likes, topics written about, relationship information from profile descriptions. The confidence level identifying module 210 that calculates a confidence level for the additional information. In one embodiment, the confidence level is derived based on at least one of (i) a quality, or (ii) an origin of the associated data. For example, the confidence level may be determined to calculate data quality for an entity A and a second entity B. In one embodiment, the unstructured data and the additional information derived from the unstructured data are validated based on one or more parameters that may include, but are not limited to genuineness and a quality. [0029] The comparison module 212 that compares the additional information with trustworthy information from a database is compared to verify an accuracy of the additional information. The comparison of the one or more entities may be based on a calculation formula. The comparison functions may be the functions that perform the actual comparison of data values and scale the confidence of the comparison with a trust in the data being compared. In one embodiment, the result obtained from the comparison module 212 is an optimal match.
based on the probabilistic confidence indicator, associating the entity with one or more of the financial transaction and the NLP output in an entity identification database. (See at least Borean [0036] FIG. 3 is a flow diagram illustrating a method of identifying an individual from one or more identities 108A-N and their associated data according to an embodiment herein. In step 302, an associated data of an individual is obtained from one or more identities. In one embodiment, the associated data is unstructured data. In step 304, information is extracted from the associated data to obtain extracted information. In step 306, the extracted information is standardized to obtain standardized extracted information. In step 308, additional information associated with the one or more identities is obtained based on the standardized extracted information. In step 310, a confidence level is calculated for the additional information. The confidence level is derived based on at least one of (i) a quality, or (ii) an origin of the associated data. In step 312, data from a database is compared with the additional information and the one or more identities with the associated data. The data from the database includes trustworthy information. In step 314, the individual is identified from the one or more identities and the associated data based on the confidence level. The associated data include at least one of (i) one or more posts on a social medium, (ii) data associated with an identity on a social medium, (iii) documents, (iv) emails, or (v) web logs.
Borean does not specifically teach: inputting a recurring transaction indicator to the entity service;
However Dotter teaches:
inputting a recurring transaction indicator to the entity service; [0056] and [0062]: [0056] In certain embodiments, a recurring transaction is a type of repeated transaction with one or more predefined similarities, such as a repeated transaction that occurs on or around the same time during each of a plurality of time periods (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) and/or is associated with the same or similar (e.g., within a predefined percentage or amount) transaction amount, or the like. In one embodiment, an enterprise transaction module 104 may be configured to identify any repeating transaction (e.g., including recurring and non-recurring events/transactions). And [0062] Metadata records, as used herein, comprise additional data describing and/or created for financial transaction data. For example, in various embodiments, a metadata module 202 may parse downloaded financial transaction data to generate metadata records comprising a transaction amount, a transaction date, a spending category, an entity identifier, a classification of whether a financial transactions is a recurring transaction and/or subscription, an account identifier, a transaction type, and/or other metadata for a financial transaction.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for identifying an individual for one or more identities and their associated data of Borean in view of with the Automated enterprise transaction data aggregation and accounting as taught by Dotter in order to determine accounting categories for each transaction. (Dotter [0034])
Borean and Dotter does not specifically teach: generating token mappings between the entity and one or both of: (i) unstructured data relating to the financial transaction or (ii) the NLP output; and updating a 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.
However Neuenschwander teaches:
generating token mappings between the entity and one or both of: (i) unstructured data relating to the financial transaction or (ii) the NLP output; and (See at least Neuenschwander [0180] and [0182]: [0180] Sample known authorization strings and merchant names are obtained from Existing Merchants (14116) so that labelled data is gathered to build a supervised classification model (14113). The sample strings are then split into training and tests sets, and the authorization strings are embedded (14305) so that a mathematical representation of the string can exist to train the model. One embedding embodiment that may be used is count vectorizer. [0182] If the prediction is above a confidence threshold, the authorization string is sent to existing merchants topic with newly mapped merchant (14116). If the prediction is below the confidence interval, the authorization string is moved to validation topic for a process to validate and re-map the string to correct merchant (14302). One embodiment of this can be a human in the loop analyzing low confidence authorization stings and adding them back to the existing merchants database/topic (14303). In another embodiment, this may be automated. For example, fuzzy matching techniques may be used, using cosine similarity to find a better match for the string. A brute force search may be used to compare a low threshold string to every other identified or classified string, to find a better match.
updating a 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. (See at least Neuenschwander [0184] and [0176]: [0184] The authorization string with assigned merchant name is inserted into the earlier mentioned Kafka Stream Global KTable, and the original raw authorization message (14111) will be produced back to the original raw topic to be re-processed (14120) [0176] In one embodiment, the topic messages are read by consumer groups message by message, in the order that the message was received (14204). For each message, the Kstream app checks against a Kafka Streaming Global Ktable (14116). This may comprise a full list of known merchant strings with related merchant info.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for identifying an individual for one or more identities and their associated data of Borean and in view of with the method for delivering targeted marketing offers to consumers via mobile application as taught by Neuenschwander in order to aggregate data from purchases. (Neuenschwander [0185])
Regarding claims 2, 11 and 20
Borean teaches:
wherein the NLP output is associated with the entity in the entity identification database. (See at least Borean [0022] and [0070]: [0022] As mentioned, there remains a need for a better technique for matching heterogeneous entities with sparse data and unreliable information with the internal data. The embodiments herein achieve this by providing an entity matching server for identifying an individual from one or more entities and associated data. The associated data associated with an individual from the one or more entities (e.g., one or more identities). Unstructured data may be related to the individual, whose information is to be compared between one or more heterogeneous entities, or between the heterogeneous entities and an internal database. Then additional information associated with one or more identities is obtained. A confidence level is obtained for the additional information. Based on the confidence level, an individual is identified from one or more entities and associated data. Referring now to the drawings, and more particularly to FIGS. 1 through 5, where similar reference characters denote corresponding features consistently throughout the figures, preferred embodiments are shown. [0070] The unstructured data is from entity source like tweets, Facebook.RTM. users, emails, documents, web logs, master data management systems, etc., or like. The entity resolution technique may use natural language processing (NLP), semantic reasoning, etc., to extract structured information from semi-structured, unstructured data or like. The structured information from the heterogeneous entities may include name information, location information, relationship information, demographic information (for example email address, birth dates, etc.), and interaction information (for example what is the purchase reference, when was the purchase completed, where was the purchase completed, etc.).
Regarding claims 3 and 12
Borean does not specifically teach: further comprising, via the one or more transceivers and/or processors, configuring a lookup table to deterministically identify the entity in connection with a second, later financial transaction based on the NLP output.
However Dotter teaches:
Further comprising, via the one or more transceivers and/or processors, configuring a lookup table to deterministically identify the entity in connection with a second, later financial transaction based on the NLP output. (See at least 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.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for identifying an individual for one or more identities and their associated data of Borean and in view of with the method for delivering targeted marketing offers to consumers via mobile application as taught by Neuenschwander in order to aggregate data from purchases. (Neuenschwander [0185])
Regarding claims 5 and 14
Borean does not specifically teach: further comprising, via the one or more transceivers and/or processors, locating the recurring transaction indicator, the recurring transaction indicator comprising a value populating a data field assigned for use with transactions under installment payment plans by a standardized financial transaction format.
However Dotter teaches:
further comprising, via the one or more transceivers and/or processors, locating the recurring transaction indicator, the recurring transaction indicator comprising a value populating a data field assigned for use with transactions under installment payment plans by a standardized financial transaction format. (See at least Dotter [0055] A repeating transaction may comprise an event that occurs more than once. Different occurrences of a repeating transaction, in certain embodiments, may comprise at least one attribute in common (e.g., and/or may have one or more attributes that are different). 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 before the effective filing date of the invention to modify the method for identifying an individual for one or more identities and their associated data of Borean in view of with the Automated enterprise transaction data aggregation and accounting as taught by Dotter in order to determine accounting categories for each transaction. (Dotter [0034])
Regarding claims 6 and 15
Borean does not specifically teach: wherein the recurring transaction indicator is representative of a likelihood that the financial transaction is under an installment payment plan, further comprising, via the one or more transceivers and/or processors, generating the recurring transaction indicator automatically based on data regarding the financial transaction and data regarding at least one previous financial transaction associated with one or more entities corresponding to the financial transaction.
However Dotter teaches:
wherein the recurring transaction indicator is representative of a likelihood that the financial transaction is under an installment payment plan, further comprising, via the one or more transceivers and/or processors, generating the recurring transaction indicator automatically based on data regarding the financial transaction and data regarding at least one previous financial transaction associated with one or more entities corresponding to the financial transaction. (See at least Dotter [0049] An enterprise transaction module 104 may cleanse, categorize, and/or classify aggregated transaction data for a business entity. In certain embodiments, an enterprise transaction module 104 may map an enterprise and/or commercial transaction for a user (e.g., a business entity) to a general ledger (GL) code or other accounting category. An enterprise transaction module 104 may receive one or more transaction mappings from a user (e.g., an administrator or other user associated with a business entity, or the like). For example, a user may provide an enterprise transaction module 104 with one or more mappings and/or vectors from a category and/or classification (e.g., nature of a transaction) to a GL code or other accounting category, from a payee and/or third-party to a GL code or other accounting category, from an account and/or account type to a GL code or other accounting category, or the like. In a further embodiment, an enterprise transaction module 104 may determine one or more transaction mappings in an automated manner (e.g., based on one or more previous mappings by a user, using machine learning or other artificial intelligence, based on a ruleset, or the like).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for identifying an individual for one or more identities and their associated data of Borean in view of with the Automated enterprise transaction data aggregation and accounting as taught by Dotter in order to determine accounting categories for each transaction. (Dotter [0034])
Regarding claims 7 and 16
Borean does not specifically teach: wherein the generation of the recurring transaction indicator includes identification of a pattern with respect to one or more of recency, frequency and monetary-value between the financial transaction and the at least one previous financial transaction.
However Dotter teaches:
wherein the generation of the recurring transaction indicator includes identification of a pattern with respect to one or more of recency, frequency and monetary-value between the financial transaction and the at least one previous financial transaction. (See at least Dotter [0055] A repeating transaction may comprise an event that occurs more than once. Different occurrences of a repeating transaction, in certain embodiments, may comprise at least one attribute in common (e.g., and/or may have one or more attributes that are different). 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 before the effective filing date of the invention to modify the method for identifying an individual for one or more identities and their associated data of Borean in view of with the Automated enterprise transaction data aggregation and accounting as taught by Dotter in order to determine accounting categories for each transaction. (Dotter [0034])
Regarding claims 8 and 17
Borean does not specifically teach: wherein the generation of the recurring transaction indicator includes identification of a pattern with respect to one or more of recency, frequency and monetary-value between the financial transaction and the at least one previous financial transaction.
However Dotter teaches:
wherein the generation of the recurring transaction indicator includes identification of a pattern with respect to one or more of recency, frequency and monetary-value between the financial transaction and the at least one previous financial transaction. (See at least Dotter [0055] A repeating transaction may comprise an event that occurs more than once. Different occurrences of a repeating transaction, in certain embodiments, may comprise at least one attribute in common (e.g., and/or may have one or more attributes that are different). 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 before the effective filing date of the invention to modify the method for identifying an individual for one or more identities and their associated data of Borean in view of with the Automated enterprise transaction data aggregation and accounting as taught by Dotter in order to determine accounting categories for each transaction. (Dotter [0034]).
Regarding claims 9 and 18
Borean does not specifically teach: wherein the entity is an account holder, the identified pattern relates to the likely participation of the account holder in the installment payment plan, and the generation of the probabilistic confidence indicator includes increasing confidence with respect to the account holder based on the pattern.
However Dotter teaches:
wherein the entity is an account holder, the identified pattern relates to the likely participation of the account holder in the installment payment plan, and the generation of the probabilistic confidence indicator includes increasing confidence with respect to the account holder based on the pattern. (See at least Dotter [0068] For example, a string describing a transaction may be represented as “56902 ABCXYZ PAYMENT 56902 8756250331” or the like. A metadata module 202 may remove extraneous information to help a business entity or other user to better identify the merchant or other party from the transaction description, such that the merchant or other party is readily recognizable. In the example above, the metadata module 202 may cleanse the description to “ABCXYZ Company,” which a user may readily recognize, for example, as its mortgage lender or the like. The metadata module 202 may adapt and may automatically customize descriptions based on a business entity or other user's history, such that as recurring or repeating descriptions are posted the metadata module 202 recognizes the description of the merchant or other part and consistently identifies it accordingly. In some embodiments, a metadata module 202 may cleanse, categorize, and/or classify a financial transaction before presenting the transaction and/or any associated transaction data to a business entity or other user.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for identifying an individual for one or more identities and their associated data of Borean in view of with the Automated enterprise transaction data aggregation and accounting as taught by Dotter in order to determine accounting categories for each transaction. (Dotter [0034])
Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Borean (US 2015/0121679 A1) in view of Dotter (US 2020/074565 A1), Neuenschwander et al. (US 2022/005063 A1) and further in view of Sachtleben et al. (US 10,572,727 B1)
Regarding claims 4 and 13
Borean does not specifically teach: further comprising, via the one or more transceivers and/or processors, retraining the NLP for generation of additional NLP output for a second financial transaction based on the NLP output. However, Dotter teaches:
further comprising, via the one or more transceivers and/or processors, retraining the NLP for generation of additional NLP output for a second financial transaction based on the NLP output. (See at least Sachtleben (Col 4 line 32 - 62) In some implementations, the analysis of a document may include comparing the image(s) of the document to a previously established template or format that describes a typical layout of a document from a particular payee. For example, a payee may use a standard form for their bills, with certain items of information (e.g., account number, amount due, due date, etc.) in the same location across multiple bills. In such instances, extraction of the information from the document may include analyzing the text of the document at the particular locations where the information is located (e.g., using optical character recognition or other suitable technique) and determining the alphanumeric text data that is present at those locations on the document. If certain items of information cannot be extracted automatically with sufficient confidence or accuracy, in some instances the user may be prompted to enter the information into a user interface, and/or verify that the extracted information is correct. User input in such instances may be used to refine the model (e.g., template, format) for data extraction, to enable subsequently performed automatic data extraction to be performed more reliably. In some implementations, the analysis of document image(s) to extract information may employ one or more suitable machine learning techniques. For example, machine learning may be employed to train a model to predict the information in a document (e.g., account number, amount due, due date, etc.) based on input image(s) of the document. In such instances, the input provided by the user to modify and/or verify information elements predicted by the model may then be used to further retrain or otherwise refine the model for more accurate predictions in the future.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the method for identifying an individual for one or more identities and their associated data of Borean and Dotter in view of image data extraction for transaction management as taught by Sachtleben in order to extract information from a bill. (Sachtleben (Col 17 line 57 – col 18 line 4)
Prior Art of Record Not Currently Relied Upon
Sakpal et al. (US 2023/0385701 A1) teaches: artificial intelligence engine for entity resolution and standardization.
McGlynn et al (US 2009/02522364 A1) Teaches: Method for attribute based transaction categorization.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY MARK JAMES whose telephone number is (571)272-5155. The examiner can normally be reached M-F 8:30am - 5:00pm 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, Ryan Donlon can be reached at 571-270-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/GREGORY M JAMES/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692 March 19, 2026