PATTERNS

Field of Invention

The present invention relates in general to the field of financial analysis, and more particularly, to a system and method for detecting and responding to transaction patterns.

Background Art

Without limiting the scope of the invention, its background is described in connection with financial analysis.

Prior art financial analysis systems and methods often analyze a user’s spending and provide recommendations based on third-party offers or a comparison to other users. The recommendations may relate to budgeting or spending categories. Other systems and methods analyze the user’s spending to provide targeted offers and/or advertising. However, these systems and methods do not identify patterns on recurring and sporadic non-recurring spending from transaction data and provide actions based on those patterns.

Summary of the Invention

The present invention uses principled data science techniques to identify time-based patterns in transaction data. These time-based patterns may include recurring transactions and non-recurring transactions. Spectral decomposition of the transaction data is one possible detection technique. Actions based on these time-based patterns are generated and performed.

In one embodiment of the present invention, a system for detecting and responding to transaction patterns includes one or more servers having one or more processors, one or more databases communicably coupled to the one or more servers, and one or more remote devices communicably coupled to the one or more servers. The one or more processors cause the one or more servers to: (a) identify one or more time-based patterns in a set of transaction data stored in the one or more databases corresponding to a data pair over a time period using a spectral decomposition of the set of transaction data, (b) classify the identified time-based pattern(s) into at least two pattern categories comprising a recurring transaction and a non-recurring transaction, (c) generate one or more actions for each pattern category, and (d) respond to the identified time-based pattern(s) by causing the one or more remote devices to perform the one or more actions. In another embodiment of the present invention, a computerized method for detecting and responding to transaction patterns includes providing one or more processors communicably coupled to a communications interface and one or more databases. One or more time-based patterns are identified in a set of transaction data stored in the one or more databases corresponding to a data pair over a time period using a spectral decomposition of the set of transaction data by the one or more processors. The identified time-based pattern(s) are classified into at least two pattern categories comprising a recurring transaction and a non recurring transaction using the one or more processors. One or more actions are generated for each pattern category using the one or more processors. The identified time-based pattern(s) are responded to by causing one or more remote devices communicably coupled to the one or more processors to perform the one or more actions via the communications interface.

In yet another embodiment of the present invention, a computerized method for detecting and responding to transaction patterns includes providing one or more processors communicably coupled to a communications interface and one or more databases. A set of transaction data is received, wherein each transaction data includes at least a user identifier, a recipient identifier or a sender identifier, a date and an amount. A data array of transactions corresponding to a data pair over a time period is created from the set of transaction data. The data array of transactions is stored in a first array data structure in the one or more databases. One or more time-based patterns are identified in the set of transaction data stored in the one or more databases corresponding to the data pair over the time period by projecting the set of transaction data into a frequency domain using a Fourier transformation and identifying any dominant frequencies within the frequency domain using the one or more processors. The identified time-based pattern(s) are classified into at least two pattern categories including a recurring transaction and a non-recurring transaction using the one or more processors, wherein any data pairs corresponding to the identified dominant frequencies, if any, are classified as the recurring transaction and any data pairs that do not correspond to the identified dominant frequencies are classified as the non-recurring transaction. One or more actions are generated for each pattern category using the one or more processors. The identified time-based pattern(s) are responded to by causing one or more remote devices communicably coupled to the one or more processors to perform the one or more actions via the communications interface.

In yet another embodiment of the present invention, a system for detecting and responding to transaction patterns includes one or more servers having one or more processors, one or more databases communicably coupled to the one or more servers, and one or more

2 remote devices communicably coupled to the one or more servers. The one or more processors cause the one or more servers to: (a) receive a set of transaction data, each transaction data comprising at least a user identifier, a recipient identifier or a sender identifier, a date and an amount; (b) create a data array of transactions corresponding to a data pair over a time period from the set of transaction data; (c) store the data array of transactions in a first array data structure in the one or more databases; (d) identify one or more time-based patterns in the set of transaction data stored in the one or more databases corresponding to the data pair over the time period by projecting the set of transaction data into a frequency domain using a Fourier transformation and identifying any dominant frequencies within the frequency domain using the one or more processors; (e) classify the identified time-based pattem(s) into at least two pattern categories comprising a recurring transaction and a non-recurring transaction using the one or more processors, wherein any data pairs corresponding to the identified dominant frequencies, if any, are classified as the recurring transaction and any data pairs that do not correspond to the identified dominant frequencies are classified as the non-recurring transaction; (f) generate one or more actions for each pattern category; and (g) respond to the identified time-based pattern(s) by causing the one or more remote devices to perform the one or more actions.

In addition, the present invention can be implemented as a non-transitory computer readable medium containing program instructions that cause one or more processors to perform a method for detecting and responding to transaction patterns as described above in reference to the computerized method.

In addition to the foregoing, various other method, system, and apparatus aspects are set forth in the teachings of the present disclosure, such as the claims, text, and drawings forming a part of the present disclosure.

The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail. Consequently, those skilled in the art will appreciate that this summary is illustrative only and is not intended to be in any way limiting. There aspects, features, and advantages of the devices, processes, and other subject matter described herein will become apparent in the teachings set forth herein.

Brief Description of the Drawings

For a more complete understanding of the features and advantages of the present invention, reference is now made to the detailed description of the invention along with the accompanying figures, in which:

3 FIG. 1 shows a block diagram of a system in accordance with an embodiment of the present invention;

FIG. 2 shows a flow chart of a computerized method in accordance with an embodiment of the present invention;

FIG. 3 shows a flow chart of a computerized method in accordance with another embodiment of the present invention;

FIG. 4 shows an example of array data for transactions between a merchant and a user over time;

FIG. 5 shows an example of a frequency domain representation of user and merchant transaction data;

FIGS. 6A-6B show an example of two categories of spending patterns: a monthly recurring pattern (FIG. 6A), and a mixed frequency pattern with no dominant frequency, representing a non-recurring pattern (FIG. 6B);

FIGS. 7A-7B show an example of two recommendations based on spectral filtering of spending patterns: filtering a specific recurring frequency through cancellation of the recurring charge (FIG. 7A), and removing the higher frequency spendings (FIG. 7B);

FIGS. 8A-8B show examples of suggestions and recommendations for specific transactions: suggestions to reduce specific sporadic but non-recurring transactions (FIG. 8 A), and requesting cancellation of specific recurring charges (FIG. 8B);

FIG. 9 shows a flow chart of an exemplary implementation of the present invention;

FIG. 10 shows a flow chart of a pattern determination method in accordance with another embodiment of the present invention;

FIG. 11 shows a flow chart of a computerized method in accordance with another embodiment of the present invention;

FIG. 12 shows a flow chart of a method for user income estimation in accordance with another embodiment of the present invention;

FIG. 13 is a block diagram of a system architecture or engine for income analysis in accordance with another embodiment of the present invention;

FIG. 14 is a graphical illustration of income prediction in accordance with another embodiment of the present invention;

4 FIG. 15 shows a flow chart of a method for discovering the merchant in transaction summaries from bank or credit card provider data in accordance with another embodiment of the present invention;

FIG. 16 shows a block diagram of a system for merchant discovery based on transaction data in accordance with another embodiment of the present invention; and

FIG. 17 shows a flow chart of a pattern determination method for entity discovery in accordance with another embodiment of the present invention.

Description of the Invention

Illustrative embodiments of the system of the present application are described below. In the interest of clarity, not all features of an actual implementation are described in this specification. It will of course be appreciated that in the development of any such actual embodiment, numerous implementation-specific decisions must be made to achieve the developer’s specific goals, such as compliance with system-related and business-related constraints, which will vary from one implementation to another. Moreover, it will be appreciated that such a development effort might be complex and time-consuming but would nevertheless be a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure.

The present invention uses principled data science techniques to identify time-based patterns in transaction data. These time-based patterns may include recurring transactions and non-recurring transactions. Spectral decomposition of the transaction data is one possible detection technique. Actions based on these time-based patterns are generated and performed. As will be described in more detail below, the present invention may include various analysis modules or features. For example, the analysis modules or features may include spending analysis, income analysis, merchant analysis, or any combination thereof.

Now referring to FIG. 1, a block diagram of a system 100 in accordance with an embodiment of the present invention is shown. The system 100 for detecting and responding to transaction patterns includes one or more servers 102 having one or more processors, one or more databases 104 communicably coupled to the one or more servers 102, and one or more remote devices 106 communicably coupled to the one or more servers 102 via one or more networks 108 or communication interfaces. The one or more processors cause the one or more servers to: (a) identify one or more time-based patterns in a set of transaction data stored in the one or more databases corresponding to a data pair over a time period using a spectral

5 decomposition of the set of transaction data, (b) classify the identified time-based pattern(s) into at least two pattern categories comprising a recurring transaction and a non-recurring transaction, (c) generate one or more actions for each pattern category, and (d) respond to the identified time-based pattern(s) by causing the one or more remote devices to perform the one or more actions. The system 100 may also include communications with other devices and systems 110, such as financial institutions, merchants, services, employers, third parties, etc.

All the devices within the system 100 can communicate with one another over various networks 108, such as public networks, private networks, local networks, wide area networks, wired connections, wireless connections, or any other form of known or unknown communication mechanism using known or unknown protocols. As will be appreciated by those of ordinary skill in the art, the system 100 can include other devices, components, modules, etc., and is not limited to the specific embodiments described herein in connection with the figures. Moreover, the server(s) 102 can be any type of processing or computing device using any combination of hardware and software suitable for performing the processes described herein. As will be appreciated by those of ordinary skill the art, the server(s) 102 can be multiple computers, multiple processors and may include many other components, devices and/or peripherals. Moreover, the server(s) 102 and the processes described herein can be implemented in a distributed architecture at multiple geographic locations. Likewise, processing can be shared or distributed between the server(s) 102 and the remote device(s) 106.

The remote device(s) 106 can include a server, computer, laptop computer, hand-held computing device, mobile communications device, electronic token, electronic wearable device (e.g., wrist watch, bracelet, glasses, etc.), transaction processing device (e.g., point-of-sale device, kiosk, cash register, credit/debit card machine, etc.) or a payment processing system. Note that other devices can be used. The transaction can be a purchase, a sale, a lease, a loan, an order, a payment, a deposit, a credit, a refund, an income, a transfer, a receipt or a barter exchange. Note that other types of transactions can be used. Moreover, the transaction can be a pending or proposed transaction awaiting approval or authorization. The one or more actions can include displaying a recommended course of action on the remote device(s) 106, displaying an alert or warning on the remote device(s) 106, displaying a prompt on the remote device(s) 106 to cancel or allow a pending transaction, the recurring transaction or the non-recurring transaction, or blocking the pending transaction, the recurring transaction or the non-recurring transaction until an override message is received from the remote device(s) 106. Moreover, the one or more actions can include: a countdown to the date for the future income transaction; blocking a

6 pending transaction, a recurring transaction or a non-recurring transaction whenever exceeds a threshold amount for the merchant name, the brand name or the category; or providing a reward, an accelerator or a bonus based on one or more criteria associated with the merchant name, the brand name or the category. Note that other types of actions can be used. Moreover, the one or more actions can execute other application(s) or software program(s) resident on the remote device(s) 106 or cause the remote device(s) 106 to communicate or interact with other devices with or without user interaction.

The one or more processors can cause the one or more servers to further perform one or more of the following:

select the data pair from at least one user identifier and at least one recipient identifier or sender identifier stored in a data structure in the one or more databases; or

select the data pair from the at least one user identifier and at least one transaction category stored in the data structure in the one or more databases; or

receive the transaction data comprising at least the user identifier, the recipient identifier or the sender identifier, a date and an amount, and store the transaction data in a data structure in the one or more databases; or

request the transaction data from one or more third party devices; or

assign a transaction category to the transaction data; or

create a data array of transactions corresponding to the data pair over the time period, wherein the set of transaction data comprises the data array of transactions, and store the data array of transactions in a first array data structure in the one or more databases; or

store the spectral decomposition of the set of transaction data in a second array data structure in the one or more databases; or

generate the one or more actions by selecting the one or more actions from a mapping of each pattern category to a set of actions in a pattern to action table stored in the one or more databases; or

store the one or more actions in a user action table in the one or more databases; or respond to the identified time-based pattem(s) by further querying the one or more actions in the user action table; or

7 receive a new transaction data corresponding to a new completed transaction, a new pending transaction or a new predicted transaction, and store the new transaction data in the data structure; or

add the new transaction data to the set of transaction data, and repeat the analyzing, classifying, generating and responding steps; or

generate one or more new actions whenever the new transaction data matches one or more of the pattern categories, or invokes one or more of the stored actions, and cause the one or more remote devices communicably coupled to the one or more processors to perform the one or more new actions via the communications interface; or

determine whether the recommended course of action was performed, send a congratulatory message to the one or more remote devices whenever the recommended course of action was performed, and send an alert message to the one or more remote devices whenever the recommended course of action was not performed; or

receive a cancellation message, which may include an authorization code, from the one or more remote devices in response to the prompt, and send a cancellation request to a third- party device for the pending transaction, the recurring transaction or the non-recurring transaction; or

receive an allow message from the one or more remote devices in response to the prompt, and send an authorization message to a third-party device for the pending transaction; or execute one or more applications on the one or more remote devices in response to the one or more actions; or

determine a geographic location of a user, and predict a destination location based on the geographic location of the user and one of the recurring transactions or one of the non-recurring transactions associated with the user, wherein the one or more actions are based on the destination location; or

modify or delete all or part of the transaction data based on an input from a user; or determine whether the transaction data comprises a payment transaction or an income transaction, wherein the income transaction comprises a transfer, a refund, a credit, a paycheck, a pension, a loan, or other income; or

estimate a monthly income based on one or more of the income transaction(s); or estimate a daily income based on one or more of the income transact! on(s); or

8 predict a date for a future income transaction based on the income transaction(s); or determine whether the future income transaction has been received, and the one or more actions comprise a notification that the future income transaction has been received on or before the date or has not been received by the date; or

sort all or part of the set of transaction data, determine a string matching score for each of the sorted transaction data, and group the stored transaction data based on the string matching scores; or

map the transaction data to one or more of a merchant name, a brand name and a category using a merchant database, and update the merchant database based on the transaction data; or

use a user data when mapping the transaction data; or

add or change the merchant name, the brand name or the category based on an input from a user; or

map the transaction data to a merchant name using a merchant database, determine a brand name for the merchant name, determine a category for the brand name or the merchant name, and update the merchant database based on the transaction data.

The user identifier can correspond to an individual, a group of individuals, a class of individuals, an entity, a group of entities, a class of entities, a unit within the entity, a group of units within the entity or a class of units within the entity. Note that other user identifiers can be used. The recipient identifier or sender identifier can correspond to a vendor, a merchant, a financial institution, a governmental entity, an employer, another individual, another group of individuals, another class of individuals, another entity, another group of entities, another class of entities, another unit within the entity, another group of units within the entity or another class of units within the entity. Note that other recipient identifiers can be used.

The spectral decomposition of the set of transaction data can include projecting the set of transaction data into a frequency domain using a Fourier transformation, and identifying any dominant frequencies within the frequency domain. The Fourier transformation can be computed using the following mathematical formula:

9 where n is a total number of the data pairs in the transaction set, a is a transaction amount, and t is a transaction date. The one or more processors can classify the identified time-based pattern(s) into the at least two pattern categories by: classifying any data pairs that correspond to the identified dominant frequencies, if any, as the recurring transaction; and classifying any data pairs that do not correspond to the identified dominant frequencies as the non-recurring transaction.

Referring now to FIG. 2, a flow chart of a computerized method 200 in accordance with an embodiment of the present invention is shown. The computerized method 200 for detecting and responding to transaction patterns includes providing one or more processors communicably coupled to a communications interface and one or more databases in block 202. One or more time-based patterns are identified in a set of transaction data stored in the one or more databases corresponding to a data pair over a time period using a spectral decomposition of the set of transaction data by the one or more processors in block 204. The identified time-based pattern(s) are classified into at least two pattern categories comprising a recurring transaction and a non-recurring transaction using the one or more processors in block 206. One or more actions are generated for each pattern category using the one or more processors in block 208. The identified time-based pattem(s) are responded to by causing one or more remote devices communicably coupled to the one or more processors to perform the one or more actions via the communications interface in block 210. As will be appreciated by those of ordinary skill the art, the steps described herein can be omitted or combined and that additional steps (not shown) can be added. In some circumstances, the steps can be performed simultaneously or in another order and/or repeated.

The remote device(s) can include a server, computer, laptop computer, hand-held computing device, mobile communications device, electronic token, electronic wearable device (e.g., wrist watch, bracelet, glasses, etc.), transaction processing device (e.g., point-of-sale device, kiosk, cash register, credit/debit card machine, etc.) or a payment processing system. Note that other devices can be used. The transaction can be a purchase, a sale, a lease, a loan, an order, a payment, a deposit, a credit, a refund, an income, a transfer, a receipt or a barter exchange. Note that other types of transactions can be used. Moreover, the transaction can be a pending or proposed transaction awaiting approval or authorization. The one or more actions can include displaying a recommended course of action on the one or more remote devices, displaying an alert or warning on the one or more remote devices, displaying a prompt to cancel or allow a pending transaction, the recurring transaction or the non-recurring transaction on the

10 one or more remote devices, or blocking the pending transaction, the recurring transaction or the non-recurring transaction until an override message is received from the one or more remote devices. Moreover, the one or more actions can include: a countdown to the date for the future income transaction; blocking a pending transaction, a recurring transaction or a non-recurring transaction whenever exceeds a threshold amount for the merchant name, the brand name or the category; or providing a reward, an accelerator or a bonus based on one or more criteria associated with the merchant name, the brand name or the category. Note that other types of actions can be used. Moreover, the one or more actions can execute other application(s) or software program(s) resident on the remote device(s) or cause the remote device(s) to communicate or interact with other devices with or without user interaction.

The method 200 can further include one or more of the following steps:

selecting the data pair from at least one user identifier and at least one recipient identifier or sender identifier stored in a data structure in the one or more databases; or

selecting the data pair from the at least one user identifier and at least one transaction category stored in the data structure in the one or more databases; or

receiving the transaction data comprising at least the user identifier, the recipient identifier or the sender identifier, a date and an amount, and storing the transaction data in a data structure in the one or more databases; or

requesting the transaction data from one or more third party devices; or

assigning a transaction category to the transaction data; or

creating a data array of transactions corresponding to the data pair over the time period, wherein the set of transaction data comprises the data array of transactions, and storing the data array of transactions in a first array data structure in the one or more databases; or

storing the spectral decomposition of the set of transaction data in a second array data structure in the one or more databases; or

generating the one or more actions by selecting the one or more actions from a mapping of each pattern category to a set of actions in a pattern to action table stored in the one or more databases; or

storing the one or more actions in a user action table in the one or more databases; or responding to the identified time-based pattern(s) by further querying the one or more actions in the user action table; or

11 receiving a new transaction data corresponding to a new completed transaction, a new pending transaction or a new predicted transaction, and storing the new transaction data in the data structure; or

adding the new transaction data to the set of transaction data, and repeating the analyzing, classifying, generating and responding steps; or

generating one or more new actions whenever the new transaction data matches one or more of the pattern categories, or invoking one or more of the stored actions, and causing the one or more remote devices communicably coupled to the one or more processors to perform the one or more new actions via the communications interface; or

determining whether the recommended course of action was performed, sending a congratulatory message to the one or more remote devices whenever the recommended course of action was performed, and sending an alert message to the one or more remote devices whenever the recommended course of action was not performed; or

receiving a cancellation message, which may include an authorization code, from the one or more remote devices in response to the prompt, and sending a cancellation request to a third- party device for the pending transaction, the recurring transaction or the non-recurring transaction; or

receiving an allow message from the one or more remote devices in response to the prompt, and sending an authorization message to a third-party device for the pending transaction; or

executing one or more applications on the one or more remote devices in response to the one or more actions; or

determining a geographic location of a user, and predicting a destination location based on the geographic location of the user and one of the recurring transactions or one of the non recurring transactions associated with the user, wherein the one or more actions are based on the destination location; or modifying or deleting all or part of the transaction data based on an input from a user; or determining whether the transaction data comprises a payment transaction or an income transaction, wherein the income transaction comprises a transfer, a refund, a credit, a paycheck, a pension, a loan, or other income; or

estimating a monthly income based on one or more of the income transaction(s); or

12 estimating a daily income based on one or more of the income transaction(s); or predicting a date for a future income transaction based on the income transaction(s); or determining whether the future income transaction has been received, and the one or more actions comprise a notification that the future income transaction has been received on or before the date or has not been received by the date; or

sorting all or part of the set of transaction data, determining a string matching score for each of the sorted transaction data, and grouping the stored transaction data based on the string matching scores; or

mapping the transaction data to one or more of a merchant name, a brand name and a category using a merchant database, and updating the merchant database based on the transaction data; or

using a user data when mapping the transaction data; or

adding or changing the merchant name, the brand name or the category based on an input from a user; or

mapping the transaction data to a merchant name using a merchant database, determining a brand name for the merchant name, determining a category for the brand name or the merchant name, and updating the merchant database based on the transaction data.

The user identifier can correspond to an individual, a group of individuals, a class of individuals, an entity, a group of entities, a class of entities, a unit within the entity, a group of units within the entity or a class of units within the entity. Note that other user identifiers can be used. The recipient identifier or sender identifier can correspond to a vendor, a merchant, a financial institution, a governmental entity, an employer, another individual, another group of individuals, another class of individuals, another entity, another group of entities, another class of entities, another unit within the entity, another group of units within the entity or another class of units within the entity. Note that other recipient identifiers can be used.

The spectral decomposition of the set of transaction data can include projecting the set of transaction data into a frequency domain using a Fourier transformation, and identifying any dominant frequencies within the frequency domain. The Fourier transformation can be computed using the following mathematical formula:

13 where n is a total number of the data pairs in the transaction set, a is a transaction amount, and t is a transaction date. The one or more processors can classify the identified time-based pattern(s) into the at least two pattern categories by: classifying any data pairs that correspond to the identified dominant frequencies, if any, as the recurring transaction; and classifying any data pairs that do not correspond to the identified dominant frequencies as the non-recurring transaction.

In addition, the present invention can be implemented as a non-transitory computer readable medium containing program instructions that cause one or more processors to perform a method for detecting and responding to transaction patterns as described above in reference to the computerized method.

Now referring to FIGS. 3-10, a non-limiting example of the present invention will be described in which patterns in spending behavior of a financial entity or person are discovered with the goal of providing financial recommendations based on their spending patterns. Note that any of the features described or shown in reference to FIGS. 3-10 can be implemented in the system 100 of FIG. 1 or the method 200 of FIG. 2.

FIG. 3 shows a flow chart of a method 300 in which a user's transaction data is received and stored as a data structure to be analyzed for identifying patterns in block 302. A spectral decomposition of transaction data is calculated, using Fourier transformation, to identify dominant frequencies (representing patterns) in the data in block 304. Then the patterns are classified into categories of recurring spendings and sporadic non-recurring spendings in block 306. A recommendation is assigned to each category of spendings and it is stored in a user insight table in block 308. This is done using a mapping from different types of patterns to suggested actions. The insights from the user insights table are used to send recommendation(s) to the application to be illustrated to the user in block 310.

Various examples of spectral decomposition of spending patterns will now be described.

As shown in the table below, customer transaction data can be represented as a structured database where each row represents a transaction with merchant information, amount of transaction as well as the date that the transaction was posted.

14

Table 1 : Data array representation for transactions between a merchant and a user over time.

As shown in FIG. 4, the transaction data for each customer is processed into a form of array of transactions between each merchant (e.g., Starbucks and the user), where each variable represents the value of the transaction for the merchant: $5.65 on 01-01-2017; $6.50 on 01-03- 2017; and $4.50 on 01-07-2017. This array is projected into Fourier domain by computing the following mathematical transformation on the transaction array:

where n is a total number of the data pairs in the transaction set, a is a transaction amount, and t is a transaction date.

For the example shown in Table 1 and Fig. 4, the mathematical transformation is:

F(d ) = 5.65 b ^_;w1 + 6.50 b ^_;w3 + 4.50 b^ ^w7 +. .. The decomposition provides different intensities for different frequencies (w) of spending as shown in FIG. 5 for the Starbucks example: 60 days; 30 days; 10 days; 5 days; and 1 day. Note that other transformation techniques can be used.

Thereafter, actions and recommendations are determined based on patterns as illustrated in FIGS. 6A-6B and 7A-7B. In this example, the spectral outcome is then classified into two categories, where the first includes cases identified as recurring with a certain frequency based on the spectrum and second involves cases where the spectrum is flat and doesn’t show and dominant frequency (recurrence).

The first case shown in FIG. 6A shows that the customer has a tendency to transact with a specific frequency (e.g., weekly or monthly), while the second case shown in FIG. 6B models a case where the customer doesn’t have a specific frequency and shows sporadic spending in different frequencies. For example, FIG. 6 A shows a dominant frequency at 30 days were the value is considerably higher than the values at 60 days, 10 days 5 days and 1 day. In contrast, FIG. 6B shows the values at the various frequencies, 60 days, 30 days, 10 days 5 days and 1 day,

15 are relatively similar to one another. The process then branches into two different responses. First, if there is a dominant frequency (e.g., 30 days), the process would flag that frequency 702 and provide a suggestion for the customer to reduce the recurrence of the specific spending as illustrated in FIG. 7A. Second, the process would give recommendations based on a high frequency filter, such as every day 752 as illustrated in FIG. 7B.

The process can also provide recommendations or suggestions to reduce spending on non-recurring transactions or cancelling bills that are recurring with an identified frequency. For the case of non-recurring transactions in which the user spends sporadically, the process provides recommendations on how to reduce that spending. FIGS. 8A-8B shows examples of suggestions and recommendations for specific transactions: suggestions to reduce specific sporadic but non-recurring transactions (FIG. 8A), requesting cancellation of specific recurring charges (FIG. 8B). As shown in FIG. 8A, exemplary spending suggestions 800 could display the merchant or vendor name, the approximate amount spent per time period and a suggestion to reduce the spending with an expected savings over a time period:

Starbucks 802a

$20/week 804a

“One less purchase each week will save you $50/month” 806a

Uber 802b

$70/month 804b

“One less ride each week will save you on average $40/month” 806b

Soulcycle 802c

$300/month 804c

“Two fewer classes per month will save you $400/year” 806c

As shown in FIG. 8B, exemplary recommendations for cancelling of recurring charges 850 could display the merchant or vendor name, the approximate amount spent per time period, the payment mechanism used and a“button” to select/click to cancel the recurring charge:

Netflix 852a

$143.88/year 854a

“Bill Pay - 1010 CA Dec 30, 2016” 856 “Cancel” 858a

16 Spotify 852b

$l20.00/year 854b “Cancel” 858b

Audible 852c

$275.40/year 854c

“Cancel” 858c.

Other information, data and actions can be displayed.

In this non-limiting example, the system is built on a separate server using customer transaction data as illustrated in the flow chart of FIG. 9. The system and method 900 are integrated with the client server 902 providing suggestions and important parameters to the application 904.

Transaction data 906 is processed into arrays of time points as illustrated in FIG. 4 which is stored in an array data structure in memory for optimizing processing time. The frequency domain transformation, shown in FIG. 5, is stored as an array data structure in the memory and analyzed further for patterns using the pattern discovery server 908. The pattern discovery server 908 matches the identified patterns to recommendations using the pattern to insights mapping table 910, which are stored in a user insights table 912 in a format such as is shown in the table below.

Table 2: Data structure for pattern to insight mapping. The user insights table 912 is queried by the client server 902 and the result is sent to the user application 904.

Now referring to FIG. 10, a non-limiting example of a flow chart of a pattern determination method 1000 is shown. The transaction data 906 is transformed into an array data structure in block 1002. Thereafter, the array is projected into the Fourier domain in block 1004 and pattern detection is performed in block 1006. The identified patterns are matched to

17 recommendations using the pattern to insights mapping table 910, and the recommendations are stored in the user insights table 912.

The system and method may also provide other features, such as geolocation to predict where the transaction will be taking place for non-recurring spendings and provide real time alerts and saving advice. In this case the process will be actively intervening as opposed to just providing recommendations. Moreover, the process can be integrated with the payment processing systems to send alerts when the user violates the recommended insights, which could be done by prompting the user to override a block of the transaction.

Referring now to FIG. 11, a flow chart of a method 1100 in accordance with an embodiment of the present invention is shown. The computerized method 1100 for detecting and responding to transaction patterns includes providing one or more processors communicably coupled to a communications interface and one or more databases in block 1102. A set of transaction data is received, wherein each transaction data includes at least a user identifier, a recipient identifier, a date and an amount in block 1104. A data array of transactions corresponding to a data pair over a time period is created from the set of transaction data in block 1106. The data array of transactions is stored in a first array data structure in the one or more databases in block 1108. One or more time-based patterns are identified in the set of transaction data stored in the one or more databases corresponding to the data pair over the time period by projecting the set of transaction data into a frequency domain using a Fourier transformation and identifying any dominant frequencies within the frequency domain using the one or more processors in block 1110. The identified time-based pattern(s) are classified into at least two pattern categories including a recurring transaction and a non-recurring transaction using the one or more processors, wherein any data pairs corresponding to the identified dominant frequencies, if any, are classified as the recurring transaction and any data pairs that do not correspond to the identified dominant frequencies are classified as the non-recurring transaction in block 1112. One or more actions are generated for each pattern category using the one or more processors in block 1114. The identified time-based pattem(s) are responded to by causing one or more remote devices communicably coupled to the one or more processors to perform the one or more actions via the communications interface in block 1116. Note that the computerized method 1100 can include can further include one or more of the additional step described above in reference to FIG. 2. As will be appreciated by those of ordinary skill the art, the steps described herein can be omitted or combined and that additional steps (not shown) can

18 be added. In some circumstances, the steps can be performed simultaneously or in another order and/or repeated.

The present invention can be implemented as a system 100 as described in reference to FIG. 1 that performs the computerized method described above in reference to FIG. 11.

In addition, the present invention can be implemented as a non-transitory computer readable medium containing program instructions that cause one or more processors to perform the computerized method described above in reference to FIG. 11.

Now referring to FIGS. 12-14, a non-limiting example of the present invention will be described in which patterns in user income are discovered and estimated using the transaction data. Income estimation is challenging since users can be paid through different payment cadences and they could have regular or non-regular income. Estimation of monthly income can be impacted by non-regularity leading to inferior results. With the techniques described herein, income is estimated and categorized into two types, regular-income (i.e., a recurring transaction) and non-regular-income (i.e., a non-recurring transaction). Note that any of the features described or shown in reference to FIGS. 12-14 can be implemented in the system 100 of FIG. 1 or the method 200 of FIG. 2.

Referring now to FIG. 12, a non-limiting example of a flow chart of a method 1200 for user income estimation from bank or credit card provider transaction data is shown. A user's transaction data is received and stored as a data structure to be analyzed for the entity in block 1202. A regular income dictionary 1204 and pattern NLP engine 1206 are a model used to map the transaction to a regular and non-regular income in block 1208. A monthly income is estimated in block 1210 by identifying the income matching to a month. Patterns of income payments are identified in block 1212. This data is used to update the pattern NLP engine 1206 and regular income dictionary 1204. A next paycheck time and amount is identified in block 1214, and the results are provided to the user in block 1216.

Any inflow money to non-credit accounts is either income or an internal-accounts transfer. Internal-account transfers are detected if they have the same amount (with a negative sign), same day of transaction, and different account IDs. An income transaction is either regular income or non-regular income. Regular income is detected if it is in the regular income category dictionary 1204.

Paycheck cycles are predicted for users and the days to arriving paycheck are shown in a countdown fashion. Make sure to catch the pending transaction and also tie a notification sent to

19 the user as soon as the paycheck hits the account. This enables users to clearly plan their upcoming big bills and manage their debt. Combined with the income estimation, the present invention provides a holistic picture of user’s incomes.

String similarity is used and the transaction names are tokenized using natural language processing libraries to identify regular paychecks vs non-regular paychecks. The regular paychecks tend to have a pattern and after cleaning up their names, they are very similar. Even in cases of job changes, we are able to pick up regular paychecks after the 2nd or 3rd paycheck.

Customer transaction data is represented as a structured database where each row represents a transaction with merchant information, amount of transaction and the date that the transaction was posted.

Table 3 : Transaction data for users and recipients/senders.

Regular incomes are detected using the engines described below and tagged in the database as regular incomes (i.e., a recurring transaction) and non-regular incomes (i.e., a non-recurring transaction).

Actions and recommendations based on this knowledge may include financial insights on spending and budgeting, days until next paycheck, and/or a targeting system. The categorization is used for predicting income to be used in safe to spend and other applications such as push notifications send to users on if they have been spending more than their income. Detection of the next date for income is used in a feature to present to user when is the next paycheck will come to user's account. Value of the income is used by targeting and personalization system. For example credit cards are targeted to a specific debt to income ratio. Income estimation is key for this type of targeting.

20 This methodology and system can be integrated into a complete user experience focused on ensuring users have an accurate picture of their finances by inputting correct monthly income value. Users may also receive notifications and insights when there spend falls outside of certain parameters defined on the income they make.

Now referring to FIG. 13, a non-limiting example of a block diagram of a system architecture or engine 1300 for income analysis is shown. The engine 1300 performs the following different steps. The first step is dependent on accurate categorization. With accurate categorization income transactions can be detected. Out of these candidate transactions, pattern recognition/spectral analysis is performed to filter out the ones that have a pattern in their reoccurance. These transactions are sorted alphabetically and and then grouped by their string matching scores. This provides the number of employers and their paycheck transactions. If there is a single employer, prediction of the next paycheck is performed considering things like business holidays, weekends, etc. The application then displays the countdown to the next paycheck date. If the paycheck (pending transaction) arrives earlier than the predicted date, the countdown is automatically skipped to let user know that they have been paid. The algorithms are updated regularly to adjust to various pay cycles, such as semi-monthly, biweekly, weekly, monthly, etc. The transaction names are sorted alphabetically first, which gives due importance to leading characters. String similarity is then used to cluster similar named transactions together. Within each bucket the pattern and the next paycheck date are predicted.

The transaction data 1302 undergoes an income detection process 1304 and an income type detection process 1306. The income detection process 1304 identifies the transaction data 1302 as an income transaction 1308 or a non-income transaction 1310. The income type detection process 1306 identifies the income transaction 1308 as non-regular income 1312 or regular income 1314. The income aggregator 1316 uses the non-regular income 1312 to estimate income. The income predictor 1318 uses the regular income 1314 to detect cadence and predict the next paycheck. The engine 1300 provides a user income list 1320, which can be verified by the user 1322, and is used by the ML Engine 1324 to provide a user regular income list 1326, which can also be verified by the user 1322.

The estimation technique for income estimation (Income Aggregator) 1316 will now be described. As shown in FIG. 14, income prediction is done for the duration after the last income transaction (the red area marked ?). Daily income is estimated by using regular income, since there is higher confidence that it will be recurring. Estimation is done by matching principle.

21 For example, the earnings P_l, P_2 and P_3 are matched to the duration d_l, d_2, d_3 and d_4, hence daily income is estimated with:

Daily income = (P_l + P_2 + P_3) / (d_l + d_2 + d_3 + d_4)

This methodology uses matching principles from accounting to match the interval that income is gained to the transactions that have been detected.

The estimation technique for cadence detection and next paycheck prediction (Income Predictor) 1318 will now be described. An algorithmic approach is used that uses day difference between different paychecks to identify the cadence of paychecks. This part is done after identifying the regularity of the paycheck using the NLP engine on the transaction details including name and type. The technique is novel in following ways:

1. Using sorting before string matching to build clusters of paycheck transactions.

There are two main observation. The first is that the leading characters in financial transaction carry a higher importance. Sorting is a lighter operation than performing string matching. Hence sorting before hands helps with avoiding doing NxN string matching operations.

2. On the sorted transactions, string matching operations are performed for each with its neighbour. When the string matching score drops, a cluster is formed with high accuracy of assuring that a cluster belongs to a single employer.

3. If the cluster has continuous and detectable pattern in its occurrence, its next occurrence can be predicted. This will work with various cadences like weekly, bi-weekly, monthly, semi-monthly, annual.

Various other features may include: an algorithm for identifying regular and non-regular income; a method for users to manually add or edit income; a method for estimating monthly income from transaction data; setting up an information system for storing the initial data, a query database for the estimated and inferred information and retrieval of the estimations; modeling based on learned data as an assumption free matching approach; allowing third-parties to access or otherwise benefit from the income information database; pulling the income information from a third-party; only receive income information from the user and do not estimate it; rely completely on users to update this information or extrapolate it from transactions but not combine both approaches; and/or not employ machine-learning informed by ongoing income provides and user transactions.

22 Referring now to FIGS. 15-17, a non-limiting example of the present invention will be described in which merchant knowledge discovery is performed using the transaction data. Identifying the merchant for a transaction is a known problem and users would use search engines such as Google to identify the merchant from the transaction-level data. This embodiment of the present invention identifyies the merchant names, called entities, for all user transactions and providing it through an application. This establishes a digital and online learning framework using the identified entities and categories based on individual user and crowdsourced labels. A pattern recognition algorithm and modeling technology are used to extrapolate entities from transaction-level and user-level data, and continuously update a merchant database and the algorithm based on new transactions. This approach leverages both user-level and transaction-level data as well as the actions the users take to proactively re categorize merchants within a digital interface or application. The same methodology is used to identify brands as well as categories for the entities. Note that any of the features described or shown in reference to FIGS. 15-17 can be implemented in the system 100 of FIG. 1 or the method 200 of FIG. 2.

Now referring to FIG. 15, a non-limiting example of a flow chart of a method 1500 for discovering the merchant in transaction summaries from bank or credit card provider data is shown. User's transaction data is received and stored as a data structure to be analyzed for the entity in block 1502. The transaction data is mapped to a known merchant using a model in block 1504. The brand for the merchant detected in block 1506 and the transaction is labeled for the merchant in blockl508. A category for the spending type can also be detected. The new data from transactions is used to update the learning engine in block 1510 and retrain the mapping model for merchant inference in block 1512. As such, a byproduct of this method would be a merchant database that is continuously updated and whereby the merchant category is continuously validated from transaction-level data.

Customer transaction data is represented as a structured database where each row represents a transaction with merchant information, amount of transaction and the date that the transaction was posted as previous shown and described in Table 1. Merchant knowledge is a set of inferred information about the merchant for that transaction. It has merchant entity, merchant brand and merchant category.

Various actions and recommendations based on merchant knowledge can be provided. For example, an information query system uses a summary engine that detects brands, entities and specific transactions through specific methods. These methods include running algorithms

23 against historical spend and leveraging inputs from users in the application. A targeting system can operate on three levels: entity/merchant, brand and category. As such, the methodology allows the identification and improvement over time these three levels of data. The merchant allows us to create a rich user-merchant many-to-many mapping. The mapping in turn is used to identity the user financial lifecycle, explore user to user and product to product similarities, and to generate personalized financial recommendations. The recategorization of merchants and transactions by user action in the application is used to inform the initial identification of merchants, brands and categories, as well as to update these over time. By constraining the transaction space onto the user-merchant domains, the transaction can be effectively categorized. This methodology and system can be integrated into a complete user experience focused on ensuring users have an accurate, holistic view of the finances; this view will include reporting by merchant type and spend category. Users may also receive notifications and insights when there spend falls outside of certain parameters by merchant or category.

Referring now to FIG. 16, a non-limiting example of a block diagram of a system 1600 for merchant discovery based on transaction data is shown. This system 1600 is built on a separate server using customer transaction data. The system 1600 is integrated with the client server 902 providing suggestions and important parameters to the application 904. Transaction data 906 is processed into arrays of time points as illustrated in FIG. 4 which is stored in an array data structure in memory for optimizing processing time. The frequency domain transformation, shown in FIG. 5, is stored as an array data structure in the memory and analyzed further for patterns using the entity detection system 1602. The entity detection system 1602 matches the identified patterns to recommendations using the pattern to crowd sourced entities 1604, which are stored in a user insights table 912.

Now referring to FIG. 17, a non-limiting example of a flow chart of a pattern determination method 1700 for entity discovery is shown. The transaction data 906 is matched with an existing entity in block 1702. Modeling detection for the entity is performed in block 1704, and brand and cluster mapping are performed in block 1706 using brand and clustering engine 1708. Recommendations are stored in the user insights table 912.

This embodiment of the present invention provides: an algorithm for identifying merchant, brand and category data based on transaction and user-level data, a method for users to manually add or edit merchant, brand and category data in a digital interface; a method for combining extrapolated merchant brand and category data with what users manually enter via a digital interface; setting up an information system for storing the initial data, a query database

24 for string the updated information and retargeting logic for prompting users to add, edit or recategorize merchant, brand and category information; automatically blocking certain spend— by merchant, brand or category— once users hit certain thresholds; rewarding users for crowd- sourcing; giving users accelerators or bonuses for reaching certain percent of spend goals by merchant, brand or category; and/or allowing third-parties to access or otherwise benefit from the merchant database. Other features may include: pulling the merchant, brand and category information from a third-party; focusing only on merchant, brand or category versus all three; relying completely on users to update this information or extrapolate it from transactions but not combine both approaches; not employ machine-learning informed by ongoing merchant and user transactions; and/or not use crowdsourcing from the actions users take to categorize merchants.

It will be understood that particular embodiments described herein are shown by way of illustration and not as limitations of the invention. The principal features of this invention can be employed in various embodiments without departing from the scope of the invention. Those skilled in the art will recognize, or be able to ascertain using no more than routine experimentation, numerous equivalents to the specific procedures described herein. Such equivalents are considered to be within the scope of this invention and are covered by the claims.

All publications and patent applications mentioned in the specification are indicative of the level of skill of those skilled in the art to which this invention pertains. All publications and patent applications are herein incorporated by reference to the same extent as if each individual publication or patent application was specifically and individually indicated to be incorporated by reference.

The use of the word“a” or“an” when used in conjunction with the term“comprising” in the claims and/or the specification may mean“one,” but it is also consistent with the meaning of “one or more,”“at least one,” and“one or more than one.” The use of the term“or” in the claims is used to mean“and/or” unless explicitly indicated to refer to alternatives only or the alternatives are mutually exclusive, although the disclosure supports a definition that refers to only alternatives and“and/or.” Throughout this application, the term“about” is used to indicate that a value includes the inherent variation of error for the device, the method being employed to determine the value, or the variation that exists among the study subjects.

As used in this specification and claim(s), the words“comprising” (and any form of comprising, such as“comprise” and“comprises”),“having” (and any form of having, such as “have” and“has”),“including” (and any form of including, such as“includes” and“include”) or

25 “containing” (and any form of containing, such as“contains” and“contain”) are inclusive or open-ended and do not exclude additional, unrecited elements or method steps. In embodiments of any of the compositions and methods provided herein,“comprising” may be replaced with “consisting essentially of’ or“consisting of.” As used herein, the phrase“consisting essentially of’ requires the specified integer(s) or steps as well as those that do not materially affect the character or function of the claimed invention. As used herein, the term“consisting” is used to indicate the presence of the recited integer (e.g., a feature, an element, a characteristic, a property, a method/process step, or a limitation) or group of integers (e.g., feature(s), element(s), characteristic(s), property(ies), method/process(s) steps, or limitation(s)) only.

The term “or combinations thereof’ as used herein refers to all permutations and combinations of the listed items preceding the term. For example,“A, B, C, or combinations thereof’ is intended to include at least one of: A, B, C, AB, AC, BC, or ABC, and if order is important in a particular context, also BA, CA, CB, CBA, BCA, ACB, BAC, or CAB. Continuing with this example, expressly included are combinations that contain repeats of one or more item or term, such as BB, AAA, AB, BBC, AAABCCCC, CBBAAA, CABABB, and so forth. The skilled artisan will understand that typically there is no limit on the number of items or terms in any combination, unless otherwise apparent from the context.

As used herein, words of approximation such as, without limitation, “about,” “substantial” or“substantially” refers to a condition that when so modified is understood to not necessarily be absolute or perfect but would be considered close enough to those of ordinary skill in the art to warrant designating the condition as being present. The extent to which the description may vary will depend on how great a change can be instituted and still have one of ordinary skill in the art recognize the modified feature as still having the required characteristics and capabilities of the unmodified feature. In general, but subject to the preceding discussion, a numerical value herein that is modified by a word of approximation such as“about” may vary from the stated value by at least ±1, 2, 3, 4, 5, 6, 7, 10, 12 or 15%.

All of the devices and/or methods disclosed and claimed herein can be made and executed without undue experimentation in light of the present disclosure. While the devices and/or methods of this invention have been described in terms of particular embodiments, it will be apparent to those of skill in the art that variations may be applied to the compositions and/or methods and in the steps or in the sequence of steps of the method described herein without departing from the concept, spirit and scope of the invention. All such similar substitutes and

26 modifications apparent to those skilled in the art are deemed to be within the spirit, scope, and concept of the invention as defined by the appended claims.

Furthermore, no limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope and spirit of the disclosure. Accordingly, the protection sought herein is as set forth in the claims below.

Modifications, additions, or omissions may be made to the systems and apparatuses described herein without departing from the scope of the invention. The components of the systems and apparatuses may be integrated or separated. Moreover, the operations of the systems and apparatuses may be performed by more, fewer, or other components. The methods may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order.

To aid the Patent Office, and any readers of any patent issued on this application in interpreting the claims appended hereto, applicants wish to note that they do not intend any of the appended claims to invoke paragraph 6 of 35 U.S.C. § 112 as it exists on the date of filing hereof unless the words“means for” or“step for” are explicitly used in the particular claim.

27