WO2011028139A1

WO2011028139A1 - Information exchange system

Info

Publication number: WO2011028139A1
Application number: PCT/NZ2010/000180
Authority: WO
Inventors: Michael Koziarsky; Tim Norton; Jeremy Oliver; Sam Knowles; John Joseph Barclay Raeburn; Sushil Kamanahalli
Original assignee: KIWIBANK Ltd; SOCIAL CAPITAL Ltd
Current assignee: KIWIBANK Ltd; SOCIAL CAPITAL Ltd
Priority date: 2009-09-07
Filing date: 2010-09-07
Publication date: 2011-03-10
Anticipated expiration: 2012-03-07

Abstract

The invention provides a method and system for communicating data, preferably financial transaction-related data, to a first application. The method includes authenticating a user identity, establishing a secure data communication link between the first application and a database, and making at least a portion of the data available to the user via the first application. The invention also provides means and methods for categorising information artefacts such as financial transactions.

Description

INFORMATION EXCHANGE SYSTEM

Field of Invention

The invention relates to information systems. Preferred embodiments provide tools for exchanging, combining and manipulating data securely across multiple applications.

Background

Internet banking is widely available and enables a user to view balances on their accounts as well as details of their transactions. While this data is useful, it is not readily available for use in other applications. Typically, users are presented with the possibility of saving the data to a file in one or more formats (e.g. .qif or .csv file types). This data may then be input to other applications but there can be difficulties in usefully populating fields of the other applications with the data.

Numerous budgeting applications exist whereby a user may input details of their expenses and compare these against spending budgets or saving goals. These require a high level of user input, particularly if it is desired to categorise data such as into different types of expenses.

Microsoft's Money Plus is a software application that helps users keep track of their money. Users login to the application and can view details of any online bank accounts, bills and spending. The bank accounts are set Up in the application by providing details of each, including the user's passwords. After set up, the bank accounts are automatically accessed by the application and transactions / balances downloaded. Users can manually set budgets,, including for different categories. A bar graph provides a visual representation of how the user's actual spending compares to the budgeted allocations. While providing some good functionality, there are inherent security risks in having banking passwords stored and this is exacerbated by having all of a user's login details stored in the same place. Furthermore, the budgeting aspect of the software is labour intensive for users, lacking any intuitiveness.

It is an object of the invention to provide methods, systems or apparatus that overcome or ameliorate at least one of the aforementioned problems.

Alternatively, it is an object to provide to provide the public with a useful choice. Summary of the Invention

According to a first aspect of the. invention, there is provided a method of communicating data to a first application, the method including:

authenticating a user identity;

establishing a secure data communication link between the first application and a database; and

making at least a portion of the data available to the user via the first application.

Preferably, the database is accessed via a secure link between the first application and a second application. Communications access may be established between additional second applications and the first application. This may be effected through separate secure links for each second application, although varying degrees of commonality of links are possible. For example, if databases for two second applications are co-administered, it may be possible to establish a single link.

According to preferred embodiments, the second applications are used to access confidential and/or personal information. For example, they may include online banking and other online financial facilities. While the specific description and drawings present the invention within this context, it will be appreciated that it is not limited thereto. For example, the invention may be adapted to provide for the communication of health-related data.

Unlike the Microsoft Money Plus application, there is preferably no online communication of login details between applications (e.g. usernames and passwords) so as to improve security and reduce the risk of tampering or attacks (e.g. phishing) from third parties, particularly to the information accessible through the second application(s) or the functionality provided thereby, e.g. transfer of funds. This is enabled through the establishment of the secure link on login to the first application and generally requires prior authorisation from the administrator of the second application(s) to enable the provision of the information to the first application. This is more readily achievable where the first and second applications are co-administered.

More particularly, according to preferred embodiments, the second application creates an encrypted link containing an Access Number for the particular user. The link is used to redirect the user's browser session to that URL, using a secure protocol such as SSL, ensuring that the values of the URL are visible only to the first application, the second application establishing the link to the end-user. It will be appreciated that provision may be made for additional users to be authorised with access. A preferred process for establishing the secure link is described in more detail below.

Firstly, authentication information is established by encrypting the string "AccessNumber:LinkGenerationTime", where AccessNumber is the access number for the customer who is logging in (e.g. 516943) and LinkGenerationTime is the time the second application generated the secure link (e.g. 2009-06-08T03:09:34Z in the UTC timezone and xml schema format). The combined string is encrypted for transmission to the first application. A presently preferred encryption method is symmetric aes-256-cbc encryption. A random initialization vector is generated and used with a shared key (an encryption key shared between the first and second applications) to generate the encrypted payload. This gives the values Payload and InitializationVector. To prevent tampering a SHA1 HMAC (i.e., a SHA-1 Hash Message Authentication Code) is preferably created for the byte array consisting of the Payload and InitializationVector. The 'shared secret' (a random value used when constructing the HMAC) is used for this HMAC.

This yields three byte arrays: Payload; InitializationVector and HMAC.

Transmission of information to the first application is handled by constructing a URL within the second application (e.g. an internet banking facility) and redirecting the user's browser to that URL. The URL is preferably contructed by first Base64 encoding the three values from the encryption process and placing them into the following URL: https://HOST/auth?Payload=...&lnitializationVector=...&HMAC=... where HOST is the URL designated by the second application. All parameters must be URL escaped or formatted to avoid the +, / and = characters in the encoded values corrupting the URL. All whitespace in Base64 values is ignored, so for the sake of space it should be removed.

After the second application has received the request for the signed URL, the following steps are taken: - the HMAC is used to ensure nothing has been tampered with, checking data integrity and message authenticity

- the Payload is decrypted to yield the AccessNumber and LinkGenerationTime

- the LinkGenerationTime is compared to the current time, to ensure the value is not too old (default 15 mins)

If the AccessNumber is considered valid, the user is logged in. If there are any errors or failures in the above 3 steps, access is refused. Standard protocols may be used in such an event e.g. a generic error message may be displayed such as "permission denied, try again". A predetermined number of failures (in total and/or in succession) may be set after which access is more fully denied and a greater level of user authentication / verification is required to subsequently gain access. Such arrangements are known in the art.

On successful login, there is provided a seamless / transparent flow / provision of information from the second application(s), in that it appears to the user that information is provided directly via the first application. However, embodiments of the invention may include the option of receiving information via second applications in a more conventional manner e.g. via data downloaded from the second application as a .csv file.

Preferably, the method includes categorising information artefacts such as transactions. Categorising may be based in part on user selections and/or data associated with each artefact. Preferred embodiments include performing a rule-based algorithm for determining categories and is described in more detail in relation to the drawings.

Preferably, the method includes determining a budget and/or saving goal for a user.

Preferably, the method includes issuing a notification. The step of issuing is preferably in response to detection of an event as described herein.

Preferably, the method includes providing a user with targeted information or promotions based at least in part on data available to the first and/or second applications.

According to a second aspect, there is provided a computer readable medium, which when executed on a suitably enabled computing device, performs the method of the first aspect.

According to a third aspect, there is provided a computing device configured to perform the administrative functions of the method of the first aspect.

According to a fourth aspect, there is provided a system for providing access to information via a first application, the system including one or more client terminals and at least one computing device according to the third aspect.

The system of the fourth aspect preferably has a generally conventional client-server configuration, such as that enabled via the internet although other configurations are included within the scope of the invention. Apparatus used to perform the required processing of the user terminals and the server technology used by the first and second applications will be apparent to those in the art and any known data communication means may be used for the exchange of information therebetween.

Further aspects of the invention, which should be considered in all its novel aspects, will become apparent to those skilled in the art upon reading of the following description which provides at least one example of a practical application of the invention.

Brief Description of the Drawings

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

Figure 1 is a schematic diagram of a system of one embodiment of the invention; and Figures 2-13 show example screenshots generated by an embodiment of the invention.

Detailed Description of Preferred Embodiments

In broad terms, the invention provides an application that securely transfers information from a remote database (e.g. one holding banking or other sensitive data) so as to provide for improved usability and functionality associated with the data. The improvement may be effected through a first application, over and above that provided by a second application (e.g. a conventional internet banking facility). For the avoidance of doubt, the first application of the invention may be configured to cooperate with more than one external database, said external database(s) conventionally being accessed by one or more corresponding second applications.

The application of the invention may be established local to or remote from the provider of the second application. Similarly, data-centres or memories used by each application may be co- or separately located.

Preferred embodiments of the invention (including those shown in Figures 2-13) may, on the whole, be enabled through standard internet technology but configured such that the application of the invention provides a seamless, secure, two-way integration with the second application, more particularly, with the associated databases. Consequently, as will become apparent from Figures 2-13, most (if not all) functionality associated with the first application appears to users to be performed or capable of being performed by the application of the invention, although varying extents of use of the second application(s) may be made to access the associated database(s). Thus, to users, direct use of the second application(s) may no longer be required. This provides for improved ease of use and better visualisation since all relevant data may be viewed in a single application / window, rather than having to switch between applications. However, unlike the Microsoft application, there is preferably no communication of login details between the applications, although alternative configurations may be used.

The "single" integrated application of the invention is preferably enabled through the use of cryptographically secure HTML links between the separate applications. Each application has access to two cryptographic keys, one for encryption and the other for signature. Whenever a user transitions from one application to the other (namely when data communication is required therebetween), the transmitted information is encrypted and provided with a signature to prevent tampering or other unlawful or unauthorised access to the data. Thus, session-related information may be transparently transported between the applications, resulting in data change in one application being recreated in the other application, thereby keeping the inter- application transition essentially hidden from users.

Figure 1 is a schematic diagram of a system 1 according to one embodiment. The system shown is merely by way of example and it will be appreciated that various modifications may be made without departing from the scope of the invention. Any data communication media may be used to convey data between elements of system 1 , including wired and/or wireless media.

System 1 includes user terminals 2, data network 3, bank server 4, credit card server 5 and categorisation engine 6. It will be apparent that bank server 4 will in reality be comprised of more than one unit and may be distributed around the network at more than one site. This similarly applies to other ones of the elements shown. Furthermore, any two or more elements may be co-located or integral to one another to varying degrees, depending primarily on design choices and the parties responsible for their operation. For example, the bank server 4 and the credit card server 5 may be co-located and/or substantially integral. Also, additional ones of these elements and/or other elements may be included within the system 1.

Categorisation engine 6 is a preferred component part of the invention and is described in more detail below. As will be apparent from that description, engine 6 may be positioned anywhere within the system 1 , provided the necessary communications channels are established.

According to preferred embodiments, the data network 3 (or at least a portion thereof) is embodied by the internet. As will be apparent, more direct communications links may be established between particular elements of the system 1 as desired. For example, a fixed connection may be provided between the bank server 4 and the credit card server 5.

Functionality provided by embodiments of the invention will now be described with reference to the screenshots taken from an example software application according to the invention.

Figure 2 shows a preferred display presented to users on successful login to the application. It provides a summary of the user's current finances and may be switched to by users at any time by clicking on the current time period (while monthly periods are shown, these may be adjusted as desired) and the "All Spending" tab 21. Other tabs 22 allow users to look at sub-categories of their total spending e.g. home expenses, food, fun, travel and miscellaneous. Chart 23 provides users with an easy visualization of their spending relative to received income or earnings and an overall spending budget, over a predetermined period. According to preferred embodiments, the predetermined period may be adjusted by users. In the example, a period of 6 months is shown. Table 24 shows figures for the selected month of June from chart 23. Box 25 lists a user's accounts and their corresponding balances. This information is obtained from a user's online banking facility. Box 26 provides a brief summary of average monthly earnings and spending and at 27, a user is provided with an indication of the effect of their transactional history on future savings. In the example shown, the user is saving $180 per month which will result in total savings at the end of the 6 month period of $1830 (on the assumption that $550 had already been saved).

Box 28 shows details of recent transactions (also obtained from a users internet banking applications) including categories for any expenses. According to preferred embodiments, the application of the invention determines a category for each transaction using a categorisation engine. Note that the categories shown are by way of example only. Other categories may include loan payments, rent, etc. Further categories may be used where the invention is adapted for businesses such as marketing, IT, etc. Furthermore, as will be appreciated by those in the art, due to the modular nature of computer processing, the categorization engine (and other elements of the system) may be located according to system preferences with communications media provided between different elements within the system as required.

The categorization engine may be assisted using information fed from a number of sources, namely, a user's internet banking application (e.g. merchant name, amount, date, particulars, code and reference), credit card accounts (e.g. a merchant category code or MCC), and a user's past behaviour. A preferred embodiment of the categorization process is set out below. The process is presented in a preferred sequential order but the invention is not limited thereto.

If the user has previously manually categorized a transaction from a particular merchant, then this categorization is used. If not and if applicable (i.e., it is a bank account transaction), details of the transaction are extracted from the user's internet banking records. According to preferred embodiments, the records used are the internet bank's internal records rather than the information typically presented to a user in the internet application as this may provide additional details. The category may be determined and provided by the internet banking application (or an add-on module thereof) to the application of the invention. Alternatively, data required to make the determination may be communicated elsewhere including to the application of the invention which may include the categorization engine as a module thereof.

Visa and Mastercard have a predefined series of numeric codes which correspond to the business of the customer originating a transaction. An excerpt of Visa classifications is provided in Table 1 below.

MCC MERCHANT TYPE

0742 Veterinary Services

0763 Aqricultural Co-operatives

0780 Horticultural Services

0780 Landscapinq Services

1520 General Contractors-Residential and Commercial

171 1 Air Conditioning Contractors- Sales and Installation

171 1 Heatinq Contractors- Sales, Service, Installation

1731 Electrical Contractors

1740 Insulation - Contractors

1740 Masonrv. Stonework Contractors

1740 Plasterinq Contractors

1740 Stonework and Masonrv Contractors

1740 Tile Settings Contractors

1750 Carpe ntrv C ontractors

1761 Roofinq - Contractors

1761 Sheet Metal Work - Contractors

^• 1761 Siding - Contractors

1771 Contractors - Concrete Work

1799 Contractors - Special Trade . Not Elsewhere Classified

2741 Miscellaneous Publishing and Printing

2791 Tvpesettinq. Plate Makinq, & Related Services

2842 . Specialty Cleaning, Polishing, and Sanitation Preparations

3000 . UNITED AIRLINES

3001 AMERICAN AIRLINES

3002 PAN AMERICAN

3004 TRANS WORLD AIRLINES

3005 BRITISH AIRWAYS

TABLE 1 - EXAMPLE MCC CLASSIFICATIONS

Where a transaction has an associated MCC, this may be used to derive the category. If not, the categorization engine may search a database for a merchant. If an exact match is found, associated details of the merchant may be used to categorize the transaction. For example, if the MCC was 3000, by referring to Table 1 , we can assume that the user has purchased an airline ticket as the transaction is with United Airlines and categorise the transaction in "HOLIDAY". If there is no exact match, a rules-based engine may be used to match a merchant name for a transaction against a merchant in a database or against a transaction category based on fuzzy matches.

If none of the above successfully arrive at a category, the category may be left blank and a user prompted to select a category. Alternatively, a default category may be designated such as "other". Transactions categorized by the engine or by a user may be used subsequently by the rules-based engine to categorize future transactions, developing new fuzzy and exact matches. Thus the categorization engine learns as it progresses, providing improved matches over time. According to preferred embodiments, the fuzzy logic of the engine is built up using categorizations performed by or on behalf of more than one user (preferably all users), enabling users to take advantage of categorizations made by others.

According to a preferred embodiment, the categorization engine categorises a transaction with a merchant according to the following sequence:

1. If the user has manually categorised a transaction with the merchant previously, that categorisation is used

2. If the merchant is a customer of an associated bank (i.e, details of the merchant are available through bank records directly or indirectly accessible by the application of the invention), then that information is used

3. use an associated MCC to derive a category

4. search for an exact match of the merchant's name in a database

5. if no exact match is found, attempt to match the merchant's name against a series of rules, preferably based on fuzzy matches

6. the category is left blank (the user may be prompted to provide the information).

As an example, consider a first transaction between a particular user and the merchant "PETIT BORDEAU". Since this is the first transaction, the engine proceeds to step 2. Assuming that steps 2 to 5 produce no result, the user is prompted and provides the category "FOOD". The next time the user purchases from the merchant, only step 1 is performed.

According to preferred embodiments, manual inputs of one or more users may be used to categorise transactions of those and/or .other users. Thus, referring to the above example, after a statistically significant number of users have matched the name PETIT BORDEAU with FOOD, all users may be provided with this as a manual categorisation and would therefore identify the merchant at step 1 even if a particular user had not previously done business with PETIT BORDEAU. An alternative approach is to store these determinations in a separate database which is searched at, say, step 4. The latter approach ensures that a particular users own inputs have overriding priority. ,

Figure 3 provides a screenshot similar to that of Figure 2 but showing additional detail for May, rather than June. According to preferred embodiments, categories with overspending (e.g. food and fun) are easily distinguishable and may be shown in red. Those under budget (e.g. travel and other) may be in a contrasting colour (e.g. green). As will be evident, the ability to easily switch to different points in time or different time periods provides users with a ready visualisation of their finances at different times that enables them to quickly assess each period in turn and identify trends. Following on from the view of Figure 3, a user may wish to look further at a category in which they have overspent. This is achieved by clicking on the relevant tab 22. Figure 4 shows the resultant view when the "fun" tab 22 for the May period is activated. In this view, chart 23 is limited to the selected category for each of the time periods enabling users to see trends for that category. The transactions in box 28 and the budget figures in table 24 are also preferably limited to the selected category and preferably additionally to the selected month.

Table 24 of Figure 4 provides a user with key information for setting a budget. As indicated, the budget is currently set at $450 per month for the user to spend on fun. The budget is preferably initially set or proposed by the application of the invention, rather than a user setting a budget. This provides for improved ease of use and is a key step in encouraging and achieving the use of budgets. The suggested budget may be based on any one or more of historical data for the user in question, historical data for other users (preferably of users in a similar position to the user in question) and generally accepted budgeting practices (e.g. a user in a particular age group may generally be recommended to save a particular percentage of their salary, other factors may be used to adjust this e.g. whether they are paying a mortgage as opposed to rent).

Rather than creating budgeting and setting goals separately, the application of the invention ties these two concepts together. More particularly, based on targets set by a user, the application determines what they could achieve (i.e., what they may be able to save each month and how long it will take to achieve their goal) and makes this the default. As time passes, continuous or periodic assessment may be made as to whether a user is adhering to their budget and the application detects behaviour characteristics e.g. a user is bad at sticking to budgets and frequently overspends. As a result of this, warnings relating to delays in achieving goals or simply updated goal achievement dates may be dispjayed to a user, preferably in place of the original goal so that the user is not set with unrealistic goals they will not achieve. Users may be presented with the option to accept or reject any changes before they are made. In Figure 4, the user is provided with an option to change their budget for the selected category by clicking on the change budget button 41. The resultant view is provided in Figure 5 which shows a user having manually selected a new monthly budget of $200 in the budget entry box 51 which is confirmed by clicking on the set budget button 52.

Figure 6 shows the display following setting of the new budget with chart 23 updated accordingly. The user is presented with the box 61 which enables a user to be notified if they are approaching or exceeding their budget. Alternatively, details of spending may be incrementally provided based on predetermined time periods or spending amounts. The periods or amounts may not be equal and according to one embodiment, they may be initially relatively long and then shortened as the budget is approached or exceeded. Communications means for sending notifications of bank account status are well known in the art and conveniently include email and text messaging.

The notification process of preferred embodiments of the invention provides additional functionality over prior approaches. Various information is collected by the application each time a user uses the system, makes a transaction or other change to their profile / goals. These enable the application to form a comprehensive profile for each person which is used to ascertain the timing and types of messages sent to users about their spending so as to trigger real behaviour changes. Thus, rather than simply notifying someone based on a set event such as a budget having been exceeded, the application of the invention looks at a user's overall profile, their goals and previous behaviour and ascertains the likelihood of particular behaviour occurring, such as noticing that someone is on a drinking binge^". On detection of this (from, for example, transaction details such as details of the merchant and/or the time of purchase), a message is sent to the user and/or someone in their trust group. The message content, who it is sent to and the timing can therefore be updated based on data stored against a user showing what approach has been most effective in the past.

The comprehensive profile may contain any one or more of demographic information, financial information and information on financial / life goals looking to be achieved. The probability and propensity for a given user to achieve their goals may be derived from historical data (primarily of the user in question although some account may be taken of other users, particularly those in a similar position to that user) and the feasibility of the savings or behaviour changes required. This is more detailed than simply considering a user's financials or demographics in isolation because the information is combined with the goals attempting to be achieved and the user's spending habits.

An additional advantage of the building of profiles is that they may be used to provide contextual advertising and offers to users which is more accurate or relevant to them than typical contextual / demographic targeted advertisements. For example, advertising for mortgages may be targeted more precisely than simply being aimed at those potentially looking for a mortgage - advertisements for mortgages for specific sectors may be sent e.g. those that already own their home, may be looking to purchase a larger home, earn more than $100k, are up to date on their current mortgage payments, have a history of saving money for purchases and no history of carrying credit card debt. Other sectors may be selected as desired.

In addition to simply presenting users with more targeted advertising / offers, the application of the invention may fully integrate with the advertiser's provisioning system, allowing for two-way exchange of information with advertising companies. For example, if a user wants to make a mortgage application in response to an advertisement, this may be achieved by a single click on the advert. Not only may this result in communication of the relevant personal details, but may include, for example, providing a transaction history (i.e., bank statements) for a given period of time. Preferably, the period (or whatever information, is required) is defined by the advertising company so that they receive what they need but this may be established by the application of the invention based on the category of merchant. An alternative example is a company selling under-floor insulation. The merchant could automatically be passed the address, contact details and grant-eligibility (in relevant areas) information of a user based on a single click. Thus, in accepting an offer, the application of the invention may provide the relevant merchant with information tailored to be of relevance to them.

Data stored against the comprehensive user profiles may, for example, also be used to calculate a profile of the default-risk for a potential loan to assess whether to grant a loan and also to select the most appropriate loan. Since the comprehensive user profiles contain more information than that usually provided to secure a loan, more risk factors can be taken into account. Furthermore, all that is required for a user to request a loan is to allow the relevant authority access to the profile. As will be appreciated, this may be achieved using the secure link set up between the user's online banking applications and the application of the invention, provided these institutions are providing the financing. These benefits are more readily derived where the application of the invention is hosted by the same institution as that providing the financing since additional permissions may not be required from the user to have the profile used in this way and the exchange of data may be more secure, particularly if both applications are hosted from the same site or server and external transfer of data is not required. At the least, the user profiles may be used to automatically fill forms for loan requests or the like. Figure 6 also shows an Add Goal Button 62 which is used to add savings goals. Figure 7 shows a preferred screen display when the button 62 is activated. Chart 71 shows current savings and projected future savings based on the current budget. Boxes 72-74 are provided for a user to input a name, image and description, respectively, against their goal. Figure 8 shows an example goal of renovating a kitchen with boxes 72-74 filled in.

Boxes 75 and 76 allow a user to set parameters for their goal, namely, how much they need to save in box 75 and by when they would like to achieve their goal in box 76. This is converted into how much needs to be saved per month and displayed in box 77. Also shown in Figure 7 is a summary of earnings and expenses (for each category). This can be useful for users when assessing what budget they can afford and which they are prepared to commit to.

Tasks tab 81 and notes tab 82 are shown in Figure 8 but more clearly in Figure 9. The tasks tab is used to add tasks other than a financial goal. Figure 10 shows a user adding a new task for their kitchen renovation project, namely, buying paint test pots, in box 101.

Figure 11 shows a view similar to that in Figure 2 but two months later, in August. As can be seen, tasks (including buying paint test pots) are set out in box 111. It is readily apparent from the updated chart 23 that the user has kept spending below the budget line 112 for the past few months and that consequently, the user's savings are higher than budgeted. Since the saving goal may be reached before the original deadline, by selecting the particular goal, the user may opt to adjust the deadline by which they achieve their goal. As shown in box 76 of Figure 12, the user is provided with an indication as to when they will achieve their goal based on the latest spending history (i.e., 1 November) and the option is provided to make this the due date. Figure 13 shows the goal due date having been changed with the chart 71 adjusted accordingly. The user is also provided with the option of manually adjusting the due date.

Figure 12 also shows a user about to update one of their tasks, namely researching lighting, which is also displayed in box 111. "Task" is generally used herein to refer to a "sub-goal" i.e., something that contributes to the achievement of a goal. By clicking on the check box 121 to indicate that the task has been completed, it is removed from the task list (or marked as completed) and removed from box 111 as shown in Figure 13. Rather than removing completed tasks from display in box 111 , an indication may be provided that they have been completed.

While the displays shown in Figures 2 to 13 are preferred both in terms of layout and functionality, it will be appreciated that various modifications may be made. For example, elements of the display may be positioned differently, alternative chart forms may be used, menu structures for accessing / activating / setting different options may be altered and various elements may be substituted or omitted. All such modifications are include within the scope of the invention.

The entire disclosures of all applications, patents and publications cited above and below, if any, are herein incorporated by reference. Reference to any prior art in this specification is not, and should not be taken as, an acknowledgement or any form of suggestion that that prior art forms part of the common general knowledge in the field of endeavour in any country in the world.

Wherein the foregoing description reference has been made to integers or components having known equivalents thereof, those integers are herein incorporated as if individually set forth.

Various changes and modifications to the presently preferred embodiments described herein will be apparent to those in the art. Such changes and modifications may be made without departing from the spirit and scope of the invention and without diminishing its attendant advantages. All such changes and modifications are included within the scope of the invention.

Claims

1. A method of communicating data to a first application, the method including:

authenticating a user identity;

establishing a secure data communication link between the first application and one or more database;

establishing a respective secure link between the first application and each of one or more second applications, each said second application being associated with one or more of said database(s); and

making at least a portion of the data available to the user via the first application by . communicating said data from the database(s) to the first application via the secure link between the first application and the corresponding second application.

2. The method of claim 1 , wherein a said second application is an online banking or other forms of financial information application.

3. The method of claim 1 or 2, wherein the step of establishing a respective secure link between the first and second applications is initiated on login to the first application.

4. The method of any one of the preceding claims, including obtaining authorisation of the to communicate data from the second application(s) to the first application.

5. The method of any one of the preceding claims, wherein the step of establishing a secure data link includes:

creating an encrypted link containing an Access Number for a user; and

using the link to redirect the user's browser session to that URL.

6. The method of claim 5, wherein the values of the URL are visible only to the first application.

7. The method of claim 5 or 6, wherein the URL is constructed by the second application.

8. The method of any one of claims 5-7, wherein said establishing includes establishing authentication information by encrypting the string "AccessNumber: LinkGenerationTime", where AccessNumber is the access number for the user and LinkGenerationTime is the time the link is generated.

8. The method of claim 7, wherein said establishing includes transmitting the string to the first application.

9. The method of claim 8, including encrypting the string to prior to transmission to generate an encrypted Payload.

10. The method of claim 9, including generating a random Initialization Vector using an encryption key shared between the first and second applications for generating the encrypted Payload.

11. The method of claim 10, including hashing the Payload and InitializationVector to generate a hash value, HMAC.

12. The method of claim 11 , wherein said URL is constructed by encoding said Payload, said Initialization Vector and said HMAC.

13. The method of claim 12, wherein said URL is contructed by placing the encoded three values into the URL: https://HOST/auth?Payload=...&! nitializationVector=...&HMAC=... , where HOST is the URL designated by the second application.

14. The method of any one of claims 11-13, including using HMAC to check data integrity and/or message authenticity!

15. The method of any one of claims 11-14, including:

decrypting the Payload to yield the AccessNumber and LinkGenerationTime; and comparing the LinkGenerationTime to the current time.

16. The method of any one of the preceding claims, including generating a transparent flow of information from the database(s) to the first application.

17. The method of any one of the preceding claims, including determining a budget and/or saving goal for a user.

18. The method of claim 17, including issuing a notification in response to detection of a pre-defined event.

19. The method of any one of the preceding claims, including providing a user with targeted information or promotions based at least in part on data available to the first and/or second applications.

20. The method of any one the preceding claims, wherein the data includes finance-related data.

21. The method of claim 20, wherein the data includes financial transaction data.

22. The method of claim 21 , including categorising a financial transaction into a category.

23. The method of claim 22, wherein said categorising is based at least in part on user selections and/or data associated with each artefact.

24. The method of claim 23, including using a rules based engine for determining the categories for said transactions.

25. A method of categorising information artefacts, including categorising one or more of said artefacts based at least in part on user selections and/or data associated with each artefact.

26. The method of claim 25, including using a rules based engine for determining categories for said artefacts.

27. The method of claim 25 or 26, wherein said information artefacts are or relate to financial transactions.

28. The method of claim 27, including the step of a user manually specifying a category for a transaction.

29. The method of claim 27 or 28, including using data associated with said financial transaction to specify a category.

30. The method of claim 29, wherein said associated data includes details of a merchant for a transaction and/or an MCC or merchant category code.

31. The method of any one of claims 25-30, including using fuzzy logic and/or a predetermined category where no category for the artefact is otherwise identified. 32. The method of any one of claims 1-24, including categorising one or more information artefacts according to the method of any one of claims 25-31.

33. A computing device configured to perform the administrative functions of a method according to any one of the preceding claims..

34. A system for providing access to information via a first application, the system including one or more client terminals and at least one computing device according to claim 33.

35. A method of communicating data to a first application substantially as hereinbefore described with reference to any one of the embodiments shown in the drawings.

36. A method of categorising information artefacts substantially as hereinbefore described with reference to any one of the embodiments shown in the drawings. 37. A computer readable medium, which when executed on a suitably enabled computing device, performs a method according to any one of claims 1-32 or 35-36.

39. A computer-based engine for performing the method of any one of claims 1-32 or 35-36. 39. A computing device substantially as hereinbefore described with reference to any one of the embodiments shown in the drawings.

40. A system substantially as hereinbefore described with reference to any one of the embodiments shown in the drawings.