WO2008119985A1

WO2008119985A1 - Token transfer

Info

Publication number: WO2008119985A1
Application number: PCT/GB2008/001138
Authority: WO
Inventors: Antony William Elliott Elliott; George Thatcher Guernsey
Original assignee: Antony William Elliott Elliott; George Thatcher Guernsey
Priority date: 2007-03-30
Filing date: 2008-03-28
Publication date: 2008-10-09
Also published as: GB0706286D0

Abstract

A system is provided for analysing the transfer of tokens from a user in a plurality of categories. The system includes; summing means for providing respective totals of token transfer for each category; and means for providing an output of said analysis; wherein the output is dependent on the respective total transfer of tokens from the user for each category. In a preferred embodiment the system further comprises means for allocating an identification code to each category, and each category is a category of merchant or merchandise.

Description

Token transfer

Field of the Invention

The present invention relates to a system and method of controlling and monitoring the transfer of tokens.

Summary of the invention

It is an aim of the present invention to provide token transfer services in which there can be greater interaction between individual services and more efficient use of such services. A token reservoir (preferably in respect of some or all token use) may be operated alongside other services relating to the transfer of tokens, so that the user may not be required to access information from a variety of sources. The present invention can afford the technical ability to provide users with messages relating to activities concerning their token transfer services in real-time. The invention may afford multiple forms of communication between the token transfer provider and the user.

The present invention can provide the technology and technical ability to integrate token transfer services via an interface provided online via the internet. Furthermore, the present invention can provide the user with detailed information relating to their token transfer services and their use.

The present invention is characterised in Claim 1. By providing a means for providing an output of the analysis of token transfer in dependence on the respective total transfer of tokens from the user in each category efficient use of token resources may be made by the user, and in particular more efficient tracking of token usage may be undertaken.

Preferably, a limit is provided for each category. By providing a limit for each category the system may control token usage more efficiently.

Preferably, the system further comprises means for profiling said user, so that more effective limits may be provided for each category. Preferably, the profiling uses said user's total token transfer in a given period of time, so that the profile becomes more accurate over time.

Preferably the means for profiling uses pattern recognition, so that a more accurate profile may be obtained.

Further features of the invention are characterised by the appended claims. The invention extends to methods and/or systems substantially as herein described with reference to the accompanying drawings.

The invention also provides a computer program and a computer program product for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, and a computer readable medium having stored thereon a program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

The invention also provides a signal embodying a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein, a method of transmitting such a signal, and a computer product having an operating system which supports a computer program for carrying out any of the methods described herein and/or for embodying any of the apparatus features described herein.

System or apparatus and method features may be interchanged as appropriate, and may be provided independently one of another. Any feature in one aspect of the invention may be applied to other aspects of the invention, in any appropriate combination. In particular, method aspects may be applied to system or apparatus aspects, and vice versa.

Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying figures, in which:- Figure 1 is a schematic diagram of the overall system; Figure 2 illustrates a token planning and control account process; Figure 3 illustrates the creation of messaging and blocking criteria; Figure 4 illustrates the allocation of expenditure within a budget;

Figure 5 illustrates the operation of a loan system; Figure 6 illustrates a specific embodiment of the system invention; and Figure 7 illustrates a specific embodiment of the web interface.

Detailed description Overview

The present invention allows the transfer of tokens between a user and a further party to be monitored and, if necessary, restricted. Figure 1 is a schematic diagram showing an overview of the present invention, system 100. The central server 101 has communications links with all of the other hardware associated with the system, and the user 102, and further party(ies), 104. The central server 101 has communications links to the monitoring unit 106, the recording unit 108 and the reporting unit 110. The central server also communicates with the profiling engine 112, the message generation unit 114, and the transfer blocking unit 116. This hardware, and the communications between such hardware, is situated within the system 100. In addition, there are external links to the user 102 from the central server 101 ; this communication is two- way. The message generation unit 114 is also enabled to communicate, one-way, from the message generation unit 114 to the user 102.

The central server 100 is therefore capable of routing the data from the monitoring, recording, and reporting units, 106, 108, and 110 respectively, in an appropriate manner.

The user, 102, can be single person, or a group of people, including multiple main-users and multiple sub-users. The main-users and the sub-users may communicate with the system via a communications link to the central server. The communication link may be via the internet, or the telephone. Main-users have the authority to change the settings associated with the system; sub- users do not. However, all users may transfer tokens to the further parties 104. Each user has an electronic transfer device, such as a smart card, for enabling the transfer of tokens between the user 102 and the further parties.

The further party 104 is in one-way communication from that party to the central server 101. Information relating to the type of transfer taking place between the user 102 and the further party 104 is provided to the central server, generally via a Standard telephone line. During the communication the further party identifies themselves via the use of an identification code unique to each further party.

The further parties 104 may be arranged into groups. Figure 1 shows the further parties 104 arranged into two groups, A and B; however, this is only by way of example and there may be any number of groups of further parties 104, with any number of further parties 104 within each group. Each group is arranged to be a category of similar further parties, or similar merchandise/services. Similar further parties 104 are grouped together to allow related transfers of tokens to be stored in the same location. For example, when two separate transfers are between two further parties 104 that are related in some manner, for example they supply the same type of service, then the transfer of tokens between the user 102 and those further parties 104 will be stored under the same group. The user 102, or the central server 101 , may define multiple groups each containing the identification codes (ID 1 , ID 2, ...) of similar further parties.

The transfer of tokens between the user 102 and the further party 104 is monitored by the monitoring unit 106 via the central server 101. The monitoring unit 104 passes the information to the recording unit 106 via the central server 101 which then stores the information relating to the transfer of tokens between the user 102 and the further party 104. The recording unit is adapted to store the information within a database in the further party groups.

The reporting unit 110 generates reports based on the data stored by the recording unit 108. The central server 101 also provides an interface between the user 102 the reporting unit 110. In the preferred embodiment this interface is a website and the user may connect to the website via the internet. In this embodiment the reporting unit 110 can generate data in a form requested by the user 102.

The profiling engine 112 is utilised by the system to generate profiles of the user 102 based on the user's details, in order that the profiling engine may propose for the user, or indeed create, token transfer limits and message alert limits. The limits generated by the profiling engine are used by the message generation unit 114 and the transfer blocking unit 116. The token transfer limits are used to limit the transfer of tokens between the user 102 and the further party(ies). A token transfer limit can be created for each further party 104 individually or for each group of such further parties, or for other related categories such as categories of goods, services or merchandise.

The profiling engine 112 is in communication with the transfer estimate generation unit 117. The transfer estimate generation unit 117 is also in communication with the central server 101. The transfer estimate generation unit 117 is provided with information on the user 102 from the profiling engine 112, and then uses that information to generate a total token transfer estimate for each of the further parties and/or further party groups, typically for a predetermined time period such as a month. The total token transfer estimate may be based on the total availability of tokens to the user 102 (usually in a defined period) and the user's details. For example, if the user 102 has available 1000 tokens per calendar month then the transfer estimate generation unit 117 will allocate the 1000 tokens across the further parties that the user 102 would wish to transfer tokens to. The allocation of the tokens would be based on previous transfers, and estimates of future transfers.

The profiling engine 112 can use pattern recognition to analyse previous token transfers to allocate a total token transfer estimate and/or message generation limit and/or transfer blocking limit to each group of further parties. Using pattern recognition allows the system to provide initial parameters to be used or modified by the user 102. These parameters may be adjusted regularly to cope with changing circumstances. The pattern recognition incorporated into the profiling engine also allows for ongoing analysis of the user's token transfer. The pattern recognition enables the inherent pattern of token transfer for each user to be recognized, and then utilized by the system. This allows for the system to provide additional messages to the user in dependence on the patterns of token transfer. For example, if a user wishes to reduce their overall token transfer, the system would use the history of token transfer of the user to suggest methods through which the user would effect the reduction. In a specific example, if one user had a history of token transfer in which in every time period a relatively small number of tokens was transferred then the methods suggested would be different to a user who alternately transferred a small number and then a large number of tokens in successive time periods.

Furthermore, the system is enabled to detect a change in the inherent pattern of a user's token transfer, and effect an action; the action, again, could either be a message or a block on further token transfer. This form of action would only be possible once the system has established, over a period of time, a normal pattern of usage for the user.

In addition, the profiling engine can use pattern recognition to analyse the method by which the user utilises the system. In this way the system can allow the user to set up a combination of key strokes to act as a "shortcut" for a more complex process. For example, if the user always enters the system's user interface and then proceeds to the interface to alter the blocking limits - which may take a number of key strokes/mouse clicks to initiate - then the system would present the user with a "shortcut" enabling them to quickly and easily go to the interface to alter blocking limits.

The message generation unit 114 has a number of message generation limits, either pre-defined by the profiling engine 112, or set by the user 102. The message generation limits are used to generate a message to the user 102 when a certain number of tokens have been transferred between the user 102 and a further party 104, or group of further parties, for example to warn of an impending exceeded budget in a particular category.

The transfer of tokens from the user to further party(ies) is routed through the transfer blocking unit 116. This allows for the blocking limit to be defined whereby once the predetermined blocking limit has been reached no further transfer of tokens is permissible between the user and a further party, or a group of further parties, as defined by blocking limit rules. Moreover, when the total number of available tokens has been expended any further token transfer, to any further party or group of further parties, may be blocked.

Each further party or group of further parties may be provided with a total token transfer estimate, one or more message generation limit, and one or more transfer blocking limit.

In this way the user may control the transfer of tokens to further party(ies) in an efficient and organised manner. In setting up the respective limits for each group of further parties the overall total transfer of tokens may be controlled. The pre-defined limits may also be set-up for each sub-user, thereby further controlling the transfer of tokens, and allowing sub-users to utilise the tokens of a main user without the main-user being concerned that an excessive transfer of tokens will result.

For example, a group of three further parties may be assigned three message generation limits. The first, a notification message, can be set up to send a pre-defined message when, for example, the combined transfer of tokens to the three further parties reaches 70% of the token transfer estimate for that particular group of further parties. A second message, a warning, will be sent to the user when, for example, the combined transfer of tokens to the group of further parties reaches 90% of the token transfer estimate for that particular group. A final, alarm, message can be set-up to send a message when, for example, the total transfer of tokens to a particular group reaches 100% of the token transfer estimate for that particular group. In further examples the notification message limit may be set to 50%, 60% or 80%; the warning message limit may be set to 70%, 80% or 100%; and the alarm message limit may be set to 90%, 95%, or 110%. These limits are provided purely by way of example and it is understood that the user 102 may set the limits to any desired value.

The transfer blocking limit may, for example, be set as 110% of the total token transfer estimate for that particular group of further parties. When for example, the total transfer of tokens to that group reaches 110% further transfer of tokens is blocked by the transfer blocking unit. A transfer blocking limit may be set up for each group of further parties for each main-user and each sub-user. In this way a user may have control over the total number of tokens transferred. In further examples the transfer blocking limit may be set to 90%, 100%, or 120% of the total token transfer estimate for that particular further party or group of further parties.

The message generation limits and the transfer blocking limits are effective immediately, once submitted to the system. The messages generated can be in the form of an email, SMS, telephone call or postal services. The message generation unit and the transfer blocking unit analyses, in real-time, the current state of the user's account such that messages and blocks can be implemented immediately. They are therefore enabled with the ability to detect when a message/transfer block is required by utilising the functions of the monitoring unit. The message generation rules and the transfer blocking rules can be based on the current state of any of the further party group's total token transfer estimates (or any other relevant parameter), and are set by the user 102, and or by the system 100. Messages/transfer blocks may also be generated for sub-users, either by the user 102 or by the sub-user themselves.

The message generation unit and the transfer blocking unit can be set up with complex rules, as mentioned previously, to determine when messages/transfer blocks are activated. For example, a rule may be set up that activates the message/transfer block when sub-user A exceeds his/her personal transfer estimate for group A by 10% and sub-user B has 10% of his/her estimate for group B remaining. In a further example the message/transfer block will be activated when the total transfer of tokens from main-user A and sub-user A to a particular group of further parties 104 exceeds the total transfer estimate by 5%. It will be understood that this is purely an example and further rules, and/or combinations of rules, are achievable by the present invention.

The total number of tokens transferred may be reset periodically. For example, in the preferred embodiment the total is reset every calendar month. Therefore, if the total transfer of tokens in a particular calendar month reaches the transfer blocking limit and further transfer is therefore blocked, the transfer of tokens will be allowed again once the total is reset at the end of the calendar month. Therefore the user may control his/her monthly quota of tokens to reduce the possibility of transferring more tokens than the quota allows. The user 102 replenishes the system with tokens at regular intervals, for example once every calendar month; therefore, the number of tokens that may be transferred from the user 102 to the further parties 104 may vary from month to month.

The invention allows for an excess of tokens, over the quota, to be transferred in a particular period of time, and then redeemed in subsequent time periods. The system will automatically assign a portion of the subsequent period's tokens to redeem the advance of tokens until advance is fully redeemed.

A specific embodiment of the invention will now be described, purely by way of example, with reference to the invention as described above.

Instead of a usual banking service where the user is presented with an individual interface for each service the preferred embodiments of the present invention provides a single interface for all of the users banking services. In this way users can manage household expenditure through a single interface which enables them to: construct and monitor a household budget; make a single, regular payment which will eliminate all existing unsecured debts in a reasonable period of time; receive regular expenditure reports, including e-mail/text messages if required; provide multiple cards and a sub budget for each card, suitable for other sub- users related to the main-user.

Banking providers will be able to re-establish a comprehensive relationship with each customer via a service that emphasises shared responsibility. Thus, the banking provider increases customer retention and reduces risk. The resulting database of customer expenditures provides a continuing competitive advantage in new product/feature development.

The system allows for alarms to be set-up for each expenditure group. The alarms are active immediately, once submitted to the system, and can produce alarms in the form of an email, SMS, telephone call or via postal services. A rules based engine is utilised to generate the alarm. The rules based engine analyses, in real-time, the current state of the users account. It is therefore enabled with the ability to detect when an alarm is required and send it to the user informing them of the current situation. The rules can be base on the current state of any of the expenditure group's budget, and are set by the user. Alarms may also be generated for sub-users, either by the user or by the sub-user themselves.

The rules based alarm engine invention provides for three types of alarm to be set-up as appropriate by the user. The three types of alarm are called; notification, warning and alarm. They can be used to notify, warn and then provide an alarm respectively, as to the current state of the budget for each particular expenditure group. For example, the user can be notified when expenditure is at 70% of the budget, warned when expenditure is at 90% of the budget, and given an alarm when expenditure is at 100% of the budget. The individual rules, including each percentage of budget can be determined by the user. The invention provides for pre-formed messages that can be adapted to the specific requirements of each individual user.

In the preferred embodiment the notifications/warnings/alarms are sent to the user via a telecommunications system that is in communication with the main system. The telecommunications system would then send out an email, SMS, or notify an operative to contact the user via telephone or post, with the alarm.

The rules based engine invention also provides for the blocking of further use of the users, or sub-users, electronic payment device, such as a "chip and pin" card or the like, when a pre-defined expenditure has been reached for the respective expenditure group.

The details of the user, including information relating to demographics, is entered into the system in order for the system to create a user account, and to provide information relevant to the user when the user creates a budget based on demographics. The user details will initially be entered into the system by the banking provider, but can be updated by the user through the system interface. The users details can be adjusted for alterations in income sources, such data can be used to decide on budgeting. In addition, sub-accounts can be created, either by the user or the banking provider, to allow the user's child for example to use the account according to predefined parameters. The sub-user's preferences are preferably determined by the main-user, or any other named account holder; however, in alternative embodiments the sub-user may adjust his/her own preferences in at least a limited manner.

In a specific embodiment the further party identification codes are MCC (Merchant Category Codes) assigned to merchants in order that they are recognisable to the banking providers. The system uses the codes to look up the type of merchant and assign it to a group of merchants containing other similar merchants. The system may potentially be able to sub-divide each transaction (token transfer) into the type of purchase made. For example, in a high street department store there is a range of products that can be bought, which may need to be placed in different groups. The system can identify the type of purchase within the store and place the transaction into the appropriate group.

The user may map an MCC to a particular group of further parties. In this case the MCC may relate to a merchant that provides certain ambiguous services, the user may then map the MCC to a more relevant further party group. In some instance this may be undesirable, for example when it is well known what a particular merchant provides, and so in this case the MCC will be locked to a particular group of further parties.

The user may also reallocate certain token transfers from one group to another to more accurately describe the particular transfer event. Again, in some situations this may be undesirable so a block can be placed on certain reallocations to prevent misuse.

Real-time generation of information The website interface is capable of describing real-time information relating to the transfer of tokens between the user and the further parties. Using the identification codes the information is broken down into the relevant further party groups and displayed accordingly.

The information recorded by the recording unit can be reported to the user in various formats. The reporting unit can generate pie charts, executive summaries, or other such methods of conveying the data to the user.

Advances

The website interface also provides access to information relating to any advances provided to the user. Thus enabling the user to keep track of the advances and manage any further redemption of the advances, or further advances.

All of the advances are combined into one group, and can be viewed separately to enable the user to determine the overall exposure. The user may also select, within this section, the period over which he/she will redeem the tokens.

Money Planning and Control Account Account ('MPCA')

Budget Set-up

Figure 2 shows a flow diagram of information relating to the token planning and control account. The customer connects to the MPCA account opening, step 104, on-line via the internet, speaks to the account opener by phone or set up takes place face to face. In the case of the internet there may be a few preliminary questions to determine the plan/budget set-up approach. In the case of phone or face-to-face, the account opener can ask the questions. The following actions would apply depending on the set-up method being used. These actions are in addition to the normal account opening checks relating to knowing the customer for fraud and money laundering purposes. Following account opening the customer will be sent a MPCA Card and cheques in order to operate the account. The customer is assisted in setting up a budget, step 106. This could take a number of different approaches depending on the existing information on the customer and the most useful assistance for this type of customer.

For an existing customer of the bank, the bank can use any data that is already held about the customer, step 108. This could include whether the customer has a mortgage and the amount of the existing payment. It may include known regular payments from the existing bank account, such as utility bills, debt payments and regular standing orders for insurance. It can include known income and the sources from the bank statement, such as employment income and dividends paid automatically. The information would be used to pre-populate a budget/plan, which the customer would tailor as described below.

In a variant embodiment, the customer enters basic details, such as size of house, rented or mortgaged, number of children, hobbies, number of cars and private education, step 110. From this, a budget is pre-populated, which the customer would tailor as described below.

The pre-populated budget uses an algorithm that takes into account the demographics of the customer and the key data that has been identified or provided in order to construct a 'best fit' budget as a starting point for the customer, step 112. The algorithm may use probabilities to determine the likelihood of the budget amount being in a given range given the information obtained on the customer. For example, identifying certain types of utility, expenditure on clothing, supermarkets etc.

In another variant embodiment, the customer will be provided with the cells that should be completed given the basic data, step 114. The customer would be assisted in budget completion with messages that provide information on typical/peer group expenditures in that category. This would enable the customer to benchmark the budget category and make adjustments in the light of the information. The set-up system would highlight budget categories that are missing from the budget/plan, but would normally be expected for customers with these characteristics. The budget could be developed in more than one stage to give the customer a sense of accomplishment as different parts of the budget are completed. For example, household expenditure could be completed at one time and utilities at a later date.

Alternatively, the customer may set up the account and utilise actual expenditure over the following 3 months to create the budget/plan, step 116. The information on peer group expenditures would be provided (as in Step 112) as the plan was populated to enable the customer to benchmark.

The system will contain messages as the budget is created and completed, step 118:

• Need for a contingency amount for unexpected expenditure.

• Savings levels required e.g. for holidays/Christmas. This would be achieved by the capability of entering a requirement amount and when it is required. The system would calculate the monthly saving requirement, which can be automatically put into a savings account to be used for the expenditure at the due time.

• It will advise as to the amount of debt that would be accumulated if a monthly deficit were incurred.

The user can determine the start date of the budget and duration of the budget, step 120. The budget could be weekly, monthly or annual.

Family/sub-account MPCA Cards

The main account holder can issue cards to multiple users for the same account, for example, for the benefit of partners, spouses or children, step 122.

The card can be set up with a budget for items spent on that card, step 124. This could enable a card to be used by a partner for clothing, petrol or another budget category and the expenditure to be monitored. Messaging and Control Set-up

Figure 3 shows a flow diagram of information relating to the messaging and control setup. The customer has the opportunity to set up messaging commands in order to enable him/her to be advised of developments on the account, step 126. The messaging will have many customer options, or the customer can use the standard messaging contained in the system. It will contain the ability for customers to receive trigger messages at certain percentages or absolute amounts of expenditure by budget category. The customer will have the choice as to whether to receive the message by e- mail, text message to a mobile phone, automated phone message or any other communication medium available at the time.

The messages can be phased so that they highlight the seriousness of the difference to the budget, step 128. This could be in the form of stages such as notification, warning or alarm/alert. There can be traffic light colouring used in order to make the nature of the message clear to the user.

The messages can be customised to the user requirement, step 130. If the message is required to be coded to avoid embarrassment of the customer, the customer can choose the messages to be sent under different circumstances.

In addition to the messaging, the customer will have the opportunity to set blocks on the use of the MPCA Card under certain circumstances, step 132. The block could be applied once the expenditure in a category had exceeded a percentage of budget/plan or come into effect when an absolute amount of expenditure has been incurred. The block may be related to the time of use in order to avoid a stolen card being used or to add further controls to the use of sub/family cards. In addition to blocking the use of the MPCA Card in certain outlets, it is also possible to only permit the use of the card in certain categories of outlet.

Messaging and controls/blocks can be set for each sub/family card operating on the account, step 134. The messages can be sent to the main account holder or to the sub account holder or to both. In addition to blocking the use of the MPCA Card in certain outlets, it is also possible to only permit the use of the card in certain categories of outlet.

Expenditure allocation to Plan

Figure 4 shows a flow diagram of information relating to the allocation of expenditure. Actual expenditure using the payment (debit) card for the account is automatically assigned to budget categories using the Merchant Category Code ('MCC) or such other codes as are available in the relevant country of operation, step 136. The MCC or such other codes are an identifier of the type of retailer or supplier. Examples of these codes would include clothing retailer, supermarket or petrol station.

Direct debits/standing orders would be assigned to the correct budget item using codes for the different entities, step 138. This would include water, electricity, gas, local authorities, insurance companies (home, car, health, holiday) and other expenditures that can be identified in this way.

Cash will be totalled for all ATM withdrawals, step 140. It is possible to view the breakdown of the different amounts showing the date and location of the withdrawal. The breakdown can be viewed by clicking on the aggregate amount.

Cheques are totalled in one category for later adjustment to the relevant budget category, step 142. The breakdown (individual cheques) can be viewed by clicking on the aggregate amount.

In a variant embodiment, the individual expenditure items from a retailer such as a supermarket may be separately identified or by category, step 144. This will make it easier to reassign purchases that belong in different budget categories. For example, if children's clothing is purchased in the supermarket, it can be easily identified from the information provided. Customer Adjustments

The system permits the user to re-categorise expenditure between budget categories, but not to remove expenditure entirely, step 146.

The cash and cheque items can be re-allocated to the appropriate budget category, step 148.

Reporting

A base level of reporting will be available to enable the monitoring of the actual income and expenditure against the plan, step 150.

The system contains different reporting formats to show income and expenditure. The user can select the format that they prefer, step 152. One format can be in tabular form, another may use graphics and another may represent the format with diagrams or pictures.

The report will show any categories of expenditure where the actual exceeds the budget/plan, step 154.

The reporting will provide information, in terms of actual against the plan, on each of the family cards or sub-accounts, step 156.

Receiving Messages

An example of a message would be as follows:

• This text is to advise you that your supermarket expenditure for this month has exceeded £450 and/or it has exceeded 90% of your budget for the month. Messages can be sent by the account provider to advise the user that the budget is not being achieved, step 158. The user can be advised to make contact with the account provider. An example would be as follows:

• This message is to alert you that your budget is resulting in increasing debt. Please contact us to arrange to discuss your current financial situation.

The system provides that messages can be sent in accordance with different instructions on different payment cards operating on the account for different cardholders, step 160.

• Cardholder 2 has a trigger message set for clothes shops, this is not the same as the overall budget for clothes.

The system allows messages to be sent at a time specified by the user, step 162. For example, the user may only require text messages to be sent between 7.30 am and 11pm.

Loan payment

Figure 5 shows a flow diagram relating to loan repayment. There will be one loan payment and it will be at the level to repay the loan in a reasonable time period (e.g. 5 or 7 years). This will enable the user to understand the commitment they are entering into and include in the budget planning. The customer may have separate loans for different purchases (e.g. a car loan) in order to prepay the loan if they so choose.

The loan is revolving i.e. it is re-set every month. Interest is charged on the amount out- standing.

Usage for Small Businesses

The account can be amended to make it useful to small businesses.

Different people within a small company can use the sub-accounts. The totals of individual categories can be used as a component of tax returns.

Summary

In summary in respect of this particular embodiment:-

1. This is the first bank account in which the system is designed to help the customer identify an affordable level of borrowing.

2. The account assists the user to produce a realistic expenditure plan making it more likely that a plan is produced and used.

3. The account provides a complete report of expenditures, both overall and by category, compared to plan and past periods.

4. It is the first account to accept instructions from the customer to facilitate account management and expenditure planning. The instructions are used to send messages to the customer to assist with expenditure management. These messages may be by text, e-mail or using another form of communication technology.

5. The account permits different family members to have separate cards each with expenditure plans and limits within the master accountholders expenditure plan.

6. One key feature is to provide users with expenditure data from others in comparable circumstances — in effect, a standard profile against which to plan their expenditures.

7. The account offers users multiple levels of assistance in planning and managing expenses, including automated help and financial planning-management training. The account can educate and support customers in sound financial management. 8. The account provides issuing banks with a uniquely rich set of data on customer plans and expenses, facilitating targeted marketing and more proactive, effective risk management.

This invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

Any reference numerals appearing in the claims are for illustrative purposes and are not to be construed as limiting the claims in any way.

Claims

1. A system for analysing the transfer of tokens from a user in a plurality of categories, including; summing means for providing respective totals of token transfer for each category; and means for providing an output of said analysis; wherein the output is dependent on the respective total transfer of tokens from the user for each category.

2. A system according to Claim 1, further comprising means for allocating at least one identification code to each category.

3. A system according to Claim 1 or 2, wherein each said category contains one type of further party, there preferably being a plurality of further entities in each category.

4. A system according to Claim 3, further comprising means for allocating an identification code to each such further entity.

5. A system according to any of Claims 4, further comprising a look-up table associating further entities and categories.

6. A system according to any of the preceding claims, wherein a limit is provided for each said category.

7. A system according to Claim 6, wherein said analysis is dependent on said limit.

8. A system according to any of the preceding claims, wherein said output is in dependence on the overall total transfer of tokens in all of the said categories.

9. A system according to any of the preceding claims, wherein said output is an action.

10. A system according to Claim 9, wherein said action blocks further transfer of tokens from the user in a given category.

11. A system according to Claim 10, wherein the transfer of tokens is blocked when a pre-determined number of tokens has been transferred.

12. A system according to Claim 11, wherein said pre-determined number of tokens is defined by said system.

13. A system according to Claim 11 or 12, wherein said pre-determined number of tokens is defined by said user.

14. A system according to any of the preceding claims, wherein said output is a message.

15. A system according to Claim 14, wherein a message is communicated to said user when a pre-determined number of tokens has been transferred in a given category.

16. A system according to Claim 14 or 15, wherein the content of said message is dependent on the number of tokens transferred in the given category.

17. A system according to Claim 15 or 16, wherein said pre-determined number of tokens is pre-determined by said system.

18. A system according to Claim 15, 16 or 17, wherein said pre-determined number of tokens is pre-determined by said user.

19. A system according to any of Claims 14 to 18, wherein said message is communicated to said user via email, SMS, telephone, post, or any other such method.

20. A system according to any of the preceding claims further comprising means for profiling said user.

21. A system according to Claim 20, wherein said user is profiled in dependence on said user's personal details.

22. A system according to Claim 20 or 21 , wherein said profiling uses said user's total token transfer in a given period of time.

23. A system according to Claim 20, 21 or 22, wherein said profiling uses said user's total token transfer in each said category.

24. A system according to any of Claims 20 to 23, wherein said profiling is in dependence on the sequence of token transfers.

25. A system according to any of Claims 20 to 24, further comprising means for generating a transfer estimate, wherein said estimate is generated in dependence on said profile.

26. A system according to Claim 20, or 21 , wherein said means for profiling uses pattern recognition.

27. A system according to Claims 25 or 26, wherein said transfer estimate is generated in dependence on said pattern recognition.

28. A system according to any of the preceding claims, further comprising means for reporting said transfer of tokens from said user in a plurality of categories.

29. A system according to Claim 28, wherein said reporting means operates via the internet.

30. A system according to Claim 29, wherein said reporting means operates via the Public Service Telephone Network.

31. A system according to any of the preceding claims, wherein said system is adapted to analyse the transfer of token from at least one main-user and at least one sub-user.

32. A system according to Claim 31, wherein the output is individual to the or each said at least one main-user.

33. A system according to Claim 31 or 32, wherein the output is individual to the or each said at least one sub-user.

34. A system according to Claim 33, wherein the or each main-user pre-determines the output for the or each sub-user.

35. A system according to Claim 33 or 34, wherein the or each sub-user may not predetermine said output.

36. A system according to any of the preceding claims, wherein a pre-determined number of tokens is available for said user to transfer in each category, typically over a predetermined time period.

37. A system according to any of the preceding claims, wherein said user is provided with additional tokens that can be transferred.

38. A system according to Claim 37, wherein all of said additional tokens are redeemed at a rate dependent on said user's pre-determined number of tokens.

39. A system according to any of the preceding claims, wherein said categories are categories of merchant or merchandise.

40. A system according to Claim 2, wherein the identification codes are MCCs.

41. A smart card for use in a system according to any of the preceding claims, wherein said smart card is adapted to transfer tokens from said user.

42. A computer-readable signal or carrier wave adapted to be propagated over the internet between computers, said signal containing a set of instructions comprising: code for analysing the transfer of tokens from a user in a plurality of categories; summing code for providing respective totals of token transfer for each category; and code for providing an output of said analysis; wherein the output is dependent on the respective total transfer of tokens from the user in the plurality of categories.