WO2001065460A2 - Procurement and diet management system and method - Google Patents

Abstract

A procurement and diet management system operable over the Internet provides personalised diet and exercise recommendations according to stored user and group profiles and goals. Avatars are used to display progress towards the goals. The system facilitates procurement of goods and services, including those recommended by the system and allows users to choose delivery options.

Description

PROCUREMENT^' AND DIET MANAGEMENT SYSTEM AND METHOD

BACKGROUND OF THE INVENTION FIELD OF THE INVENTION The present invention relates to a system and method for diet management and procurement of goods or serivces over a network, particularly but not exclusively a public packet-switched data network such as the Internet.

Various dietary sites, such as CyberDiet.com™, eDiets.com™ and phys.com are currently available on the Internet. These sites provide general dietary advice and have interactive content, such as calorie counters, menu planners and Body Mass Index calculators.

However, existing dietary sites do not facilitate personalised weight loss or other dietary programmes and therefore do not encourage users to revisit the site regularly, as the information provided does not change and is not tailored to the individual user.

US Patent No. 5,951.300 describes a system for providing on-line composite health education and entertainment in which the health profile of a patient is input and personalised health information is subsequently displayed to that patient. The system does not require patients to request health content or update their health profiles, on the assumption that many patients will not actively seek health information.

US Patent No. 5,908,301 describes a system for modifying a user's eating behaviour, by means of a self-contained device which prompts the user when to perform actions such as drinking water and chewing. The user enters current and target physical parameters and the device establishes a control program based on these values.

US Patent No. 5,542,420 describes a system for prescribing a suitable diet to users based on their personalised health characteristics. Information about food consumed and medical data is entered at terminals and communicated to a 'health computer', which determines the dietary prescription.

AIMS OF THE INVENTION

One of the aims of the present invention is to provide a dietary management system and method which provides personalised information and/or recommendations to users, . according to their individual preferences, which .are recorded by the system .and updated as the user makes choices based on the information or recommendations.

An additional or alternative aim of the present invention is to provide a dietary management system which classifies users into appropriate groups and provides information to or performs services for a user at least partly on the basis of information relating to the group or groups to which the user may belong.

An additional or alternative aim of the present invention is to provide dietary information or recommendations to users on the basis of factors other than their nutritional requirements, such as individual taste preferences and/or the local factors (e.g. price, availability) for different foods and/or religious or cultural preferences and/or time of day, day and/or season, and/or health factors such as allergies.

An additional or alternative aim of the present invention is to allow users to combine an interactive personalised exercise programme with their dietary programme. An additional or alternative aim of the present invention is to facilitate the procurement of goods, such as foods recommended as part of the dietary programme, and/or services.

An additional or alternative aim is to allow the user to visualise the effect of their dietary programme on their appearance. SUMMARY OF THE INVENTION

According to one aspect of the present invention, there is provided an electronic system in which users receive individual meal recommendations based on taste preference data. The taste preference data may be modified to reflect meals selected by the users.

According to another aspect of the present invention, there is provided an electronic system in which there is stored information on local availability of ingredients and user records of the locations of different users. Food recommendation data is presented to the users on the basis of the availability of the constituent ingredients at the location of the respective users.

According to .another aspect of the present invention, there is provided an electronic system in which there is stored information on preferred times for different foods, and food recommendation data is presented to users on the basis of a specified time.

According to another aspect of the present invention, there is provided an electronic system which stores information on the calorific values of different foods, receives information on the physical characteristics of different users and provides information on recommended foods to users on the basis of their received physical characteristics.

According to another aspect of the present invention, there is provided an electronic system which stores records of users, at least some of which are classified into groups. In one more specific aspect, the system stores records of different foods, receives food selections from the food records from different users and compiles group lists relating to foods selected by multiple users from the same group. The group lists may be transmitted to some or all of the users of the respective group, or to another party. In another more specific aspect, the system provides dietary information to the users. If a user has not accessed the system for more than a predetermined length of time, the system notifies other users in a specified group to which the user belongs. Explicit permission for this function may be required from the user. In another more specific aspect, the system stores information about individual or group preferences which are used to select options for individual users. Group preferences may be modified according to selections made by individual members of the group, or individual preferences may be modified according to selections made by other members of the same group.

According to another aspect of the present invention, there is provided an electronic system which periodically receives data representing physical characteristics of users, and displays to the users a graphical representation of their physical appearance.

According to another aspect of the present invention, there is provided an electronic system which receives data entered by users representing actual and target physical characteristics of users and displays to them a graphical representation of both their actual and target physical appearance.

According to another aspect of the present invention, there is provided an electronic dietary management system which stores records of the individual ingredients and preferably the nutritional properties of each ingredient of meal recommendations, so that these can be closely matched to users' requirements, which may be defined in terms of Recommended Daily Allowances and/or other such standards.

According to another aspect of the present invention, there is provided an electronic system for confirming, at a completion stage, transactions initiated electronically. A confirmation is recorded at the user's terminal on a physical medium in an electronically readable form and the user presents the physical medium at a point of delivery to confirm the details of the transaction, such as discounts specific to the transaction. Preferably, the details are recorded in a printed bar code. The transaction may be time- dependent, in which case the details are verified at the time of fulfilment, to confirm that any time-dependent conditions have been satisfied.

BRIEF DESCRIPTION OF THE DRAWINGS

Specific embodiments of the present invention will now be described with reference to the accompanying drawings, in which:

Figure 1 is a diagram of the connections of a server to user terminals and other servers in embodiments of the present invention;

Figure 2 shows an example of the architecture of the server of Figure l; Figure 3 is a flow diagram of the functions performed by a diet management application run on the server;

Figure 4 is a diagram of the data inputs and outputs of the diet management application;

Figure 5 is a diagram of the structure of a user record in the database of Figure 4; and

Figure 6 is a diagram of the structure of the meals database used by the system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS SYSTEM ARCHITECTURE

As shown in Figure 1 , a diet management system in an embodiment of the present invention is implemented by a software application running on a main server 2 connectable via the Internet 4 to other servers, such as an ISP server 6, an interactive TV network 8, and a wireless network 10, which allow access to the main server 2 by user terminals in the form of general purpose computers 12, wireless mobile terminals 14 and interactive TV equipment 16 respectively. Only one of each type of user terminal is represented, but it will be understood that a very large number of user terminals may communicate with the main server, limited only by the latter's capacity. Software compatible with the diet management system runs on the user terminals. The software may be generic internet and/or communications software, or be customised for the diet management system, for example by the use of 'plug- in' software.

The main server 2 is also connected to a circuit-switched network 18, such as a PSTN or ISDN, allowing audio access by telephone equipment 20 and data access by data terminals 21. Dial-in or leased line data communication access to the main server 2 may also be available to wireless networks 10, general-purpose computers 12 and interactive TV networks 8. However, the Internet is the preferred means of data communication, because of its near-global availability and ease of access.

For simple input, users of telephone equipment 20 may dial directly into the main server and enter information on a keypad when prompted audibly to do so. Alternatively, users may dial up a call centre and exchange more complex information with an operator, who enters information on and reads information from a data terminal. Thus, the circuit switched network 18 may be directly or indirectly connected to the main server 2. The user may also request specialised help from an adviser, who then sets up a voice call to the user, either via the Internet 4 or circuit switched network 18.

An advantage of the diet management system is that various different types of input and information presentation terminals are available to users. However, the following description will refer generically to input, presentation and transmission, it being implicit that certain types of input or presentation may not be possible with certain types of user terminal; for example, telephone equipment 20 is not capable of graphical display unless coupled to a suitable graphical data terminal.

The main server 2 is also connectable via the Internet 4 or circuit switched networks 18 to other servers 5, 7, such as hosts of affiliate websites, third-party databases of dietary or other information, and supplier (merchant) databases to permit it to offer its selections in terms of regionality and seasonality.

One example of the architecture of the main server 2 is shown in Figure 2. The main server 2 consists of one or more processors 22 connected to an internal bus 24 allowing read/write access to main memory 26 and a large non-volatile store 28, such as a hard disc array. The internal bus is connected, either directly or via a suitable high-speed port, to a router 30 connected to other internet routers and implementing internet routing protocols, to a modem array 32 having multiple lines for connection to a PSTN, and to a data protocol adapter 34, such as an ISDN terminal adapter.

The diagram of the main server 2 in Figure 2 is provided purely by way of example, as the skilled person will be aware of other suitable architectures. The important properties of the main server 2 is that it is connectable to a network, has the necessary capacity to serve a large number of users, and is able to store, update and present information from a database of user records and dietary information records. Preferable features include the ability to access the main server through alternative networks. The database need not be collocated with the main server 2, but may be accessed remotely via a suitable communications link.

DIET MANAGEMENT APPLICATION

Figure 3 is a flow diagram of the functions of a diet management application running on the main server 2, using suitable internet database management software, such as currently available from Oracle Corporation and others, which accept user input, process database records and present the results to the user in dynamic HTML.

The default method of user access is through the World Wide Web, which is well-known to skilled persons, so that details of the necessary protocols, browsers, modems and other generic aspects will not be discussed further. Instead, the following description will concentrate on those features which are specific to the diet management application.

For ease of reference, the diet management system will be referred to hereafter as 'the system'. It is implicit in this reference that the actions performed by the system are carried out by the diet management application running on the main server 2, unless otherwise stated.

ACCESS AND LOGIN At a first stage, users access the system either through the system home page (S1.0), or via various affinity web sites, for example food, exercise or corporate health-related sites Affl, Aff2, Aff3.

At a login stage S2, users identify themselves to the system, for example by providing a user name and password. New users may register, at stage S2.0, by providing user details, and optionally account details if use of the system is to be charged to the user, and a new user name and password is established to enable the new user to log on to the system.

Users who have been transferred from an affinity site Affl, Aff2, Aff3 may already have logged in to that site. In that case, the affinity site may transfer user details directly to the system so that the user does not have to log in again.

USER DETAILS

At a user profile display and input stage S3, the user is presented with currently stored user data, including user profile, goals and progress records, and is allowed to input new data and modify existing data, as explained in more detail below. At stage S3.0, additional information is presented to the user on the basis of the new or modified data. At stages S3.1, S3.2 and S3.3, a similar process takes place to that at stage S3, but tailored to the users linked from the affinity sites Affl, Aff2 and AfT3 respectively.

Referring to Figure 4, the database includes for each User a User Detail record, comprising the user details provided when the user was accepted as a new user, with any amendments subsequently made by the user. Referring to Figure 5, the user details include a USER record, which records details which do not change (apart from Post Code), as shown in Table 1 below. Initially, storage capacity may be provided for 2 million active users, and hence for 2 million USER records.

Table 1 - USER

Label Description

UserlD Defines user (8 Characters)

FirstName First name

LastName Last name

Gender Gender (M/F)

UnitPreference Sets metric or imperial units for display and input

Height Height

LegLength Leg Length

ArmLength Arm Length

FootS ize Foot Size

DOB Date of Birth

PUK Immutable password in case current password is forgotten

Active Whether Active (Y/N)

PostCode Current Post/Zip code - repeated from USERDET record for faster access

LogDT Log date of record The USER record is marked as inactive when the user has not logged on to the system for 6 weeks. The system sends the user an e-mail after every week in which the user has not logged on, with the nature of the e-mail changing after every successive week that the user does not log on. User details which change slowly are stored in a current User Detail record USERDET, the format of which is shown below in Table 2. Assuming that these details change no more frequently than the record is .archived (every 6 months), approximately 10 million USERDET records will be needed.

Table 2 - USERDET Label Description

UserlD Identifies user - links to other records relating to same user

Type Flexible record for indicating address, current post code, credit card numbers, PINs etc. Permitted values are defined in Type table

TDET Value Value of information specified in Type field Active Y/N - Current record is active, historical records are inactive LogDT Log date of record

REWARD POINTS

The system allows the user to accumulate and carry out transactions with different types of reward points, such as Beenz, Airmiles and Clickmiles.

For example, reward points may be awarded for using the system or achieving goals, and may be spent on additional services provided or advertised by the system. Reward point information is stored in a record REWARD formatted as shown below in Table 3. Assuming an average of 10 transactions per archive period, the number of REWARD records required will be 100 million. Table 3 - REWARD

Label Description

UserlD Identifies user - links to other records relating to same user

TRewardlD Type(s) of Reward Points

Transaction Transaction records

Rewards Values of Reward Points

Balance Balance of Reward Points

LogDT Log date of record ^•

The TRewardlD field is linked to a TREWARD table, which stores the names, operators, start and end dates of different reward schemes.

MEASUREMENTS AND GOALS

Each user is required to set Diet Goals (see Figure 4), which .are recorded in a GOALS record as shown below in Table 4. Assuming new goals are set every month, between 12 and 60 million GOALS records may be needed.

Table 4 - GOALS

Label Description

UserlD Identifies user - links to other records relating to same user

TargetWeight Target weight

TargetWaist Target waist

TargetHips Target Hips

TargetDate Date by which target is to be achieved

TCauselD Reason for dieting - choice from a list in record TCAUSE

TActivitylD Type of Activity Level - Linked to Table of possible values - TACTIVITY

Active Whether record is current or historical LogDT Log date of record

The system allows users to set various parameters, such as target weight, target waist, and the date by which the target is to be achieved. However the system rejects unrealistic goals, such as losing more than 2 lb. (0.9 Kg), or 1,2% of body weight per week. Alternatively, the user may be prevented from submitting such unrealistic goals to the system by software, such as an 'applet', running on the user terminal, or by an operator at the call centre. To enable the system to compare the user's performance against the goals, and to provide suitable health-related advice, the user is prompted to enter variable measurements as described below.

The current and historical physical dimensions of the user are stored in a RECORD record shown below in Table 5. Assuming new dimension records are entered every month, between 12 and 60 million RECORD records will be needed. Table 5 - RECORD

Label Description

UserlD Identifies user - links to other records relating to same user LogDT Log date of record ProfileSet Identifies the Profile Set against which one aspect of the user profile can be measured. Each profile set measures a different aspect - food, exercise, etc.

Value 1 The Value of Value 1 for this Profile set Value2 Ditto for Value 2 ValueS Ditto for Value 3 Value4 Ditto for Value 4 Value5 Ditto for Value 5 Active Whether this record is active. There can only be one active record for User and each Profile set

Profile Sets are used to store sets of information about each user. One such set is a physical information set containing Weight, Waist and Hips measurement fields; another is a preference set containing food taste preference fields, exercise preference fields, and other fields. Each Profile Set is described in detail in a PROFILE record as shown below in Table 6:

Table 6 - PROFILE

Label Description

ProfileSet The ID of the Profile Set ProfileName The name of the Profile Set ProfϊleDescr The description of the Profile Set Value 1 Name The Name of Value 1 (Each Profile Set has 5 Values) Value IDescr The description of Value 1 Value 1 Max The maximum value for Value 1 Value IMin The minimum value for Value 1 ValuelDefault The default value for Value 1 Value lUsrlncr The amount by which Value 1 is incremented when user entered

Value IGrpIncr The amount by which Value 1 is incremented when Group entered

Value2Name The same set of records is repeated for each of Values 2 through 5

Etc....

Value5 G lncr LogBy The person who has entered the information in this record

The system calculates useful indicators of the user's health, fitness and dieting needs from the USER, RECORD and PROFILE records, and displays these to the user. For example, the system calculates the Body Mass Index (BMI - mass in kg divided by the square of the height in metres) and indicates the implications of the calculated value of BMI graphically. If the BMI lies between 19 and 22, the colour green is displayed to indicate that the value is ideal; if between 22.1 and 24.9, the colour orange is displayed to indicate risk; above 25, the colour red is displayed to indicate danger. If the BMI is 30 or above, or below 19, the system will withhold dietary information from the user and display a message advising the user to consult their doctor.

At stage S4 shown in Figure 3, the user may select different support options in order to obtain information, advice or encouragement about their diet and exercise goals and progress, either in the form of an electronic display, or by requesting a call from a human adviser who has access to that user's records. The supply of external support information is represented by step 4.0 in Figure 3.

EXERCISE

The user is required to enter a general level of exercise, which is recorded in GOALS as shown above in Table 4. As an option, the user may enter a specific type of exercise performed on a particular day. The system may suggest suitable exercises compatible with the user's general level of exercise, or suggest a higher level of exercise to assist with the user's diet.

The selected type of exercise is recorded to allow the daily calorie allowance of the user to be adjusted accordingly.

As shown in Figures 3 and 4, the user may enter Activity Goals, such as a minimum level of exercise to be performed each week, at stage S3, S3.1, S3.2 or S3.3. The user may also enter or amend details of actual exercise performed each day and the system indicates whether the user has met the Activity Goals, and if not how much more exercise is needed to achieve these. The system performs checks to ensure that the Activity Goals are not unrealistic on the basis of the user's exercise history .and other details of the user profile.

At step S6 (S6.2 for users from the affinity site Aff2) an Exercise Engine, as shown in Figure 4, derives a list of Activity Choices to be performed on a particular day. The Activity Choices are presented to the user (step S6.0) and the user selects one of these options. More advanced users can simply select the number of Calories to be expended in exercise that day. If the user actually performs a different activity, or none at all on that particular day, this selection can be subsequently amended at stage S3, S3.1, S3.2 or S3.3. The user's exercise details are stored in records including the UserlD, an Activity type code linked to an Activity type table and indicating the type of activity, the duration of the activity, and the Calories burned, as calculated by the Exercise Engine according- to the user's current weight, activity type and duration. The Activity Choices are selected so as to match the user's activity goals. The Exercise Engine also takes into account the user's previous selections of Activity Choice in compiling the current list of Activity Choices. For example, if the user has never or seldom selected a certain type of exercise, this type of exercise is no longer included in the Activity Choices.

AVATARS

Advantageously, at stage S4, the system displays to the user a representation of their current and/or target bodily shape, to encourage the user to achieve their dietary goals. This type of virtual representation of a user is often referred to as an avatar, but is most commonly used by internet-based software, such as Virtual Places chat software, to represent a user to other users. The avatar of the present system may also be used in this way by other applications within the system, such as in a virtual chat room in which users may discuss diets and fitness. The weight and dimensions from the USER, GOALS, RECORD and

PROFILE records are submitted to a graphics routine which generates a representation of a human body to scale having the specified weight and dimensions. The avatar may be further customised to resemble the user more closely, by allowing the user to input additional physical dimensions and characteristics. Advantageously, the user uploads to the system via a highspeed data connection a digital photograph of their face or whole body which is mapped by the system as a 'skin' or surface pattern onto the representation of the human body, and displayed to the user. Alternatively, to reduce the bandwidth requirements between the system and the user terminal, the system may transmit the necessary parameters to graphical software running on the user terminal, and the digital photograph is stored and manipulated locally at the user terminal.

Optionally, the user may modify the avatar by selecting specific clothing, hairstyle .and/or makeup, selected from a range of options presented by the system. This feature allows the user to create an ideal look for the target avatar, for example, or simply to make either the current or target avatar look more like the user. The system creates a USER DRESS record of the options selected, of the form shown below in Table 7:

Table 7 - USER DRESS

Label Description

UserlD Identifies user - links to other records relating to same user

TasteType Selects a category from a Taste Type table, such as Fabric, hairstyle, makeup, lipstick Taste Val Selected option for the category indicated by TasteType, such as floral, Bouffant, dark red LogDT Date record logged

The USER DRESS records are processed to generate reports of the tastes of the users. Additionally, the system may recommend to the user specific items of clothing or beauty products from affiliate web sites, based on the selected options. GROUPS

Thus far, all of the information used as input by the system relates to an individual user. However, the participation of peer groups or families plays a large part in successful dieting. The system allows the user to join one or more groups of other users and takes into account properties of that group, as explained below.

The system stores GROUPUSER records each of which records the membership of one group by one user, as shown below in Table 8:

Table 8 - GROUPUSER record

Label Description

GroupID Identifies group

UserlD Identifies user member of group

StartDT Start date of membership

EndDT End date of membership

Active Whether record is current or historical

As shown in Figure 5, the existence of each group is recorded in a GROUP record, as shown below in Table 9: Table 9 - GROUP record Label Description

GroupID Identifies group

GroupName Name of group

Active Whether record is current or historical

LogDT Logging date of record

Membership of a group is either selected by a user or inferred by the system. For ex-ample, users referred by an affinity site are automatically entered into a group specific to that site. As another example, the system detects multiple users resident within the same local area, and asks those users to confirm whether they wish to be added to a neighbourhood group. For neighbourhood or affinity groups, each user is asked whether they have preferences (e.g. gender specific) for the type of other members of the group. Users who wish to form a group, for example having discussed their diets using the chat room facility, may set up user-defined groups by having one prospective member select a name and password for the new group, and allowing other users to join the group if the correct password is supplied.

A family group is automatically created for each new user, unless the user indicates that they wish to join the family group of an existing user, in which case the user name and password of the existing member are entered and, if recognised by the system, the new user is added to the family group of the existing user.

The family group is used by the expert engine to co-ordinate the meals and shopping lists of each member. Thus, when selecting meals for suggestion to a user, the system looks up the menu selections, if any, of the other members of the family group and, if those menu selections are compatible with the nutritional requirements and diet goals of that user, includes those menu selections in the options displayed to that user, indicating which other family member has chosen that option.

The system also creates group shopping lists and restaurant orders for family groups. Thus, instead of creating an individual shopping list or restaurant order as described above, the system adds the ingredients or meal orders for the current user to the family group shopping list or restaurant order. The system indicates to the user whether all of the family group members have made a menu selection for a specific day or meal and allows the user to complete the shopping list or order. The completed shopping list is displayed or sent to the user, for example as an e-mail, and a new group shopping list is created. Likewise, a completed order is sent to the relevant restaurant or restaurants and a new group order is created.

Groups are also used by the system to encourage members of a group to support other members who are failing to use the system. For example, if a user has not logged onto the system for a certain period of time, such as three weeks, the system sends an e-mail to other members of the group encouraging them to support that user. For privacy reasons, this feature is only enabled if selected by the user.

GROUPUSER and GROUP records are also used by the system to store further information about groups of users. For example, language group records are used to record the preferred language of users. The system looks up the language group of the user and uses this information to determine the language in which text is displayed to the user and the language used to deliver information over the telephone. Language groups are also used by the system, preferably in conjunction with address information, to select meal options. For example, a Chinese speaker living in London may have food tastes which are more typically Chinese than Western. Currency groups are used by the system to identify the currency in which a user should be charged for goods or services.

PROFILES

One particularly advantageous feature of the system is its ability to record the user's changing preference profiles and provide information or recommendations to the user based on those profiles. One function of the user profiles is to recommend menus customised to the individual nutritional needs and dieting goals of each user, and to a food preference profile for each user. Before a user has made any menu choices, the system sets an initial food preference record for that user, based on a group food preference record for the cluster group to which the user belongs. The cluster group is determined by the user's entry point into the system (there may be several URL's for different 'flavours' of the site) or by interrogation of the user.

The user's taste profile is recorded as a three-digit code from 000 to 999, with each digit representing one quality to be matched to possible meal options (e.g. intensity/blandness, complexity of preparation, sophistication), but more digits may be used to record other qualities.

The system creates PROFILE records of the user's food preferences and nutritional requirements, as shown above in Table 5. The system also maintains a current requirement for the user in terms of the recommended daily allowances for the various components if ingredients as shown below in

Table 10.

Table 10 - USERREQ Label Description

UserlD Identifies user - links to other records relating to same user

CalReq Daily calorie requirement

CarbReq Daily carbohydrate requirement

ProtReq Daily protein requirement

FatReq Daily fat requirement etc.

Active Whether record is current or historical

Log DT Date of logging record

INGREDIENTS

The system includes a database of nutritional information on ingredients and meals composed of those ingredients, represented by Figure 6.

About 5,000 records of different basic ingredients are stored. INGREDIENTS records are of the form shown below in Table 11 : 2

Table 11 - INGREDIENTS

Label Description

IngredID Identifies ingredient FoodGroup ID Identifies food group of ingredient (beans, beverages, dairy products, milk & cream, fats & oils, fruit and fruit juice, grain products, pasta, condiments, meat, nuts, seeds and related products, seafood, vegetables and vegetable juices, candies)

PortionID Standard portion size for this ingredient

Water Water content per standard portion (g)

CalCon Calorie content per portion (kcal)

Protein Protein content per portion (g)

Carbohydrate Carbohydrate content per portion (g)

Glycemic index Glycemic index

Dietary Fibre Dietary Fibre per portion (g)

Calcium Calcium per portion (mg)

(other nutrients) (individual records for other nutrients)

Fat Total fat (g)

Fat: Saturated Saturated Fat (g)

Fat:Monounsaturated Monounsaturated Fat (g)

Fa Polyunsaturated Polyunsaturated fat (g)

Cholesterol Cholesterol (mg)

HCA Hydroxycitric acid (mg)

LogBy Source of Information

LogDT Logging date of record

The contents of the INGREDIENTS records may be based on the USDA Ingredients database, but further fields may be added to accommodate the ingredient breakdown formats of other authorities relevant to the countries in which the system operates.

The system also stores a database of products (Prodlngred in Figure 6) which comprise the ingredients required for the menu options. Information on these products, such as pack size and nutritional content, are obtained from the manufacturer.

MEALS

The system also stores MEALS records which store the composition of different meals in terms of the quantity of different ingredients stored in INGREDIENTS records, in the form shown below in Table 12: Table 12 - MEALS Label Description

MeallD Identifies meal

IngredientID Lists the identities of the ingredients which make up the meal Quantity Lists the quantity of each ingredient

LogBy Source of Information

LogDT Logging date of record

An additional field may be included, identifying any preferred time of day for the meal or type of meal (morning, midday, evening, snack or drink).

For each meal, the system stores a set of 1000 MEALMATCH records of the degree of matching between that meal and each user taste profile, from 000 to 999, as shown in Table 13: Table 13 - MEALMATCH Label Description

MeallD Identifies meal

PersTasteA First digit of user taste profile

PersTasteB Second digit of user taste profile PersTasteC Third digit of user taste profile

Match Degree of matching between meal and the user taste profile

(%)

The MEALMATCH records simplify the task of matching meals to the individual user's tastes, as will now be described.

MEAL RECOMMENDATION

The system determines a customized menu for the user, represented as stage S5 (or S5.3 for users from affinity site Aff3). An expert engine EE, forming part of the system, and represented in Figure 6, looks up from the stored records the nutritional requirements of the individual user, the user's food preference tastes, the user's dietary goals, and the user's current level of exercise and calculates personalised taste and nutritional requirements. The expert engine then selects, from the MEALS records, individual meals or combinations of meals for the next 24 hours or a longer predefined period which closely match the taste and nutritional requirements of the user. The selection for taste match is taken by selecting the MEALMATCH records containing a profile closest to the user's current profile and then extracting the MEALS records corresponding to the selected MEALMATCH records.

Preferably, at least three options are presented for each meal, and are displayed to the user for selection (step S5.0). The user then selects one of the options for each meal, or chooses another meal which was not selected by the expert engine, for example by a keyword search of the MEALS records or the component ingredients of each meal. For example, if the user does not have the ingredients required for any of the suggested meal options and does not wish to shop for those ingredients or order the complete meal, the user may search using the names of those ingredients which are available. The expert engine calculates the total permitted calorific content for meals in the selected day, on the following basis. First, the basic number of Calories (kcal) needed to maintain the user's current weight is calculated by multiplying the user's current weight in kg by 30. For example, an 80 kg person is assumed to require 2400 kcal/day. Next, an exercise allowance is added according to the user's activity level, or for specific exercises selected by the user for the previous day. The system stores a table of calorific equivalents of specific exercises and of general activity levels and looks up the additional allowance from this table. The total of the basic and exercise allowance is reduced by a weight loss amount according to the weekly weight loss set by the user's goals. To lose 0.5 kg per week, 500 kcal/day must be subtracted from the daily allowance. Hence, the weight loss amount is calculated by subtracting the value of Target Weight from the value of Weight, dividing the result by the number of days between TargetDate and the current date, and multiplying by

7000. If the user wishes to gain weight, then the Calorie reduction will be calculated as negative and the daily Calorie allowance increases.

Next, the expert engine EE divides the total daily allowance into calorie ranges for each meal type, for example as shown below in Table 14:

Table 14 -Consumption Profile

Meal Type Average Min Max

Morning 20% 15% 35%

Midday 30% 15% 35%

Evening 25% 15% 35%

Snacks 10% 0% 15%

Drinks 15% 0% 20%

For each meal type, the expert engine selects meal options which fall within the permitted Calorie ranges. As the user makes a choice for each meal type, the meal options for the meal types not yet selected are adjusted to stay within the proportions identified for the respective meal type. When the last choice is made for a particular day, the total calorific value may be greater or less than the daily allowance. If the shortfall or excess is greater than a threshold percentage, such as 5% or 10%, the user is warned of this and asked to confirm the selection for that day.

Advantageously, the system takes into account further user-defined or user-dependent criteria when selecting and presenting meal options to the user. In one option, the user selects a particular type of diet regime, such as vegetarian, Atkins diet or cabbage diet. The system stores a set of rules for all commonly encountered diet regimes and the expert engine applies these rules to the MEALS records to select only those meals which comply with the diet regime. For example, the rules may exclude specific ingredients or food groups, or combinations of specific ingredients or food groups within the same meal.

In another option, which is selectable by the user, the expert engine takes into account the country or area of residence of the user, as stored in the USERDET record, and/or the current day, month or season. The INGREDIENTS record may include a field listing the countries or areas in which the ingredient is available, and/or the date range for each country within which the ingredient is available. The expert engine then selects for presentation to the user only those meals which use ingredients available in the user's area on the day or within the period for which the user requests meal recommendations.

In another option, the system detects whether the day for which the meal suggestions are requested is a special day for that user. A special day may be the user's birthday, which is detected from the USER record, a national holiday in the user's country of residence (e.g. Thanksgiving in the US) or a religious festival appropriate to the user (e.g. Christmas), if the USERDET or USER records include a field indicating the religion of the user. The system stores a table of special days for each user, together with a meal option selection rule appropriate for each special day (e.g. select one meal with turkey, ham or goose as an ingredient for Christmas or Thanksgiving; allow a certain percentage increase in calories for a birthday).

The system stores MENU records which record what menu was allocated by the system for each meal for a given user, and what the user actually selected to eat. Six different 'meals' can be recorded per day, comprising morning, midday and evening meals, snacks, drinks and supplements. Assuming that all six meals are recorded per day by each of 2 million users, and allowing for a six month archive period, 12 billion MENU records are needed. The MENU records have the format shown below in Table 15:

Table 15 - MENU

Label Description

UserlD Identifies user - links to other records relating to same user

Date Date

MealTimelD Identifies type of meal (morning, midday, evening, snacks, drinks, supplements) MeallD 1, Identify the first, second and third meals suggested by the

MealID2, system

MealID3 MeallDChoice Identifies which meal (suggested or otherwise) the user chose LogDT Date of logging record Every time a new MENU record is created, the system adjusts the user's PROFILE record to reflect any trend in the user's tastes. For example, Table 16 below shows how the PROFILE record changes after a meal selection. For each Profile Set (as described in Table 5), a taste adjustment rate (Usrlncr) is defined which determines the degree of change of each value each time a meal taste profile higher or lower than the current user taste profile is selected; in this case the taste adjustment rate is 0.2 for each criterion A, B, and C:

Table 16 - PROFILE adjustment

Description A B C

User Taste Profile before meal selection 3.0 7.0 6.0

Taste profile of meal selection 1 7.0 7.0 6.0

User Taste Profile after meal selection 1 3.2 7.0 5.8

Taste Profile of meal selection 2 7.0 7.0 6.0

User Taste Profile after meal selection 2 3.4 7.0 5.6

Taste Profile of meal selection 3 4.0 7.0 5.0

User Taste Profile after meal selection 3 3.4 7.0 5.4

Each PROFILE record may also be adjusted according to selections made by other members of any of the groups to which the user belongs. As shown in Table 6 above, a Group Increment rate (GRPIncr) is defined for each value in the Profile record, and the appropriate value is increased or decreased by the group rate each time another member of the same group makes a selection with a value grater than or less than the current PROFILE value for the user.

As an additional or alternative feature, a group PROFILE may be defined for each group, and the group profile values are increased or decreased in response to individual selections by members of the group. The user may amend historical MENU records to reflect any differences between what the user selected on the system and what the user actually ate.

PROCUREMENT

Once the user has selected a menu for a specified date, or for each of a range of dates, the system then facilitates the acquisition of the selected meals or the necessary ingredients for those meals, as represented by stage S8 in Figure 3 (or S8.3 for users from affinity site Aff3). If the user wishes to pay for the selected meals or ingredients through the system, and is not registered, account information is obtained from the user (step S7.0). Order information (S8.0) and payment information (S7.1) may be transmitted to the appropriate suppliers.

The user selects how each meal is to be procured. The procurement categories include home cook, pre-made (buy from shop but heat at home), take-out (fully prepared by restaurant or other outlet, and collected or delivered) or restaurant.

If one or more home cook or pre-made meals are selected, the system compiles a 'shopping list' of the ingredients required for those meals, and displays these to the user. These ingredients may be displayed as generic ingredients, or as specific products derived from the Prodlngred database.

Where some of the menu choices are meals only available from a specific supplier which allows on-line ordering, the user may choose to be transferred to the site of the appropriate supplier, ^' and information on the required meals and any ingredients available from that supplier is also passed to the host of that site. The user then removes any items which the user already has, or adds any other items required to the order, before submitting the order. The order may then be collected by or delivered to the user. The MEALS records may include links or pointers to files which provide the user with additional information about that meal, such as a recipe, or a video clip demonstrating preparation of the meal. The use of video demonstrations is particularly suitable for interactive television terminals 16. The system presents the user with the option to view the additional information.

The MEALS records preferably include records of specific meals available from restaurant chains, including a field identifying the restaurant chain or chains serving that meal. If one of those meals is selected for a future meal time, the system displays to the user the identity of the restaurant chain or chains serving that meal. As a further option, the system stores a directory of addresses of restaurants serving meals stored as MEALS records, and selects the closest branch of a chain by comparing the postal or zip codes of the branches with the current post code of the user in USERDET. The closest branch is displayed to the user, and, if requested by the user, an order is sent to the closest branch, for example by fax or e-mail, or by adding the order to a order file to which orders from other users are added before sending the order file off to the branch or chain headquarters.

If a specific exercise has been selected, the user is presented with the option to procure goods or services to facilitate that exercise (step S9 or step S9.2 customised for users from affinity site Aff2), for example gym membership or exercise equipment. If this option is selected, the user may be transferred to a site offering such goods or service, together with information indicating the user's selection (step S 9.0). Another advantageous feature of the system is its ability to exchange information with merchant servers (such as the servers 5 and 7) operated by suppliers of food and other products, to assist the user in purchasing food or other products recommended by the system. In one example, the merchant servers provide information on the current pricing of items available from respective supermarket chains, which information may be updated daily, for example. The pricing information includes regional availability information, such as an indication of which products are available only from some stores. The current pricing information is stored on the server 2, so that when a user has compiled a 'shopping list', the system calculates the total price of the items on the shopping list from each of the supermarket chains from which pricing information has been obtained. The system compares the user's home location with any regional availability information in the pricing information, and takes this into account by using the pricing information relevant to the branch of the supermarket chain closest to the user. The system also indicates whether any of the ingredients is unavailable from each supermarket chain or from the some or all branches of each supermarket chain within a specified distance from the user.

The system also allows transaction-specific pricing for the list of goods according to a number of factors, as will be described below. The pricing information stored by the server comprises a pricing record for each merchant, and optionally for each outlet, of the different ordering options available and their effect on the total price. The pricing record defines delivery options, such as home delivery or collection by customer. Home delivery is more expensive to the merchant and removes the possibility of impulse buying, and the home delivery option may therefore carry a fixed charge or a percentage uplift on the total price, which is recorded in the pricing record. The pricing records also defines picking options, such as store picking (order assembled by staff) or customer picking (order assembled by customer). The former is more expensive to the store in terms of labour costs

.and the removal of impulse buying, and therefore has an additional charge recorded against it. The pricing record also includes a repeat order field, which defines options for repeating the order at different intervals, such as weekly or monthly, and records discounts which are offered to the user for making repeat orders.

The pricing record also includes a time option field, which defines different times at which the customer may visit the store, and associated price adjustments. The time option field may define adjustments associated with each of a time of day, a day of the week or a week of the year. This field allows the merchant to offer incentives to users to visit the store at quiet times.

The pricing record also defines product-related pricing adjustments for selecting products in a specific pack size or for selecting equivalent products.

For example, the pricing record may define pack options, such as larger packs which may have a cheaper price per item, volume or weight, or product options, which record whether a cheaper equivalent brand is available.

The pricing record also defines discounts available for spending over different thresholds, with pricing adjustments recording the percentage discounts available at each threshold. User Groups are also identified to which additional discounts are available, such as cluster groups targeted by the specific merchant. The pricing record may also define discounts available for exceeding specified numbers of orders from that merchant. Finally, the pricing record defines parameters of a random discount which is offered by the system on a per-user basis within limits defined by the merchant or the store.

The different options defined in the pricing record for a selected merchant or store are presented to the user, and the system recalculates and indicates the total price to the user as the options are selected. Once all necessary options have been selected, the user then confirms the order through the system, which causes a list to be printed out or otherwise recorded at the user's terminal, and/or recorded on the supplier database against a customer ID or Loyalty Number or as a generated Deal Number or in any other form verifiable against a customer claim, so as to record the items and options selected, together with the pricing offered by the merchant.

As an alternative, once the necessary options have been selected, the user may make an offer instead of accepting the price calculated by the system. In that case, the system forw-ards the list of items and options selected by the user to the merchant server which processes orders from an outlet selected by the user. The merchant server sorts all received offers according to benefit to the merchant, such as by profit, and periodically selects the most beneficial for acceptance. For the selected offers, a list of details of the acceptance is sent to the respective user. Otherwise, an e-mail notification is sent to an unsuccessful user, including a URL which takes the recipient back to the ordering stage, with the list of items filled in but some or all of the ordering options not completed. The unsuccessful users may then change the ordering options and/or the offer price and resubmit an offer. When .an offer is made to the user by a merchant, or an offer by the user is accepted, a list of details is presented to the user in a form which can be recorded on a physical medium at the user's terminal and/or recorded on the supplier database against a customer ID or Loyalty Number or as a generated Deal Number or in any other form verifiable against a customer claim, and carried with the user to the branch of the supermarket, if the user has selected customer collection. The physical medium and/or supplier database provides a record on the on-line order so that the appropriate price can be claimed by the user.

Preferably, the system sends a series of bar-code images to the user, who then prints the bar-codes and takes the print-out to the selected supermarket. The bar codes identify the customer, who must be pre-registered with the merchant, the order, including a time-stamp, and the products ordered. The information is scanned at the branch and checked against records on the supermarket chain's computer system to verify that the offer has been made, that the customer details are correct and that the list of items has been or is being bought. Each order has a specified duration of validity, and the time-stamp is checked against the current time to ensure that the order is still valid. Additionally, where the order included a time-dependent option, the indicated collection time is checked against the actual time of fulfilment of the order to ensure that the user has collected the items at the time or date selected - if not, a price penalty may be added. If the bar-coded details are verified, the price charged to the customer is then based on that specified in the order.

The use of a bar code does not require the user to acquire any additional hardware or software and can easily be scanned at outlets which already use bar-code scanners for identifying products. However, as an alternative where the user has a smart card writer/reader connected to the user's terminal, the special offer information may be stored on the user's smart card, which is then read at the branch. The scanned information may include a code which indicates that the offer was negotiated through the diet management system, which enables commission payments to be made from the suppliers to the operator of the diet management system when the purchase from the supplier is complete.

As another alternative, all of the details of an on-line order are stored on the supplier database and the customer need only provide some means of identification, such as a loyalty card bearing the customer's signature, in order to be linked to the appropriate order record on the supplier database.

Many of the described features may be implemented only if selected by the user, or selectively made available by the system. For example, the system may allow a 'guest login' in which a user does not provide a full set of information and is allowed to access only certain functions of the system. The system may discard guest login records once the guest user has left the site. Account details may be required from users before they can become registered users of the system, and a charge made per visit to the site, or for specific types of information. Alternatively or additionally, a commission system may operate in which businesses to which users are referred by the system, such as restaurants or beauty product vendors, pay the operator of the system a commission on purchases made by the user. Many of the features described above can be provided independently of the other features. For example, the procurement options could be provided as part of .an on-line ordering service independently of any dietary recommendations.

It will be apparent to the skilled reader that the above system may be modified in many ways without departing from the scope of the present invention, as defined by the claims.

Claims

1. A method of selectively providing dietary data to any of a plurality of users, including: electronically storing a database of a plurality of food records each including food identity data identifying a specific food and taste factor data identifying a taste factor for that food; electronically storing one or more taste preference records relating to each of said multiple users, each taste preference record indicating a taste preference relating to a specific user; for at least one of said users, selecting a set of one or more food records on the basis of a comparison between the or each taste preference record for the respective user with the taste factor data of some or all of said food records, and transmitting, to the respective user, food recommendation data derived from the food identity data of the selected set.

2. A method as claimed in claim 1, wherein the set comprises a plurality of said food records, the method further including: receiving from the user a food selection indication signal identifying one or more of said specific foods, and modifying one or more of the taste preference records relating to that user in response to the food selection indication signal.

3. A method as claimed in claim 2, wherein the food selection indication signal indicates a subset of the selected set of food records.

4. A method of selectively providing dietary data to any of a plurality of users, including: electronically storing a database of a plurality of food records each identifying a food, and local availability information for that food, indicating where that food is available; electronically storing a location record relating to each of said multiple users, each location record indicating the location of a specific user; for at least one of said users, selecting a subset of said set of food records on the basis of a comparison between the location record for the user and the local availability information of some or all of said foods, and transmitting to the respective user food recommendation data derived from the food identity data of the selected set of food records.

5. A method as claimed in claim 4, further including storing a list of ingredients and local availability information for those ingredients, wherein the food records indicate the ingredients of the corresponding foods and the local availability information for said foods is derived from the indicated availability information of the ingredients of the foods.

6. A method as claimed in claim 4 or claim 5, wherein the local availability information further indicates time of availability and the selecting step is performed further on the basis of a comparison between variable time data and the local availability information, according to whether the foods are available at the location of the user at the time indicated by the variable time data.

7. A method of selectively providing dietary data to any of a plurality of users, including: electronically storing a database of a plurality of food records each including food identity data identifying a specific food and time-dependent data indicating a preferred time for that food; and for at least one of said users, selecting a subset of said set of food records on the basis of the time-dependent data of some or all of said food records, and transmitting to the respective user food recommendation data derived from the food identity data of the selected set of food records.

8. A method as claimed in claim 7, wherein said time-dependent data relates to a preferred time of day for that food, and the subset is selected on the basis of a specified time of day.

9. A method as claimed in claim 7 or claim 8, wherein the time- dependent data relates to a preferred day for that food, and the subset is selected on the basis of a specified day.

10. A method of selectively providing dietary data to any of a plurality of users, including: electronically storing a database of a plurality of food records each identifying a specific food and a calorific value of that food; electronically storing physical characteristics records relating to each of said multiple users; for at least one of said users, calculating a calorific requirement of the respective user from the one or more physical characteristics records relating to the respective user, selecting a set of said food records according to said calculated calorific requirement, and transmitting, to the respective user, food recommendation data derived from the selected set of food records.

11. A method as claimed in claim 10, wherein the physical characteristics records include actual and target physical characteristics records, the calorific requirement for the respective user being calculated according to a difference between the values of the actual and target physical characteristics records.

12. A method as claimed in claim 11, wherein the physical characteristics records further indicate a target interval for achievement of the target physical characteristics indicated by the target physical characteristics records, the calorific requirement being calculated additionally according to said target interval.

13. A method as claimed in any one of claims 10 to 12, further comprising storing exercise records representing exercise performed or to be performed by the respective users, wherein the calorific requirement is calculated additionally according to said target interval.

14. A method of selectively providing dietary data to any of a plurality of users, including: storing electronic records representing groups of said users, at least some of said groups comprising more than one of said users; electronically storing a database of a plurality of food records each identifying a specific food; responsive to selection by one or more of said users from one of said groups of one or more of said food records, adding one or more order records corresponding to that selection to a group order record corresponding to that group, and transmitting said group order record.

15. A method as claimed in claim 14, wherein the group order record is transmitted to one or more of the users from the respective group.

16. A method as claimed in claim 14 or claim 15, wherein the group order record is transmitted to a party other than the users of the respective group.

17. A method of selectively providing dietary data to any of a plurality of users, including: storing electronic records representing groups of said users, at least some of said groups comprising more than one of said users; electronically storing a database of diet-related information; in response to an access request from any one of said users, selecting information from said database and transmitting said information to the respective user; recording the time of said access request; and in response to the current time exceeding by a threshold time the most recent said access request from one of said users in one of said groups, transmitting a message to one or more other said users in said one group a message identifying said one user.

18. A method of providing dietary information to a user, including: receiving, from the user, constant physical data representing substantially constant physical characteristics of a human body; a) receiving, from the user, variable physical data representing variable physical characteristics of said human body; and b) generating graphical data arranged to represent graphically said human body having the physical characteristics represented by the constant and variable physical data; and c) transmitting said graphical data to the user to enable said human body to be graphically represented to the user; wherein the above steps a) to c) are repeated at intervals, such that at least some of the variable physical data varies between repetitions.

19. A method of providing dietary information to a user, including: receiving, from the user, constant physical data representing substantially constant physical characteristics of a human body, variable physical data representing variable physical characteristics of said human body and target physical data representing target physical characteristics of said human body; generating a first set of graphical data arranged to represent graphically a human body having the physical characteristics represented by the constant and variable physical data; generating a second set of graphical data arranged to represent graphically a human body having the physical characteristics represented by the constant and target physical data; and transmitting said first and second sets of graphical data to the user to enable said human bodies to be graphically represented to the user.

20. A method of managing dietary information for a user, including: receiving from the user target physical data representing one or more target values of physical characteristics of said user; receiving from the user, at intervals, variable physical data representing one or more variable measured values corresponding to said physical characteristics of said user, wherein said variable measured values are initially not equal to said target values, and, if subsequently said one or more variable measured values are equal to said target values, crediting an account held by said user.

21. A method of providing product, service or activity recommendations to any of a plurality of users, including: storing electronic group records representing groups of said users, at least some of said groups comprising more than one of said users; storing electronic option records representing different products, services and/or activities; storing electronic group preference records representing the respective preferences of said groups of said users in respect of said different products, services and/or activities; selecting one or more of said option records for a designated one of said users on the basis of one or more of said group preference records corresponding to one or more groups including said designated user, and transmitting data derived from the selected option records to the designated user.

22. A method of providing product, service or activity recommendations to any of a plurality of users, including: storing electronic group records representing groups of said users, at least some of said groups comprising more than one of said users; storing electronic option records representing different products, services .and/or activities; storing electronic individual preference records representing the respective preferences of individual said users in respect of said different products, services .and/or activities; selecting one or more of said option records for transmission to a designated one of said users; transmitting data derived from the selected one or more option records to the designated user; receiving an indication from the designated user of one or more of the selected one or more option records; and modifying one or more individual preference records relating to others of said users in the same group or groups as the designated user, according to the indication from the designated user.

23. A method as claimed in claim 22, wherein the option records are selected on the basis of one or more of said individual preference records corresponding to the designated user.

24. A method of electronically ordering products and/or services, including: transmitting a selection indication indicating selected one or more products and/or services; receiving offer information relating to the selected one or more products or services; recording the offer information on a physical medium in an electronically readable form; presenting the physical medium at a supply location of the selected one or more products and/or services; and, in response to electronic scanning and verification of the offer information on the physical medium, receiving the selected one or more products and/or services according to conditions indicated by the offer information.

25. A method as claimed in claim 24, wherein the selection indication is transmitted to a merchant together with a price indication indicating a price offered for the indicated goods and/or services, wherein said offer information indicates acceptance of said price.

26. A method of electronically processing orders for products and/or services, including: electronically scanning, at a supply location, offer information from a physical medium, the offer information indicating a previous selection of one or more products and/or services and conditions applicable to the supply thereof; electronically verifying the offer information against stored information relating to the previous selection, and, in response to a positive verification, supplying the selected one or more products and/or services according to conditions indicated by the offer information.

27. A method as claimed in any one of claims 24 to 26, wherein the offer information is scanned from a bar code.

28. A method as claimed in any one of claims 24 to 26, wherein the offer information is scanned from a card.

29. A method of electronically ordering products and/or services, including: transmitting a selection indication indicating selected one or more products and/or services, and one or more procurement options; receiving offer information relating to the selected one or more products .and/or services .and options; presenting the offer information at a supply location of the selected one or more products and/or services; and, in response to electronic verification of the offer information, including verification of the procurement options being satisfied, receiving the selected one or more products and/or services according to conditions indicated by the offer information.

30. A method of electronically processing orders for products and/or services, including: receiving, at a supply location, offer information indicating a previous selection of one or more products and/or services and procurement conditions applicable to the supply thereof; electronically verifying the procurement conditions against the actual conditions of receipt of the offer information, and, in response to a positive verification, supplying the selected one or more products and/or services according to conditions indicated by the offer information.

31. A method as claimed in claim 30, wherein the procurement options include a selected time and/or day of collection, and the electronic verification includes verification that the current time and/or day matches the procurement conditions.

32. A method as claimed in any one of claims 24, 25 and 29, wherein the receiving and transmitting steps are performed via an intermediate node, the offer information including information identifying the intermediate node.

33. A method as claimed in any one of claims 1 to 23, wherein the method is performed at a node of a network to which the or each said user is directly or indirectly connected or connectable.

34. A method as claimed in any one of claims 24, 25 and 29, wherein the method is performed at a terminal connected to a network.

35. A method as claimed in claim 33 or claim 34, wherein the network is a packet-switched public network.

36. A method as claimed in claim 33 or claim 34, wherein the network is a circuit-switched public network.

37. A method substantially as herein described with reference to Figures 3 to 5 of the accompanying drawings.

38. Apparatus arranged to perform the method as claimed in any preceding claim.

39. A computer program arranged to perform the method as claimed in any one of claims 1 to 37 when executed by a suitably arranged computer.