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 .
This application has PRO 63/429,100 11/30/2022
Status of Claims
Claims 1-6 and 21-34 are currently pending and rejected.
Claims 7-20 are canceled.
Claim Rejection – 35 U.S.C. 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-6 and 21-34 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The rationale for this finding is explained below. In the instant case, the claims are directed towards categorizing transactions associated with a client. The concept is clearly related to managing human transactional activities, thus the present claims fall within the Certain Method of Organizing Human Activity grouping. Moreover, the claimed procedure can be performed mentally and the result can be presented on paper, thus the present claims also fall within the Mental Processes grouping. The claims do not include limitations that are “significantly more” than the abstract idea because the claims do not include an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Note that the limitations, in the instant claims, are done by the generically recited computer device. The limitations are merely instructions to implement the abstract idea on a computer and require no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry. Therefore, claims 1-6 and 21-34 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Step 1: The claims 1-6 and 21-34 are directed to a process, machine, manufacture, or composition matter.
In Alice Corp. Pty. Ltd. v. CLS Bank Intern., 134 S. Ct. 2347 (2014), the Supreme Court applied a two-step test for determining whether a claim recites patentable subject matter. First, we determine whether the claims at issue are directed to one or more patent-ineligible concepts, i.e., laws of nature, natural phenomenon, and abstract ideas. Id. at 2355 (citing Mayo Collaborative Servs. v. Prometheus Labs., Inc., 132 S. Ct. 1289, 1296–96 (2012)). If so, we then consider whether the elements of each claim, both individually and as an ordered combination, transform the nature of the claim into a patent-eligible application to ensure that the patent in practice amounts to significantly more than a patent upon the ineligible concept itself.
Claims 1-6 and 21-34 are directed to a process (i.e., method claims).
Step 2A: The claims are directed to an abstract idea.
Prong One
The present claims are directed towards categorizing transactions associated with a client. The concept comprises receiving a transaction, categorizing the transaction as a credit card payment transaction or a transfer transaction, applying container logic to the transaction, determining whether a counterpart transaction is identified based on applying the container logic, place the transaction in a buffer base on a flag of the container, displaying a client dashboard which does not include transaction in the buffer, and periodically retesting the transaction to determine if a new matching counterpart transaction becomes available within a predefined amount of time. Paragraph 0027 of Applicant’s specification clearly discloses the claims are directed to a management platform which is a transaction categorizer that categorizes each transaction received from financial institution server and delivers the data to end user. In other words, the present claims are directed to managing human transaction activities. Thus, the present claims clearly fall within the Certain Method of Organizing Human Activity grouping. Examiner also points out that the present claims, similar to the ineligible claims in Electric Power Group v. Alstom, recite obtaining data, analyzing data, and presenting result of the analysis. The claimed concept can be performed in the human mind and the result can be presenting on paper. As such, the present claims also fall within the Mental Processes grouping. The performance of the claim limitations using generic computer components (i.e., a management platform which comprises a non-transitory memory and a processor) does not preclude the claim limitation from being in the certain methods of organizing human activity grouping or mental processes grouping. Accordingly, the present claims recite an abstract idea.
Prong Two
Independent claim 1 recites a management platform which comprises a non-transitory memory and a processor as additional elements. Independent claim 1 also recites a transaction categorizer, a container assigner, and a client dashboard as additional software elements. Dependent claims 1-6, 21-28 and 31-34 do not recite any other additional element. The additional elements are claimed to perform basic computer functions, such as receiving data, sorting data, applying logic (rules), matching counterpart transaction, displaying result, and periodically repeating the process. Dependent claims 29 and 30 recite a machine learning component. However, Examiner points out that application of generic machine learning to new data environments, without disclosing improvements to the machine learning model to be applied, is patent ineligible under 101 (see Recentive v. Fox). The recitation of the computer elements amounts to mere instruction to implement an abstract concept on computers. The present claims do not solve a problem specifically arising in the realm of computer networks. The present claims do not recite limitation that improve the functioning of computer, effect a physical transformation, or apply the abstract concept in some other meaningful way beyond generally linking the use of the abstract concept to a particular technological environment. As such, the present claims fail to integrate into a practical application.
Step 2B: The claims do not recite additional elements that amount to significantly more than the abstract idea.
As discussed earlier, independent claim 1 recites a management platform which comprises a non-transitory memory and a processor as additional elements. Independent claim 1 also recites a transaction categorizer, a container assigner, and a client dashboard as additional software elements. Dependent claims 1-6, 21-28 and 31-34 do not recite any other additional element. The additional elements are claimed to perform basic computer functions, such as receiving data, sorting data, applying logic (rules), matching counterpart transaction, displaying result, and periodically repeating the process. The additional elements are claimed to perform well-understood, routine, and conventional computer functions, such as receiving user inputs (i.e. “receiving or transmitting data over a network”), obtaining projections based on an aggregated dataset (i.e., extracting data and performing calculations), determining a set of values based on user inputs and projections (i.e., performing calculations), deriving and presenting portfolio plan (i.e., performing calculations and analysis, and displaying result of analysis). According to MPEP 2106.05(d), “performing repetitive calculations”, “receiving, processing, and storing data”, “electronically scanning or extracting data from a physical document”, “electronic recordkeeping”, “storing and retrieving information in memory”, and “receiving or transmitting data over a network, e.g., using the Internet to gather data” are considered well-understood, routine, and conventional functions of computer. Dependent claims 29 and 30 recite a machine learning component. However, Examiner points out that application of generic machine learning to new data environments, without disclosing improvements to the machine learning model to be applied, is patent ineligible under 101 (see Recentive v. Fox). The present claims do not improve the functioning of computer. Simply implementing the abstract idea on a generic computer or using a computer as a tool to perform an abstract idea cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Therefore, the present claims are ineligible for patent.
Claim Rejection – 35 U.S.C. 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-4 and 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hendry et al. (Patent No.: US 11,625,772), in view of Mori et al. (JP-4176181-B2).
As per claim 1, Hendry teaches a containerized transaction management method, comprising:
receiving, by a management platform, a transaction associated with a client from
an aggregator (see col 2 line 6-19, “The first subsystem is configured to receive transaction events in the event stream from a plurality of financial transaction processing systems”; see col 8 line 36-56 for transaction data aggregator; see col 9 line 50-60, “This data, which collectively may be referred to as enriched transaction data 664 is used by a data aggregator to provide real time enriched financial transaction data for consumption by end users”);
categorizing, by a transaction categorizer stored in a non-transitory memory of the management platform and executed by a processor of the management
platform, the transaction (see col 7 line 18-27, “data enrichment services 130 can facilitate data cleaning 302, categorizing 304, classifying 306, authentication 308, and verification 310; see col 16 line 22-55, “Upon receiving enriched data event 2626, push notification service 2630 may send a message 2642 including enriched data to a user device 2640. In this case, the message includes information about the new grocery purchase”);
determining, by the container assigner, whether a counterpart transaction is
identified based on applying the container logic (see col 9 line 18-49, “a reconciliation API 624 that communicates with reconciliation API 624 that communicates with reconciliation system 626 to reconcile processed transactions with scheduled transactions, manual transactions, and pending transactions”, and “Using reconciliation API 624, reconciliation of scheduled, manual, and pending transactions are performed”; Examiner notes, the processed transaction in Hendry is a counterpart transaction to the scheduled/manual/pending transactions);
in response to a determination that no counterpart transaction is identified, placing, by the container assigner, the transaction in a buffer based on a flag of the
container (see col 9 line 18-29, “long term storage system 604 may include one or more databases 628 that provide long term storage of all processed and pending transaction data”; see col 11 line 10-19, “Data structure 800 may include a ‘Status’ data field 819 that allows systems to record the status of a transaction, for example either ‘pending’ or ‘processed’; see col 16 line 4-15, “as soon as new scheduled payment is entered by a customer, the we bill pay system 2502 publishes a new event with the scheduled payment information…This data can then be stored, either in a temporary datastore, or in a long-term storage system, depending on the state of the transaction”; when no counterpart transaction is identified, the pending/scheduled transaction will remain in pending/scheduled pool, which can be interpreted as in a buffer; prior art teaches using a status data field, which can be interpreted as a flag, to indicate whether a transaction is in the pending/scheduled pool or the processed pool);
providing, by a display engine stored in the non-transitory memory and executed
by the processor, a client dashboard to a user device for display on a graphical user interface (GUI) of the user device (see FIG. 20, prior art shows an account summary page, which could be interpreted as “client dashboard”; see col 13 line 53 through col 14 line 31, “The embodiments may enable real time account summary information by leverage enriched financial transaction data that is pushed to an event stream in real time”, and “Each of these data fields provided within account summary page 2002 may be determined dynamically when the customer loads the corresponding website or page within a mobile application”),
wherein the client dashboard comprises a graphical representation that does not include the transaction in the buffer (Examiner points out that not displaying transaction in the buffer/pending pool is merely “elimination of an elements or its functions”, and as such this limitation an obvious modification in view of In re Karlson; see col 14 line 52-64, “the transaction records 2212 stored in datastore 2210 only provide partial view of account activity, since they do not include information about scheduled or other pending transactions”); and
periodically retesting, by the container assigner, the transaction to determine if a
new matching counterpart transaction becomes available within a predefined amount of time (see col 8 line 17-24, “the system checks to see if the financial transaction has been fully processed by the various transaction processing systems. If not, the system returns to step 404 to wait for continued processing”; see col 9 line 18-49, “a reconciliation API 624 that communicates with reconciliation API 624 that communicates with reconciliation system 626 to reconcile processed transactions with scheduled transactions, manual transactions, and pending transactions”; prior art teaches constantly waiting for counterpart transaction to be processed, so that it can be reconciled with scheduled/pending transactions in the database).
Examiner notes however, Hendry does not teach categorizing, by a transaction categorizer stored in a non-transitory memory of the management platform and executed by a processor of the management platform, the transaction as a credit card payment transaction or a transfer transaction; applying, by a container assigner stored in the non-transitory memory and executed by the processor, container logic based on a determination that the transaction is a credit card payment transaction or a transfer transaction.
Mori teaches categorizing, by a transaction categorizer stored in a non-transitory memory of the management platform and executed by a processor of the management platform, the transaction as a credit card payment transaction or a transfer transaction; applying, by a container assigner stored in the non-transitory memory and executed by the processor, container logic based on a determination that the transaction is a credit card payment transaction or a transfer transaction (see paragraph 0048, “In the transaction type, the latest online/offline transaction content is managed by dividing into transaction classification and transaction mode in the latest used transaction information. The transaction classification manages the distinction between electronic money transactions, credit card transactions, etc.”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Hendry with teaching from Mori to include categorizing, by a transaction categorizer stored in a non-transitory memory of the management platform and executed by a processor of the management platform, the transaction as a credit card payment transaction or a transfer transaction; applying, by a container assigner stored in the non-transitory memory and executed by the processor, container logic based on a determination that the transaction is a credit card payment transaction or a transfer transaction. The modification would have been obvious, because it is merely applying a known technique (i.e., classifying transaction as electronic transfer or credit card payment) to a known method (i.e., transaction management) ready to provide predictable result (i.e., provide more insightful information about user’s transactions).
As per claim 2, Hendry teaches wherein the predefined amount of time is between four and seven days (Examiner notes the waiting period is merely a business decision rather than technological feature, and thus this limitation does not carry patentable weight; see col 8 line 17-24, “the system checks to see if the financial transaction has been fully processed by the various transaction processing systems. If not, the system returns to step 404 to wait for continued processing”; see col 9 line 18-49, “a reconciliation API 624 that communicates with reconciliation API 624 that communicates with reconciliation system 626 to reconcile processed transactions with scheduled transactions, manual transactions, and pending transactions”; prior art teaches constantly waiting for counterpart transaction to be processed, so that it can be reconciled with scheduled/pending transactions in the database).
As per claim 3, Hendry teaches wherein the predefined amount of time is five days (Examiner notes the waiting period is merely a business decision rather than technological feature, and thus this limitation does not carry patentable weight; see col 8 line 17-24, “the system checks to see if the financial transaction has been fully processed by the various transaction processing systems. If not, the system returns to step 404 to wait for continued processing”; see col 9 line 18-49, “a reconciliation API 624 that communicates with reconciliation API 624 that communicates with reconciliation system 626 to reconcile processed transactions with scheduled transactions, manual transactions, and pending transactions”; prior art teaches constantly waiting for counterpart transaction to be processed, so that it can be reconciled with scheduled/pending transactions in the database).
As per claim 4, Hendry teaches identifying the new matching counterpart transaction within the predetermined amount of time based on the periodic retesting (see col 8 line 17-24, “the system checks to see if the financial transaction has been fully processed by the various transaction processing systems. If not, the system returns to step 404 to wait for continued processing”; see col 9 line 18-49, “a reconciliation API 624 that communicates with reconciliation API 624 that communicates with reconciliation system 626 to reconcile processed transactions with scheduled transactions, manual transactions, and pending transactions”; prior art teaches constantly waiting for counterpart transaction to be processed, so that it can be reconciled with scheduled/pending transactions in the database);
in response to identifying the new matching counterpart transaction, removing the transaction from the buffer (see col 9 line 18-49, “a reconciliation API 624 that communicates with reconciliation API 624 that communicates with reconciliation system 626 to reconcile processed transactions with scheduled transactions, manual transactions, and pending transactions”, and “Using reconciliation API 624, reconciliation of scheduled, manual, and pending transactions are performed”; Examiner notes, the processed transaction in Hendry is a counterpart transaction to the scheduled/manual/pending transactions; see col 11 line 10-19, “Data structure 800 may include a ‘Status’ data field 819 that allows systems to record the status of a transaction, for example either ‘pending’ or ‘processed’; when detected transaction is reconciled with pending transaction, the status of the transaction is changed from pending to processed; in other words, the transaction is removed from the pending pool); and
providing, by the display engine, an updated client dashboard to the user device
for display on the GUI, wherein the updated client dashboard does not include the transaction or the new matching counterpart transaction (see FIG. 20, prior art shows an account summary page, which could be interpreted as “client dashboard”; see col 13 line 53 through col 14 line 31, “The embodiments may enable real time account summary information by leverage enriched financial transaction data that is pushed to an event stream in real time”, and “Each of these data fields provided within account summary page 2002 may be determined dynamically when the customer loads the corresponding website or page within a mobile application”).
As per claim 6, Hendry teaches in response to no new matching counterpart transaction being available within the predefined amount of time, providing, by the display engine, an updated client dashboard to the user device for display on the GUI, wherein the updated client dashboard comprises an updated graphical representation that includes the transaction (see col 13 line 31-61, “all systems have a real time view of the transaction record at all times” and “The embodiments may enable real time account summary information by leveraging enriched financial transaction data that is pushed to an event stream in real time”).
Claim 7-20. (Canceled).
Claim(s) 5, 21-24, 26, and 27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hendry et al. (Patent No.: US 11,625,772), in view of Mori et al. (JP-4176181-B2), and further in view of Baggett (Pub. No.: US 2021/0158299).
As per claim 5, Hendry does not teach wherein the graphical representation comprises an actual bar, a planned bar, and an expected indicator for each element of a plurality of elements.
Baggett teaches the graphical representation comprises an actual bar, a planned bar, and an expected indicator for each element of a plurality of elements (see paragraph 0034, “GUI may have a ‘New’, ‘Pending’, and ‘Completed’ category tabs to organize the payment disputes”; also see paragraph 0042; prior art teaches using a tab GUI element to separate different categories of transactions; bar and tab are interchangeable).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Hendry with teaching from Baggett to include the graphical representation comprises an actual bar, a planned bar, and an expected indicator for each element of a plurality of elements. The modification would have been obvious, because it is merely applying a known technique (i.e., displaying transactions in different categories using GUI elements) to a known method (i.e., transaction management) ready to provide predictable result (i.e., provide more insightful information about user’s transactions).
As per claim 21, Hendry teaches providing, by the display engine, a transaction category screen to the user device for display on the GUI of the user device, wherein the transaction category screen includes a graphical representation of transaction data based on a category associated with each transaction (see col 16 line 22-55, “real time notifications about new purchases, including the amount of the purchase and the purchase category could be useful for managing budgets”)
Hendry does not teach wherein the graphical representation of the transaction data comprises an actual bar, a plan bar, and an expected indicator for each category; receiving, by the display engine, an indication of a user selection of the actual bar
for a first category of transactions from the user device; in response to receipt of the indication of the user selection of the actual bar for the first category of transactions, providing, by the display engine, a plurality of transactions associated with the first category of transactions to the user for display on the GUI; receiving, by the display engine, a user inputted instruction from the user device to assign a first transaction of the plurality of transactions associated with the first category of transactions to a fund; and in response to receipt of the user inputted instruction, providing, by the display
engine, an updated transaction category screen to the user device for display on the GUI, wherein the updated transaction category screen includes an updated graphical representation of updated transaction data for the first category of transactions, and wherein the updated graphical representation comprises an updated plan bar expended by an amount of the first transaction.
Baggett teaches the graphical representation of the transaction data comprises an actual bar, a plan bar, and an expected indicator for each category; receiving, by the display engine, an indication of a user selection of the actual bar for a first category of transactions from the user device; in response to receipt of the indication of the user selection of the actual bar for the first category of transactions, providing, by the display engine, a plurality of transactions associated with the first category of transactions to the user for display on the GUI; receiving, by the display engine, a user inputted instruction from the user device to assign a first transaction of the plurality of transactions associated with the first category of transactions to a fund; and in response to receipt of the user inputted instruction, providing, by the display engine, an updated transaction category screen to the user device for display on the GUI, wherein the updated transaction category screen includes an updated graphical representation of updated transaction data for the first category of transactions, and wherein the updated graphical representation comprises an updated plan bar expended by an amount of the first transaction (see paragraph 0034, “GUI may have a ‘New’, ‘Pending’, and ‘Completed’ category tabs to organize the payment disputes”; also see paragraph 0042; prior art teaches using a tab GUI element to separate different categories of transactions; bar and tab are interchangeable).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Hendry with teaching from Baggett to include the graphical representation of the transaction data comprises an actual bar, a plan bar, and an expected indicator for each category; receiving, by the display engine, an indication of a user selection of the actual bar for a first category of transactions from the user device; in response to receipt of the indication of the user selection of the actual bar for the first category of transactions, providing, by the display engine, a plurality of transactions associated with the first category of transactions to the user for display on the GUI; receiving, by the display engine, a user inputted instruction from the user device to assign a first transaction of the plurality of transactions associated with the first category of transactions to a fund; and in response to receipt of the user inputted instruction, providing, by the display engine, an updated transaction category screen to the user device for display on the GUI, wherein the updated transaction category screen includes an updated graphical representation of updated transaction data for the first category of transactions, and wherein the updated graphical representation comprises an updated plan bar expended by an amount of the first transaction. The modification would have been obvious, because it is merely applying a known technique (i.e., displaying transactions in different categories using GUI elements) to a known method (i.e., transaction management) ready to provide predictable result (i.e., provide more insightful information about user’s transactions).
As per claim 22, Hendry teaches in response to receipt of the user inputted instruction, decreasing, by the management platform, a balance of the fund by the amount of the first transaction (see col 1 line 49-59, “retrieving the transaction data from the datastore and calculating the account balance using the transaction data, and providing the account balance”; see col 13 line 53 through col 14 line 23).
As per claim 23, Hendry does not teach wherein the updated graphical representation further comprises an updated expected indicator moved back on the updated plan bar by the amount of the first transaction.
Baggett teaches the updated graphical representation further comprises an updated expected indicator moved back on the updated plan bar by the amount of the first transaction (see paragraph 0034, “GUI may have a ‘New’, ‘Pending’, and ‘Completed’ category tabs to organize the payment disputes”; also see paragraph 0042; prior art teaches using a tab GUI element to separate different categories of transactions; bar and tab are interchangeable; see paragraph 0030, 0048, and 0056, prior art teaches displaying transaction amount).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Hendry with teaching from Baggett to include the updated graphical representation further comprises an updated expected indicator moved back on the updated plan bar by the amount of the first transaction. The modification would have been obvious, because it is merely applying a known technique (i.e., displaying updated transaction information) to a known method (i.e., transaction management) ready to provide predictable result (i.e., provide more insightful information about user’s transactions).
As per claim 24, Hendry teaches categorizing, by the transaction categorizer, transactions for the client into one of a plurality of categories (see col 16 line 22-55, “real time notifications about new purchases, including the amount of the purchase and the purchase category could be useful for managing budgets”).
As per claim 26, Hendry teaches assigning, by the container assigner, at least some of the transactions to one or more containers (see col 9 line 18-29, “long term storage system 604 may include one or more databases 628 that provide long term storage of all processed and pending transaction data”; see col 11 line 10-19, “Data structure 800 may include a ‘Status’ data field 819 that allows systems to record the status of a transaction, for example either ‘pending’ or ‘processed’; see col 16 line 4-15, “as soon as new scheduled payment is entered by a customer, the we bill pay system 2502 publishes a new event with the scheduled payment information…This data can then be stored, either in a temporary datastore, or in a long-term storage system, depending on the state of the transaction”; when no counterpart transaction is identified, the pending/scheduled transaction will remain in pending/scheduled pool, which can be interpreted as in a buffer; prior art teaches using a status data field, which can be interpreted as a flag, to indicate whether a transaction is in the pending/scheduled pool or the processed pool).
As per claim 27, Hendry teaches wherein a container of the one or more containers links two or more transactions together, comprises any rules applied to the two or more transactions, and includes a linkage to an asset (see col 7 line 18-27, “data enrichment services 130 can facilitate data cleaning 302, categorizing 304, classifying 306, authentication 308, and verification 310; see col 16 line 22-55, “Upon receiving enriched data event 2626, push notification service 2630 may send a message 2642 including enriched data to a user device 2640. In this case, the message includes information about the new grocery purchase”; linking two or more transactions together is categorizing/classifying transactions);
and providing, by the display engine, a life time machine screen to the user device for display in the GUI, wherein the life time machine screen is based on the linkage included in the container (see col 5 line 30-60, “Using this architecture, the entire lifecycle of a given financial transaction can be captured”; col 13 line 41-61, “This allows data consumers to query the event stream itself, or the separate data storage systems, to retrieve current and/or historical information about a financial transaction as it passes through its lifecycle between being created and eventually posting to an account”).
Claim(s) 25, 28, and 31-34 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hendry et al. (Patent No.: US 11,625,772), in view of Mori et al. (JP-4176181-B2), and further in view of Baggett (Pub. No.: US 2021/0158299) and Suresh et al. (Pub. No.: US 2003/0158751).
As per claim 25, Hendry does not teach wherein the transactions are categorized based on applying three tiers of categorization.
Suresh teaches the transactions are categorized based on applying three tiers of categorization (see paragraph 0061, “It will be appreciated that although three layers of classification are depicted in FIG. 1, any integral number of layers can from a hierarchical coded payment scheme 100”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Hendry with teaching from Suresh to include the transactions are categorized based on applying three tiers of categorization. The modification would have been obvious, because it is merely applying a known technique (i.e., applying three tiers categorization) to a known method (i.e., transaction management) ready to provide predictable result (i.e., to enhance clarity, manageability, and scalability).
As per claim 28, Hendry teaches receiving, by the management platform, a plurality of transactions associated with the client from the aggregator (see col 2 line 6-19, “The first subsystem is configured to receive transaction events in the event stream from a plurality of financial transaction processing systems”; see col 8 line 36-56 for transaction data aggregator; see col 9 line 50-60, “This data, which collectively may be referred to as enriched transaction data 664 is used by a data aggregator to provide real time enriched financial transaction data for consumption by end users”);
assigning, by the container assigner, at least some of the plurality of transactions
to containers based on container rules (see col 9 line 18-29, “long term storage system 604 may include one or more databases 628 that provide long term storage of all processed and pending transaction data”; see col 11 line 10-19, “Data structure 800 may include a ‘Status’ data field 819 that allows systems to record the status of a transaction, for example either ‘pending’ or ‘processed’; see col 16 line 4-15, “as soon as new scheduled payment is entered by a customer, the we bill pay system 2502 publishes a new event with the scheduled payment information…This data can then be stored, either in a temporary datastore, or in a long-term storage system, depending on the state of the transaction”; when no counterpart transaction is identified, the pending/scheduled transaction will remain in pending/scheduled pool, which can be interpreted as in a buffer; prior art teaches using a status data field, which can be interpreted as a flag, to indicate whether a transaction is in the pending/scheduled pool or the processed pool);
linking, by a linkage component stored in the non-transitory memory and executed by the processor, at least one container to an asset (see col 7 line 18-27, “data enrichment services 130 can facilitate data cleaning 302, categorizing 304, classifying 306, authentication 308, and verification 310; see col 16 line 22-55, “Upon receiving enriched data event 2626, push notification service 2630 may send a message 2642 including enriched data to a user device 2640. In this case, the message includes information about the new grocery purchase”; linking two or more transactions together is categorizing/classifying transactions); and
providing, by the display engine, an updated client dashboard to the user device
for display on the GUI of the user device, wherein the updated client dashboard includes an updated graphical representation of the plurality of transactions based on the associated categories and the assigned containers (see FIG. 20, prior art shows an account summary page, which could be interpreted as “client dashboard”; see col 13 line 53 through col 14 line 31, “The embodiments may enable real time account summary information by leverage enriched financial transaction data that is pushed to an event stream in real time”, and “Each of these data fields provided within account summary page 2002 may be determined dynamically when the customer loads the corresponding website or page within a mobile application”).
Examiner notes however Hendry does not teach categorizing, by the transaction categorizer, the plurality of transactions based on applying three tiers of categorization such that each transaction is associated with a category of a plurality of categories, wherein the three tiers of categorization applied to a first transaction of the plurality of transactions comprises a first tier of categorization based on applying a client rule when the client rule for the first transaction exists, a second tier of categorization based on applying a system rule when no client rule for the first transaction exists but the system rule for the first transaction exists, and a third tier of categorization based on applying a default categorization determined based on externally provided transaction information when no client rule or system rule exists for the first transaction.
Suresh teaches categorizing, by the transaction categorizer, the plurality of transactions based on applying three tiers of categorization such that each transaction is associated with a category of a plurality of categories, wherein the three tiers of categorization applied to a first transaction of the plurality of transactions comprises a first tier of categorization based on applying a client rule when the client rule for the first transaction exists, a second tier of categorization based on applying a system rule when no client rule for the first transaction exists but the system rule for the first transaction exists, and a third tier of categorization based on applying a default categorization determined based on externally provided transaction information when no client rule or system rule exists for the first transaction (see paragraph 0061, “It will be appreciated that although three layers of classification are depicted in FIG. 1, any integral number of layers can from a hierarchical coded payment scheme 100”).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Hendry with teaching from Suresh to include categorizing, by the transaction categorizer, the plurality of transactions based on applying three tiers of categorization such that each transaction is associated with a category of a plurality of categories, wherein the three tiers of categorization applied to a first transaction of the plurality of transactions comprises a first tier of categorization based on applying a client rule when the client rule for the first transaction exists, a second tier of categorization based on applying a system rule when no client rule for the first transaction exists but the system rule for the first transaction exists, and a third tier of categorization based on applying a default categorization determined based on externally provided transaction information when no client rule or system rule exists for the first transaction. The modification would have been obvious, because it is merely applying a known technique (i.e., applying three tiers categorization) to a known method (i.e., transaction management) ready to provide predictable result (i.e., to enhance clarity, manageability, and scalability).
As per claim 31, Hendry teaches wherein the at least one container links two or more transactions together, comprises any rules applied to the two or more transactions, and includes the linkage to the asset (see col 7 line 18-27, “data enrichment services 130 can facilitate data cleaning 302, categorizing 304, classifying 306, authentication 308, and verification 310; see col 16 line 22-55, “Upon receiving enriched data event 2626, push notification service 2630 may send a message 2642 including enriched data to a user device 2640. In this case, the message includes information about the new grocery purchase”; linking two or more transactions together is categorizing/classifying transactions).
Claim 32 is rejected for the same reason as claim 5.
Claim 33 is rejected for the same reason as claim 27.
As per claim 34, Hendry teaches providing, by the display engine, a life time machine screen to the user device for display on the GUI, wherein the life time machine screen is based on the investment information for the investment as well as additional asset to investment linkages (see col 5 line 30-60, “Using this architecture, the entire lifecycle of a given financial transaction can be captured”; col 13 line 41-61, “This allows data consumers to query the event stream itself, or the separate data storage systems, to retrieve current and/or historical information about a financial transaction as it passes through its lifecycle between being created and eventually posting to an account”).
Claim(s) 29-30 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hendry et al. (Patent No.: US 11,625,772), in view of Mori et al. (JP-4176181-B2), and further in view of Baggett (Pub. No.: US 2021/0158299) and Suresh et al. (Pub. No.: US 2003/0158751) and Fischer et al. (Patent No.: US 11,829,975).
As per claim 29, Hendry does not teach promoting, by a machine learning (ML) component stored in the non-transitory memory and executed by the processor, the client rule to a new system rule.
Fischer teaches promoting, by a machine learning (ML) component stored in the non-transitory memory and executed by the processor, the client rule to a new system rule (see col 8 line 43 through col 9 line 18, prior art teaches using learning algorithm to learn new rules for categorizing transactions).
It would have been obvious to one of ordinary skill in the art at the effective filing date of the present application to modify Hendry with teaching from Fischer to include promoting, by a machine learning (ML) component stored in the non-transitory memory and executed by the processor, the client rule to a new system rule. The modification would have been obvious, because it is merely applying a known technique (i.e., using learning algorithm to learn new rules for categorizing transactions) to a known method (i.e., transaction management) ready to provide predictable result (i.e., constantly improving transaction categorization).
As per claim 30, Hendry teaches receiving, from the aggregator, at least one transaction associated with a different client (see col 2 line 6-19, “The first subsystem is configured to receive transaction events in the event stream from a plurality of financial transaction processing systems”; see col 8 line 36-56 for transaction data aggregator; see col 9 line 50-60, “This data, which collectively may be referred to as enriched transaction data 664 is used by a data aggregator to provide real time enriched financial transaction data for consumption by end users”); and
categorizing, by the transaction categorizer, the at least one transaction based on applying the new system rule such that the at least one transaction is as
associated with a category of the plurality of categories (see col 16 line 22-55, “Upon receiving enriched data event 2626, push notification service 2630 may send a message 2642 including enriched data to a user device 2640. In this case, the message includes information about the new grocery purchase”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAO FU whose telephone number is (571)270-3441. The examiner can normally be reached 9:00 AM - 6:00 PM PST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christine M Behncke can be reached at (571) 272-8103. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HAO FU/Primary Examiner, Art Unit 3695
MAR-2026
Prosecution Insights