AU2019200919A1 - System and method for transaction tracking - Google Patents

Abstract

Embodiments generally relate to a method executed by a server system for tracking transactions. The method comprises receiving a request for transaction data from a 5 computing device, the transaction data relating to a user account; determining whether the user account is authorised to receive the transaction data; in response to determining that the user account is authorised to receive the transaction data, retrieving at least one of settled transaction data from a permanent transaction data store and pending transaction data from a transient transaction data store; wherein the settled transaction 10 data and the pending transaction data relate to the user account; and sending at least one of the retrieved settled transaction data and the retrieved pending transaction data to the computing device. Receive request for transaction summary Security gateway runs authorisation on request Request is valid? NO Send error response to eques user's computing device Execute core transaction manager to retrieve transaction data Execute transaction history aggregator to prepare transaction data Send prepared data to user's computing device Figure 2

Description

Methods and systems for transaction tracking

Technical Field

Embodiments generally relate to methods, devices and systems for transaction tracking. 5 In particular, described embodiments are directed to methods, devices and systems for automatic electronic tracking of transactions.

Background

Tracking transactions is important to many people as a way of monitoring spending and 10 helping people to stay within budgets and transaction limits. Some people choose to track transactions manually every time they make a purchase or take part in a transactions. However, this can be cumbersome and time consuming, and can result in mistakes and omissions in the records, as people may forget to record their transactions or may make errors in their recordings.

Throughout this specification the word comprise, or variations such as comprises or comprising, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each of the 25 appended claims.

It is desired to address or ameliorate one or more shortcomings or disadvantages associated with prior systems for transaction tracking, or to at least provide a useful alternative thereto.

Summary

Some embodiments relate to a method executed by a server system for tracking transactions, the method comprising:

receiving a request for transaction data from a computing device, the transaction data relating to a user account;

2019200919 08 Feb 2019 determining whether the user account is authorised to receive the transaction data;

in response to determining that the user account is authorised to receive the transaction data, retrieving at least one of settled transaction data from a permanent 5 transaction data store and pending transaction data from a transient transaction data store; wherein the settled transaction data and the pending transaction data relate to the user account; and sending at least one of the retrieved settled transaction data and the retrieved pending transaction data to the computing device.

According to some embodiments, the request is generated by a computing device executing an application performing transaction tracking functions.

According to some embodiments, the request for transaction data includes a time period range, and wherein only settled transaction data from the permanent transaction data store and pending transaction data from the transient transaction data store relating to 15 transactions initiated within the time period range is retrieved. In some embodiments, the date range is a 24 hour period that includes the time at which the request was sent.

In some embodiments, the settled transaction data and the pending transaction data are retrieved from the permanent transaction data store and the transient transaction data store by a transaction history aggregator executed by the server system. According to 20 some embodiments, the settled transaction data and the pending transaction data are retrieved from the permanent transaction data store and the transient transaction data store by a transaction history aggregator via a core transaction manager system.

According to some embodiments, the settled transaction data and the pending transaction data are retrieved in batches.

2019200919 08 Feb 2019

According to some embodiments, the retrieved settled transaction data and the retrieved pending transaction data are filtered based on transaction type prior to being sent to the computing device. In some embodiments, the retrieved settled transaction data and the retrieved pending transaction data are filtered to remove transactions performed between accounts associated with or belonging to the user account, and to remove crediting transactions that increase the balance of the user account.

Some embodiments further comprise, for each transaction that is specified by the pending transaction data and the settled transaction data, comparing pending transaction data stored in the transient transaction data store with settled transaction data stored in the permanent transaction data store, and determining whether the pending transaction data and the settled transaction data relate to the same transaction.

According to some embodiments, if the pending transaction data and the settled transaction data relate to the same transaction, only the settled transaction data is sent to the computing device.

According to some embodiments, if the pending transaction data does not have corresponding settled transaction data, the pending transaction data is sent to the computing device.

According to some embodiments, if the settled transaction data does not have corresponding pending transaction data, the settled transaction data is sent to the 20 computing device.

Some embodiments further comprise, for each transaction that is specified by the pending transaction data and the settled transaction data, comparing a pending transaction date of a transaction stored in the transient transaction data store with a settled transaction date for the same transaction stored in the permanent transaction data store, and determining which transaction date is correct.

2019200919 08 Feb 2019

In some embodiments, the correct transaction date is determined to be the earlier of the pending transaction date and the settled transaction date.

Some embodiments relate to a method of tracking transactions against a transaction limit, the method comprising:

sending a request for transaction data relating to the user account to a server system;

receiving at least one of settled transaction data and pending transaction data relating to the user account;

determining an aggregate transaction amount based on the received settled transaction data and pending transaction data; and comparing the aggregate transaction amount to a transaction limit stored in association with the user account.

According to some embodiments, the step of sending a request for transaction data relating to the user account to a server system occurs periodically.

According to some embodiments, the step of sending a request for transaction data relating to the user account to a server system occurs in response to receiving user input.

Some embodiments relate to a system for tracking transactions, the system comprising: a server system configured to perform the method of any one of claims 1 to 14;

and a transient transaction data store for storing transient transaction data relating to pending transactions; and a permanent transaction data store for storing permanent transaction data relating to settled transactions.

2019200919 08 Feb 2019

In some embodiments, the server system comprises a transaction history aggregator configured to retrieve data from the transient transaction data store and the permanent transaction data store.

Some embodiments relate to a computing device for tracking transactions, the system comprising:

at least one processer; and a memory device storing executable code accessible to the processor;

wherein when the at least one processor executes the code stored in the memory 10 device, the computing device is caused to:

send a request for transaction data relating to the user account to a server system;

receive settled transaction data and pending transaction data relating to the user account;

determine an aggregate transaction amount based on the settled transaction data and pending transaction data; and compare the aggregate transaction amount to a transaction limit stored in association with the user account.

Brief Description of Drawings

Embodiments are described in further detail below, by way of example and with reference to the accompanying drawings, in which:

Figure 1 shows a block diagram of a system 100 for transaction tracking;

Figure 2 shows a flowchart for a method of transaction tracking performed by system 100;

Figure 3 shows a block diagram of the software components of system 100;

Figure 4 shows a flowchart of a method of transaction tracking performed by the transaction history aggregator of Figure 2;

Figures 5A, 5B, 5C and 5D show a timing diagram of the interactions between the components of Figure 1;

Figure 6 shows an example screenshot of a home page of the application of Figure 1;

2019200919 08 Feb 2019

Figure 7 shows an example screenshot of an account page of the application of Figure 1;

Figure 8 shows an example screenshot of an inactive daily spend tracker page of the application of Figure 1;

Figure 9 shows an example screenshot of an active daily spend tracker page of the application of Figure 1;

Figure 10 shows an example screenshot of a daily budget page of the application of Figure 1;

Figure 11 shows an example screenshot of a daily spend tracker preferences page of the application of Figure 1;

Figure 12 shows an example screenshot of an account page of the application of Figure 1 with an active daily spend tracker;

Figure 13 shows an example screenshot of a detail view of the daily spend tracker of Figure 12;

Figure 14 shows an example screenshot of a detail view of the daily spend tracker of 15 Figure 12 showing a previous day’s daily spend tracker;

Figure 15 shows an example screenshot of a detail view of the daily spend tracker of Figure 12 showing a previous day’s transactions;

Figure 16 shows a number of display options for the daily spend tracker of Figure 12;

Figure 17 shows a number of display options for the emoticon style display option of

Figure 16; and

Figure 18 shows a number of display options for the orb style display option of Figure 16.

Detailed Description

Embodiments generally relate to methods, devices and systems for transaction tracking. In particular, described embodiments are directed to methods, devices and systems for automatic electronic tracking of transactions. Some embodiments relate to server processes for accurate tracking of the timing of transactions.

Figure 1 shows a system 100 for tracking transactions. System 100 includes a computing device 110 and a banking server system 120, in communication via a network 140. System 100 may also comprise one or more third party servers 130 in communication with banking server system 120 via network 140. In the illustrated embodiment, three third party servers, 130a, 130b and 130c, are shown. However, system 100 may include more or less third party servers.

2019200919 08 Feb 2019

Computing device 110 may be a mobile device, smart phone, tablet, laptop computer, desktop computer, or other computing device. Computing device 110 includes a processor 111 and a memory 112. Memory 112 may be accessible to processor 111, and may store data and executable code. Processor 111 may be configured to execute code 5 stored in memory 112. Code stored in memory 112 may include an operating system 113, and an application 114, which may be a transaction tracking application in some embodiments. In some embodiments, application 114 may be an internet browsing application allowing user to access a transaction tracking website hosted on banking server system 120.

Computing device 110 includes user I/O 115, which may include one or more of a display, keyboard, mouse, touch screen display, microphone, speaker, and camera. Computing device 110 also includes communications module 116, configured to communication with banking server system 120 via network 140. Communications 15 module 116 may be configured to communicate via wired and/or wireless communications protocols, which may include WiFi, Bluetooth, Ethernet, and USB, for example.

Network 140 is a publicly accessible network, which may include networks such as the 20 internet in some embodiments. According to some embodiments, network 140 may include private network components, public network components, and/or mobile telephony network components accessible to computing device 110.

Banking server system 120 may be operated by a bank or financial institution, and may 25 include one or more computing devices, servers, or server systems, and may be a cloud based server system in some embodiments. Server system 120 includes at least one processor 121 and memory 122. Processor 121 and memory 122 may comprise more than one processor and more than one memory location in some embodiments, and may be distributed across multiple servers within banking server system 120.

Memory 122 may be located across one or more devices or data stores. Memory 121 may store data and executable code, and may be accessible to processor 121. In particular, memory 121 may include a transient data store 125 and a permanent data store 126.

Memory 122 may also store executable code forming a core transaction manager system

124, a transaction history aggregator 123, and a security gateway 127. Processor 121 may be configured to access data stored in data stores 125 and 126, and to execute core

2019200919 08 Feb 2019 transaction manager system 124, transaction history aggregator 123, and security gateway 127.

Transient data store 125 may store transient data about pending transactions performed by users having accounts associated with banking server system 120, such as pending credit card authorisation data. For example, when a user makes a purchase at a merchant point-of-sale terminal, the information may be sent by the terminal to banking server system 120 via network 140. While the transaction is pending, prior to settlement of the transaction between the relevant financial institutions, the transaction data may be stored 10 in transient data store 125. According to some embodiments, the transaction data may include identification information of one or more of the merchants with whom the transaction was made, a location of the transaction as supplied by the merchant, a date and time of the transactions, and the amount of the transaction.

According to some embodiments, transient data store 125 may be structured as a database storing authorisation transaction records. In particular, records stored in transient data store 125 may contain data including a permanent account number (PAN) for the card making the transaction, an estimated purchase value for approval, merchant details, and a payment date.

Processor 121 may be configured to store transaction data in transient data store 125 where the payment record has been retrieved as an authorisation request only. The payment record may be received from the acquiring bank directly or via a payment network. Where processor 121 receives a settlement transaction from a merchant 25 including details of the purchase and the exact purchase value, processor 121 may be configured to store the transaction data to permanent data store 126, as described in further detail below.

When a settlement transaction is received, processor 121 may be configured to perform 30 a matching process, matching the received settlement transaction with an earlier authorisation request If a matching authorisation request record is found, the authorisation request data is moved by processor 121 to permanent data store 126. According to some embodiments, such as when the merchant, the payment card and the acquirer are with the same bank, the settlement transaction may occur substantially 35 immediately after the authorisation request, so that the transaction data is stored in transient data store 125 for only a brief amount of time. In some embodiments, the

2019200919 08 Feb 2019 settlement process may take longer, such as three to nine business days in some cases. In this case, the transaction data may be stored in transient data store 125 for the duration of the settlement process. According to some embodiments, if settlement hasn’t occurred after nine business days, the funds may be restored and the transaction record may be 5 deleted from transient data store 125.

Permanent data store 126 may store permanent or finalised data about posted or settled transitions performed by users having accounts associated with banking server system 120. For example, after a transaction occurs and transaction data is stored in transient 10 data store 125, the transaction may settle and/or be posted. A settlement transaction may then be recorded in permanent data store 126, and processor 121 may perform the transaction matching process as described above. The settlement transaction data may be recorded in permanent data store immediately after the transaction is settled, or the settlement transaction data may be recorded overnight where a batch processing of settled 15 transactions occurs.. Data stored in permanent data store 126 may be made available to the user in their monthly bank statement or online banking portal.

According to some embodiments, permanent data store 126 may be structured as a database storing authorisation transaction records. In particular, records stored in 20 transient data store 125 may contain data including a permanent account number (PAN) for the card making the transaction, an estimated purchase value for approval, merchant details, and a payment date.

Core transaction manager system 124 is responsible for receiving and processing 25 transactions from payment networks such as third party servers 130, including pending transactions and settled transactions. According to some embodiments, core transaction manager system 124 may only receive transaction data for transactions processed on the same day, which may be a calendar day or a business day in some embodiments. This may include data relating to pending retrieved from transient transaction data store 125, 30 as well as data relating to intraday settled transactions retrieved from permanent transaction data store 126, but not data relating to transactions posted on the previous day, for example.

Transaction history aggregator 123 is responsible for retrieving data from transaction data store 125 and permanent transaction data store 126 via core transaction manager system 124, aggregating transaction data retrieved by core transaction manager system

124, and preparing the data for presentation to a user via computing device 110. This

2019200919 08 Feb 2019 allows transaction history aggregator 123 to retrieve all transactions initiated within a particular time period, such as on the same day, for example. According to some embodiments, core transaction manager system 124 may retrieve transactions only made on the present day, and transaction history aggregator 123 may also retrieve transaction 5 data from CAP-CIS 504, as described in further detail below with reference to Figure 5, which may store transactions for a longer period of time. For example, according to some embodiments, CAP-CIS 504 may store transactions for up to 120 days.

According to some embodiments, transaction history aggregator 123 may filter 10 transactions received from core transaction manager system 124 based on the type of transaction, the originating account for the transaction, or destination account of the transaction. For example, transactions between the user’s own bank accounts may be disregarded. Transactions that credit the bank account may also be disregarded, as only spend amounts, or debited amounts, may be of interest. Time and date ranges may also 15 be applied to the retrieved data. According to some embodiments, transaction history aggregator 123 may also allocate correct transaction execution dates to retrieved transactions. In some cases, point of sale devices operated by merchants may be temporally out of sync, making transactions appear to have happened in the future or the past. Transaction history aggregator 123 may compare the execution date reported by the 20 point of sale device and stored in transient transaction data store 125 with the settlement date of the transaction stored in permanent transaction data store 126, and determine that the settlement date is the correct transaction date if the execution date is later than the settlement date. If the settlement date is later than the execution date, the execution date is determined to be the correct date.

Security gateway 127 may be an Internet Information Server (ISS), and is responsible for authenticating a user and validating a session between the user’s computing device 110 and the banking server system 120. Once a session is validated, security gateway 127 may allow for communication of data from transaction history aggregator 123 to 30 communications module 128 for transmitting to the user’s computing device 110. If the user is not successfully authenticated or the session is not validated, security gateway 127 may restrict the communication of data from transaction history aggregator 123 to communications module 128.

Security gateway 127 may authenticate a user based on a session ID presented to security gateway 127 within the HTTP request sent by the user’s computing device. Security

2019200919 08 Feb 2019 gateway 127 may be configured to check the session ID for validity with the issuing bank system, before forwarding the session ID to transaction history aggregator 123. The session may subsequently be validated when a user successfully authenticates the session by providing authorised user credentials, which may include a password, device token, 5 PIN, and/or biometrics such as face detection, retina scans, or fingerprint scans.

Security gateway 127 may further be configured to control access to any services offered by transaction history aggregator 123. The level of authentication required to access the services may be based on assurance levels. For example, where access is required to read10 only data available for processed transactions, access to the transaction history aggregator services may be provided based on a basic level of authentication being provided with a registered device.

• Does the security gateway control what information is transmitted from the THA 15 to a user device? Would there be different levels of authentication that allow different types of data to be transmitted?

Third party servers 130 may be scheme servers, such as VISA or MasterCard servers, merchant terminal servers, or other third party servers that are involved in recording 20 transactions made by a user using a credit card, debit card, or online payment system such as PayPal.

Figure 2 is a flowchart showing a method 200 for tracking and allowing access to payment transactions.

At step 210, banking server system 120 receives a request for a transaction summary from computing device 110, sent via network 140 and received at communications module 128. The request may be generated by computing device 110 when processor 111 is executing application 114, and a user uses user FO 115 to input a request for a 30 transaction summary for a given time period. For example, a user may wish to see a transaction summary for the current day. In some embodiments, the request may be generated by computing device 110 when processor 111 initiates application 114, to be displayed on a summary screen within application 114. According to some embodiments, application 114 may regularly or randomly poll banking server system 120 to request an 35 update on transactions performed by the user account associated with application 114.

2019200919 08 Feb 2019

At step 220, security gateway 127 of banking server system 120 runs authorisation and validation checks on the request. For example, security gateway 127 may determine whether the user is authorised to view the information requested, by checking whether the user has logged into application 114 with valid credentials. Credentials may include 5 passwords, PINs, or biometric credentials such as face detection, retina scans, or fingerprint scans, for example. Security gateway 127 may also check the ownership of the account requesting the information, to ensure they are authorised to view the information.

At step 230, security gateway 127 determines whether or not the request was valid. If the request was invalid, such as if incorrect credentials were provided or if the user account was not authorised to view the information, method 200 moves to step 270, where processor 121 causes communications module 128 to send an error response to computing device via network 140. Computing device 110 may receive the error message 15 via communications module 116, and processor 111 may display the error message to the user on user I/O 115.

If the request is determined to be a valid request at step 230, then method 200 moves to step 240. Processor 121 executes core transaction manager system 124 to retrieve 20 transaction data from transient transaction data store 125 and permanent transaction data store 126. As described above, transient transaction data store 125 may contain transaction data for pending transactions, and permanent transaction data store 126 may contain data for completed transactions. According to some embodiments, core transaction manager system 124 may only retrieve transaction data for transactions that 25 were initiated within same day as the request received at step 210. The same day may be a calendar day or a business day. For example, a day may be considered to be a 24 hours period from midnight to midnight.

At step 250, processor 121 executes transaction history aggregator 123 to aggregate and 30 collate the data retrieved by core transaction manager system 124, and to prepare the data for sending to computing device 110. Transaction history aggregator 123 may apply further filtering to the data to ensure only third party payment transactions are included, and not transactions between bank accounts of the user. According to some embodiments, transaction history aggregator 123 may sum the transactions aggregated 35 for the time period specified in the request, to determine a total spend by the user in the time period.

2019200919 08 Feb 2019

At step 260, processor 121 causes communications module 128 to send the transaction data aggregated by transaction history aggregator 123 to computing device 110. Computing device 110 receives the data via communications module 116 and displays 5 the data to the user via user I/O 115 as a page within application 114. According to some embodiments, computing device 110 may store one or more user defined budgets or transaction limits, as described in further detail below with reference to Figures 9 to 15, within memory 112. In some embodiments, one or more user defined budgets may be stored in memory 122 of banking server system 120. Processor 111 may compare the 10 budget retrieved from memory 112 or memory 122 with the total spend determined by transaction history aggregator 123, and may display this comparison to the user on user I/O 115 in a text based message, graphic or animation.

Figure 3 is a block diagram showing some of the components of an example of system 15 100 in further detail. In the illustrated embodiment, system 100 includes a public subnetwork 310, a private sub-network 320, and a corporate subnetwork 330. Private subnetwork 320 and corporate subnetwork 330 may be demilitarised zone type subnetworks in some embodiments.

Public sub-network 310 includes application 114, which may be an android application or an iOS application in some embodiments. Application 114 communicates with security gateway 120 to authorise and validate a communication session between application 114 and private subnetwork 320. Once communication has been established, security gateway 120 allows for communication between application 114 and transaction 25 history aggregator 123.

Private subnetwork 320 includes the transaction history aggregator 123, a channel agnostic router 322, mobile banking platform 336, corporate banking gateway 324, and semantic hub 326.

Channel agnostic router 322 may be an integration layer primarily used for message protocol transformation. According to some embodiments, channel agnostic router 322 may be built on IBM data power implementation.

Mobile banking platform 336 may be a FiServ BankAnywhere platform in some embodiments, and may allow for mobile banking transactions to be performed. Mobile

2019200919 08 Feb 2019 banking platform 336 may include a number of sub-platforms, such as a rich channel web services API for mobile applications, an authorisation platform for authorisations within the BankAnywhere channel servicing platform, and a policy decision point platform for determining what permissions a user logged into the mobile application may 5 have.

Corporate banking gateway 324 may be connected to a broker, and may be configured to pull transactional data from within the core systems of bank server system 120, such as from the core transaction manager system 124, and deliver this information to transaction history aggregator 123.

Semantic hub 326 may be configured to connect mobile banking platform 336 with the core systems of bank server system 120, such as by receiving data from the core transaction manager system 124, and delivering this information to mobile banking platform 336.

Corporate subnetwork 330 contains gateway 332, channel integration middleware 334, and core transaction manager 124. Gateway 332 may be a DataPower gateway configured to provide secure communications between transaction history aggregator 123 and core transaction manager system 123. Channel integration middleware 334 may 20 be integration middleware which communicates with legacy core systems such as the core transaction manager system 123 and allows for communication between core transaction manager system 123, semantic hub 326 and gateway 324. According to some embodiments, channel integration middleware 334 may be built on the IBM Message Broker 7 system.

Figure 4 shows a method 400 executed by transaction history aggregator 123 for tracking and making available a list of transactions to computing device 110. At step 402, transaction history aggregator 123 receives a request for a transaction history from computing device 110. As described above, this may be in response to a user initiating 30 or interacting with application 114, or it may be in response to a pre-determined interval of time passing since the last request was sent.

At step 404, transaction history aggregator 123 communicates with security gateway 127 to determine whether or not the request is valid. Security gateway 127 performs syntactical checks of the message, and checks the credentials of the user logged into application 114. If security gateway 127 determines that the request is not valid at step

2019200919 08 Feb 2019

406, method 400 moves to step 408, at which transaction history aggregator 123 generates an error response, and sends this to computing device 110 at step 436.

If the request is determined to be valid, at step 410 transaction history aggregator 123 invokes the API for channel agnostic router 322. At step 412, transaction history aggregator 123 checks whether or not the user is entitled to request the information, based on their account permissions. If the user is not entitled, method 400 moves to step 408, at which transaction history aggregator 123 generates an error response, and sends this to computing device 110 at step 436.

If the user is entitled, then at optional step 414 transaction history aggregator 123 determines the spend period selected by the user in their request. For example, the user may elect to request their transaction summary for the current day, week, month, or year. The user may be able to select their desired time period via options displayed on user I/O 15 115 of computing device 110. In some embodiments, the user may not be presented with an option to select a time period, and the system may default to providing the transaction summary for a predetermined time period. For example, in some embodiments, the system may default to providing the transaction summary for the present day.

At step 416, transaction history aggregator 123 determines whether this is the first request received from the user for the currently selected time period. If not, then it is assumed that a first set of posted transactions have already been fetched, and so at step 418 transaction history aggregator 123 fetches the next set of posted transactions from transient transaction data store 125 and permanent transaction data store 126 via core 25 transaction manager system 124. At step 420, transaction history aggregator 123 generates a success response with the fetched transactions, and at step 436 this response is sent to computing device 110.

If transaction history aggregator 123 determines at step 416 that this is the user’s first call for a transaction history within the determined period, then method 400 moves to 30 step 422, where transaction history aggregator 123 determines how many spend iterations are within the request. A spend iteration may be a group or page of transaction records.

If the number of spend iterations is equal to 0, at step 418 transaction history aggregator

123 fetches the next set of posted transactions from transient transaction data store 125 and permanent transaction data store 126 via core transaction manager system 124 and channel integration middleware 334. At step 420, transaction history aggregator 123

2019200919 08 Feb 2019 generates a success response with the fetched transactions, and at step 436 this response is sent to computing device 110.

If the number of spend iterations is more than 0, at step 424 all pending transactions are 5 retrieved from transient transaction data store 125 and permanent transaction data store

126 via core transaction manager system 124 and channel integration middleware 334. According to some embodiments, pending transactions may be fetched in batches. For example, in some embodiments pending transactions may be fetched in batches of around 25, 50, 75 or 100 transactions.

At step 426, transaction history aggregator 123 continues to retrieve all posted transactions until the last iteration date selected by the user is reached. At step 428, transaction history aggregator 123 determines whether the current time is within the batch run period. If it is, then at step 430 transaction history aggregator 123 creates a 15 success response including all of the fetched transactions, and a warning message to say that the real time tracking system is currently unavailable. The response may include all pending transactions, and all fetched posted transactions. The response is sent to computing device 110 at step 436.

If the current time is not within the batch run period, at step 432 transaction history aggregator 123 calculates all spend iterations within the batch run period. At step 434 transaction history aggregator 123 creates a success response including all of the fetched transactions and aggregate spends. The response may include all transactions relating to spends made by the user, all pending transactions, and all fetched posted transactions.

The response is sent to computing device 110 at step 436.

Figures 5A, 5B, 5C and 5d show sections of a timing diagram 500 showing interactions between the components of Figures 1 and 3. Figure 5 A connects to the left of Figure 5B and above Figure 5C, Figure 5B connects to the right of Figure 5A and above Figure 30 5D, Figure 5C connects to the left of Figure 5D and below Figure 5A, and Figure 5D connects to the right of Figure 5C and below Figure 5B.

Application 114 communicates with security gateway 127 to establish a connection with banking server system 120. Security gateway 127 communicates with mobile banking platform 336 to check that the request made by application 114 is valid, and that the user has entitlement to access the relevant information. If mobile banking platform 336 determines that the request is valid and the user is entitles, this response is returned to

2019200919 08 Feb 2019 security gateway 127, which opens a mobile banking session between application 114 and banking server system 120. Security gateway 127 communicates with channel agnostic router 322, transaction history aggregator 123, semantic hub 326, channel integration middleware 334, core transaction manager 124, Media and Communications 5 Processor 502, gateway 332 and CAP-CIS 504 to retrieve and return the aggregated transactions to application 114. CAP-CIS 504 may be a customer information store, storing customer information, in some embodiments.

Figure 6 shows an example screenshot 600 that may be displayed on a user interface of 10 computing device 110 when executing application 114. Screenshot 600 shows a number of user bank accounts 610, 650, 660 and 670, with user bank account 610 being highlighted. Details of bank account 610, including an available balance 614 and a current balance 616, are displayed. Selectable options 620, 630 and 640 allow a user to perform actions with respect to bank account 610, such as transferring funds from bank 15 account 610, paying a person or entity from bank account 610, or viewing more options.

Selectable option 612 allows a user to view more details about bank account 610.

Selectable option 612 may include elements of displayed bank account 610, such as the bank account name.

If a user selects option 612, processor 111 executing application 114 may cause the user interface of computing device 110 to display example screenshot 700, as shown in Figure 7. Screenshot 700 also displays bank account 610, available balance 614, current balance 616, and selectable options 620, 630 and 640. Screenshot 700 further displays selectable tabs 710, 720 and 730, which allow a user to select between a transactions view, a statements view, and a manage view, respectively. Transactions tab 710 is illustrated as selected. Statements tab 720 may allow a user to view their monthly statements for bank account 610, and manage tab 730 may allow a user to manage preferences for bank account 710.

When transactions tab 710 is selected or becomes active, a daily spend tracker 740 is shown, along with a number of transactions 760 and 780 listed under specific dates 750 and 770. According to some embodiments, transactions tab 710 may become active as a default when screenshot 700 is loaded. As illustrated, daily spend tracker 740 is shown as disabled, with no transaction tracking figures being displayed. Selecting daily spend tracked 740 may cause processor 111 to cause a daily spend tracker screen to be displayed

2019200919 08 Feb 2019 on the user interface of computing device 110, allowing a user to activate the daily spend tracker. An example screenshot 800 is shown in Figure 8.

Screenshot 800 shows daily spend tracker 740 and selectable option 810. Selectable option 810 may be togglable by the user via user I/O 115 to opt between activating and deactivating daily spend tracker 740. A user may activate done button 820 if they wish to return to screen 700.

If a user interacts with selectable option 810, daily spend tracker 740 may be activated, as shown in example screenshot 900 as illustrated in Figure 9. Figure 9 shows daily spend tracker 740, done button 820 and selectable option 810 as described above. However, selectable option 810 is activated, and screenshot 900 further shows a daily budget option 910. Selecting daily budget option 910 allows a user to set a daily budget for their spending with respect to bank account 610.

Selecting daily budget option 910 may cause processor 111 to display a daily budget screen on the user interface of computing device 110. An example of a daily budget screen 1000 is shown in Figure 10.

Screenshot 1000 shows a number of selectable options 1010 and 1020 relating to the days of the week. Options 1010 are highlighted as being selected in the illustrated embodiment, while options 1020 are shown as being deselected. Selected options 1010 show that the user has elected to have a daily budget set for Monday, Tuesday, Wednesday and Thursday of every week, in the illustrated embodiment. Text entry box 25 1030 allows a user to set their daily budget for the selected days, which in this case is shown to be $100. The selected days and the input budget may be stored by processor 111 in memory 112.

Screenshot 1000 also shows a back button 1040. Selecting back button 1040 may cause 30 computing device 110 to go back to screenshot 900, if the user has not made any selections of days for their daily budget. If a user has selected the days and spend amount for their daily budget, pressing back button 1040 may cause computing device 110 to display screenshot 1100, as shown in Figure 11.

Screenshot 1100 shows daily spend tracker 740 and activated selectable option 810 as in Figure 8. However, since screenshot 1100 is displayed when a daily budget has been set,

2019200919 08 Feb 2019 screenshot 1100 also shows daily budget display preferences 1110 and the daily budget details 1140. Daily budget details 1140 may display the selected days for applying the daily budget, and the amount set for the daily budget, as selected on screen 1000.

Daily budget preferences 1110 may allow a user to select between different display options for their daily budget. For example, option 1120 may show their daily budget represented as an animation of an orb filled with a liquid, with the orb becoming emptier and the liquid changing colour as the daily budget is reached or exceeded. Option 1130 may show the daily budget displayed as an animation of an emoticon, with the emoticon 10 expressions changing from joyful to sad as the daily budget is reached or exceeded.

Screenshot 1100 also shows selectable option 1150, allowing a user to add a new daily budget. Selecting option 1150 may cause screenshot 1000 to be displayed again, for a user to add new daily budget details. For example, a user may wish to set two daily 15 budgets, with one applying to weekends, and one applying to weekdays. In some embodiments, a user may wish to set three or more daily budgets, with each budget applying to set days of the week.

Screenshot 1100 further displays a done button 1160. Once a daily budget has been set, 20 selecting done button 1160 may cause computing device 110 to display screenshot 1200, as shown in Figure 12.

Screenshot 1200 is similar to screenshot 700, and also displays bank account 610, available balance 614, current balance 616, selectable options 620, 630 and 640, 25 selectable tabs 710, 720 and 730, transactions 760 and 780 and dates 750 and 770.

However, a new daily spend tracker 1210 is displayed, showing that the spend tracker has been enabled and that a daily budget has been set. Daily spend tracker 1210 is populated by information generated by transaction history aggregator 123, and shows the amount remaining from the daily budget set by the user once the transactions performed 30 by the user that day have been subtracted from the budget. As both transient transaction data from data store 125, and permanent transaction data from data store 126 is taken into account, daily spend tracker 1210 can show an accurate real-time budget tracking amount. According to some embodiments, application 114 may be configured to poll banking server system 120 at regular intervals for the latest transaction information, so 35 that daily spend tracker 1210 always shows an accurate figure. Both pending and settled

2019200919 08 Feb 2019 transactions may be used to calculate the remaining budget to be displayed on daily spend tracker 1210.

Figure 13 shows example screenshot 1300, which may be displayed when a user selects 5 daily spend tracker 1210 on screen 1200. Screenshot 1300 shows daily spend tracker 1210, as well as details about the user’s daily spend, such as their set budget 1310, the amount they have spent 1320, and any amount remaining on their budget 1330. Screenshot 1300 also shows an edit daily budget button 1340, which, if selected, may cause computing device 110 to display screenshot 1000, allowing the user to edit their 10 budget details. Screenshot 1300 also displays transactions 760 listed under the date 750 on which they occurred.

According to some embodiments, a user may be able to scroll down the transactions 760 to see information about transactions performed on another date. For example, screenshot 15 1400 in Figure 14 shows yesterday’s daily spend tracker 1410 under yesterday’s date

770. Screenshot 1400 also shows daily spend tracker 1210, set budget 1310, amount spent 1320, amount remaining 1330 and transactions 760. In the illustrated embodiment, some of transactions 760 are listed as pending transactions, which is highlighted to the user by use of the word “pending” next to the transaction.

Clicking on yesterday’s daily spend tracker 1410 may cause computing device 110 to display screenshot 1500, as shown in Figure 15. Screenshot 1500 may show daily spend tracker 1210, set budget 1310, amount spent 1320, amount remaining 1330, transactions 760, yesterday’s date 770 and yesterday’s daily spend tracker 1410. Screenshot 1500 also 25 shows yesterday’s transactions 780. According to some embodiments, transactions may be listed in chronological order based on the time at which they were processed, in order of amount, or in another order. According to some embodiments, the order in which the transactions are displayed may be selectable by the user.

Figure 16 shows a number of forms of daily spend tracker that may be displayed by computing device 110 executing application 114. Daily spend tracker 740 may be displayed when no daily spend tracker is activated. Daily spend tracker 1610 may be displayed when a daily spend tracker is activated, but no display customisations have been selected. Daily spend tracker 1620 may be displayed when the orb style daily spend 35 tracker has been enabled by selecting option 1120 on screenshot 1100. Daily spend

2019200919 08 Feb 2019 tracker 1210 may be displayed when the emoticon style daily sped tracker has been selected by selecting option 1130 on screenshot 1100.

Figure 17 shows a number of example daily spend tracker options for display on display tracker 1210 when the emoticon style daily spend tracker has been selected by selecting option 1130 on screenshot 1100. Option 1710 may be displayed when the budget remaining exceeds a high threshold, showing that a large amount of the budget still remains. Option 1720 may be displayed when the remaining budget is under the high threshold, but exceeds a medium threshold, indicating that a decent amount of the user’s 10 budget still remains. Option 1730 may be displayed when the remaining budget is under the medium threshold, but exceeds a low threshold, indicating that only a small amount of the user’s budget still remains. According to some embodiments, option 1730 may also be displayed when the budget set by the user exceeds the balance remaining in the user’s account. Option 1740 may be displayed when the user has exceeded their budget 15 by a relatively small amount. Option 1750 may be displayed when the user has exceeded their budget by a relatively large amount. Option 1760 may be displayed when the daily budget tracker is not active, which may be overnight, for example. Option 1770 may be displayed when there is an error accessing banking server system 120 to retrieve the transaction data required to calculate the daily budget data.

According to some embodiments, the emoticon style daily spend tracker may show stationary emoticon images such as those shown in Figure 17. In some embodiments, the emoticons may be animations that change in appearance over time. According to some embodiments, the emoticons may be interactive virtual objects or virtual characters, that 25 may react to input being provided by the user. A number of emoticons are shown and described in further detail below with reference to Figure 19.

Figure 18 shows a number of example daily spend tracker options for display on display tracker 1620 when the orb style daily sped tracker has been selected by selecting option 30 1120 on screenshot 1100. Option 1810 may be displayed when the budget remaining exceeds a high threshold, showing that a large amount of the budget still remains. Option

1820 may be displayed when the remaining budget is under the high threshold, but exceeds a medium threshold, indicating that a decent amount of the user’s budget still remains. Option 1830 may be displayed when the remaining budget is under the medium threshold, but exceeds a low threshold, indicating that only a small amount of the user’s budget still remains. Option 1840 may be displayed when the user has exceeded their

2019200919 08 Feb 2019 budget by a relatively small amount. Option 1850 may be displayed when the user has exceeded their budget by a relatively large amount. Option 1860 may be displayed when the daily budget tracker is not active, which may be overnight, for example. Option 1870 may be displayed when there is an error accessing banking server system 120 to retrieve 5 the transaction data required to calculate the daily budget data.

As described above with reference to Figure 17, when the emoticon style daily spend tracker has been selected by selecting option 1130 on screenshot 1100, display tracker 1210 may display an emoticon, which may be a virtual character or virtual object. 10 According to some embodiments, the emoticon may be configured as an animated virtual object that changes appearance over time. For example, the emoticon may be configured to cycle through one or more animation stages. According to some embodiments, each animation stage may cause the emoticon to appear to change expression or to perform an action. A number of different animation stages are illustrated in Figure 19.

Figure 19 shows emoticons 1910 to 1968. While the emoticons are shown in a particular position, each image represents an animation sequence that may be adopted by the emoticon.

Emoticons 1910, 1912 and 1914 represent animation sequences that may correspond to option 1710 of Figure 17. For example, emoticon 1910 represents a sequence whereby the emoticon puts on a pair of sunglasses, and emoticon 1920 represents a sequence whereby the emoticon fans itself with a stack of cash. These animation sequences may be displayed when the budget remaining exceeds a high threshold, showing that a large 25 amount of the budget still remain.

Emoticons 1920, 1922, 1924, 1926 and 1928 represent animation sequences that may correspond to option 1720 of Figure 17. For example, emoticon 1920 represents a sequence whereby the emoticon adopts a pleased or satisfied expression, and emoticon 30 1922 represents a sequence whereby the emoticon adopts a wide grin. These animation sequences may be displayed when the remaining budget is under the high threshold, but exceeds a medium threshold, indicating that a decent amount of the user’s budget still remains.

Emoticons 1930, 1932, and 1934 represent animation sequences that may correspond to option 1730 of Figure 17. For example, emoticon 1930 represents a sequence whereby

2019200919 08 Feb 2019 the emoticon adopts a nervous grin and starts sweating, and emoticon 1922 represents a sequence whereby the emoticon puts on a fake, anxious smile. These animation sequences may be displayed when the remaining budget is under the medium threshold, but exceeds a low threshold, indicating that only a small amount of the user’s budget still 5 remains. According to some embodiments, these animation sequences may also be displayed when the budget set by the user exceeds the balance remaining in the user’s account.

Emoticons 1940, 1942, 1944, 1946 and 1948 represent animation sequences that may 10 correspond to option 1740 of Figure 17. For example, emoticon 1940 represents a sequence whereby the emoticon holds up their hand in a stop sign position, and emoticon 1922 represents a sequence whereby the emoticon holds up a stop sign. These animation sequences may be displayed when the user has exceeded their budget by a relatively small amount.

Emoticons 1950, 1952, 1954, and 1956 represent animation sequences that may correspond to option 1750 of Figure 17. For example, emoticon 1950 represents a sequence whereby the emoticon starts crying, and emoticon 1922 represents a sequence whereby the emoticon appears dizzy or ill. These animation sequences may be displayed 20 when the user has exceeded their budget by a relatively large amount.

Emoticons 1962, 1964, and 1966 represent animation sequences that may correspond to option 1760 of Figure 17. For example, emoticon 1962 represents a sequence whereby the emoticon is asleep with a nightcap on. These animation sequences may be displayed 25 when the daily budget tracker is not active, which may be overnight, for example.

Emoticons 1960, and 1968 show animation stages that may correspond to option 1770 of Figure 17. For example, emoticon 1960 represents a sequence whereby the emoticon appears dead, and emoticon 1968 represents a sequence whereby the emoticon holds up 30 a warning sign. These animation sequences may be displayed when there is an error accessing banking server system 120 to retrieve the transaction data required to calculate the daily budget data.

According to some embodiments, the emoticon may iterate though the animation sequences appropriate to the emoticon state at random.

2019200919 08 Feb 2019

According to some embodiments, the displayed emoticons may also interact with user input received by user I/O 115 of computing device 110. For example, a user may be able to interact with the emoticon by touching, pressing or swiping along a display screen of computing device 110, by gesturing at a camera of computing device 110, by speaking 5 into a microphone of computing device 110, or by activating an accelerometer of computing device 110 by moving, tilting or shaking computing device 110. According to some embodiments, swiping across an interaction regions of the display of computing device 110 may cause the emoticon to spin. Swiping at or above a predetermined rate, which may be 2 swipes per second in some embodiments, may cause the emoticon to 10 appear dizzy or ill, as shown by emoticon 1952, for example. According to some embodiments, display tracker 1210 may be the interaction region.

In some embodiments, touching or tapping the displayed emoticon may cause the emoticon to fall over, as illustrated by emoticon 1956. According to some embodiments, 15 this animation sequence may be accompanied by computing device 110 providing some tactile feedback, such as a vibration. According to some embodiments, one or more animation sequences may be accompanied by a sound emitted by computing device 110.

It will be appreciated by persons skilled in the art that numerous variations and/or 20 modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.

Claims (22)

1. CLAIMS:

   1. A method executed by a server system for tracking transactions, the method comprising:

   5 receiving a request for transaction data from a computing device, the transaction data relating to a user account;

   determining whether the user account is authorised to receive the transaction data;

   in response to determining that the user account is authorised to receive

   10 the transaction data, retrieving at least one of settled transaction data from a permanent transaction data store and pending transaction data from a transient transaction data store; wherein the settled transaction data and the pending transaction data relate to the user account; and sending at least one of the retrieved settled transaction data and the

   15 retrieved pending transaction data to the computing device.
2. 2. The method of claim 1, wherein the request is generated by a computing device executing an application performing transaction tracking functions.
3. 3. The method of claim 1 or claim 2, wherein the request for transaction data includes a time period range, and wherein only settled transaction data from the

   20 permanent transaction data store and pending transaction data from the transient transaction data store relating to transactions initiated within the time period range is retrieved.
4. 4. The method of claim 3, wherein the date range is a 24 hour period that includes the time at which the request was sent.

   2019200919 08 Feb 2019
5. 5. The method of any one of claims 1 to 4, wherein the settled transaction data and the pending transaction data are retrieved from the permanent transaction data store and the transient transaction data store by a transaction history aggregator executed by the server system.

   5
6. 6. The method of claim 5, wherein the settled transaction data and the pending transaction data are retrieved from the permanent transaction data store and the transient transaction data store by a transaction history aggregator via a core transaction manager system.
7. 7. The method of any one of claims 1 to 6, wherein the settled transaction data 10 and the pending transaction data are retrieved in batches.
8. 8. The method of any one of claims 1 to 7, wherein the retrieved settled transaction data and the retrieved pending transaction data are filtered based on transaction type prior to being sent to the computing device.
9. 9. The method of claim 8, where the retrieved settled transaction data and the

   15 retrieved pending transaction data are filtered to remove transactions performed between accounts associated with or belonging to the user account, and to remove crediting transactions that increase the balance of the user account.
10. 10. The method of any one of claims 1 to 9, further comprising, for each transaction that is specified by the pending transaction data and the settled transaction

    20 data, comparing pending transaction data stored in the transient transaction data store with settled transaction data stored in the permanent transaction data store, and determining whether the pending transaction data and the settled transaction data relate to the same transaction.
11. 11. The method of claim 10, wherein if the pending transaction data and the

    25 settled transaction data relate to the same transaction, only the settled transaction data is sent to the computing device.

    2019200919 08 Feb 2019
12. 12. The method of claim 10 or claim 11, wherein if the pending transaction data does not have corresponding settled transaction data, the pending transaction data is sent to the computing device.
13. 13. The method of any one of claims 10 to 12, wherein if the settled transaction

    5 data does not have corresponding pending transaction data, the settled transaction data is sent to the computing device.
14. 14. The method of any one of claims 1 to 13, further comprising, for each transaction that is specified by the pending transaction data and the settled transaction data, comparing a pending transaction date of a transaction stored in the transient

    10 transaction data store with a settled transaction date for the same transaction stored in the permanent transaction data store, and determining which transaction date is correct.
15. 15. The method of claim 14, wherein the correct transaction date is determined to be the earlier of the pending transaction date and the settled transaction date.
16. 16. A method of tracking transactions against a transaction limit, the method

    15 comprising:

    sending a request for transaction data relating to the user account to a server system;

    receiving at least one of settled transaction data and pending transaction data relating to the user account;

    20 determining an aggregate transaction amount based on the received settled transaction data and pending transaction data; and comparing the aggregate transaction amount to a transaction limit stored in association with the user account.

    2019200919 08 Feb 2019
17. 17. The method of claim 16, wherein the step of sending a request for transaction data relating to the user account to a server system occurs periodically.
18. 18. The method of claim 16 or claim 17, wherein the step of sending a request for transaction data relating to the user account to a server system occurs in response to

    5 receiving user input.
19. 19. A system for tracking transactions, the system comprising:

    a server system configured to perform the method of any one of claims 1 to 14; and a transient transaction data store for storing transient transaction data relating to 10 pending transactions; and a permanent transaction data store for storing permanent transaction data relating to settled transactions.
20. 20. The system of claim 19, wherein the server system comprises a transaction history 15 aggregator configured to retrieve data from the transient transaction data store and the permanent transaction data store.
21. 21. A computing device for tracking transactions, the system comprising: at least one processer; and

    20 a memory device storing executable code accessible to the processor;

    wherein when the at least one processor executes the code stored in the memory device, the computing device is caused to:

    send a request for transaction data relating to the user account to a server system;
22. 25 receive settled transaction data and pending transaction data relating to the user account;

    determine an aggregate transaction amount based on the settled transaction data and pending transaction data; and

    2019200919 08 Feb 2019 compare the aggregate transaction amount to a transaction limit stored in association with the user account.