NZ750553A - 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 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 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. ransaction 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 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.

Description

"Methods and systems for transaction tracking" Technical Field 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.

Background Tracking transactions is important to many people as a way of monitoring spending and 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 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; 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 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 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 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.

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 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.

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.

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 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; 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 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 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.

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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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 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 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 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 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 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 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, 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 read- 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 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 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 I/O 115 to input a request for a 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 update on transactions performed by the user account associated with application 114.

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 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 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 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 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 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 for the time period specified in the request, to determine a total spend by the user in the time period.

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 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 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 100 in further detail. In the illustrated embodiment, system 100 includes a public sub- network 310, a private sub-network 320, and a corporate subnetwork 330. Private sub- network 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 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 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 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 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 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 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 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 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 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 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 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 , 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 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 5A connects to the left of Figure 5B and above Figure 5C, Figure 5B connects to the right of Figure 5A and above Figure 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 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 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 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 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 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 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 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, 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 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 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, 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, 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 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 that daily spend tracker 1210 always shows an accurate figure. Both pending and settled 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 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 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 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 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 tracker has been enabled by selecting option 1120 on screenshot 1100. Daily spend 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 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 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 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 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 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 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.

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 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 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 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 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 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 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 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 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.

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 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 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, 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 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 (21)

CLAIMS 1.:

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. The method of claim 1, wherein the request is generated by a computing device executing an application performing transaction tracking functions.

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. The method of claim 3, wherein the date range is a 24 hour period that includes the time at which the request was sent.

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. 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. 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. 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. 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. 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. 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.

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. 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. 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. 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. 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.

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. 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. A system for tracking transactions, the system comprising: a server system configured to perform the method of any one of claims 1 to 14; 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. 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. 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; 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 compare the aggregate transaction amount to a transaction limit stored in association with the user account.