US20040241629A1

US20040241629A1 - Computerized training system

Info

Publication number: US20040241629A1
Application number: US10/807,972
Authority: US
Inventors: Tomasz Ondrusz; Simon Bayntun; Roger Margereson
Original assignee: H D Sports Ltd
Current assignee: H D Sports Ltd; HD Sports Ltd
Priority date: 2003-03-24
Filing date: 2004-03-24
Publication date: 2004-12-02
Also published as: GB0306734D0

Abstract

There is disclosed a training system for training people, for example to increase their ice skating skills or some other physical attribute. In a preferred embodiment, the training system comprises a computer and a database. The training system allows a user to enter information regarding his fitness. The system can then specify an exercise program for the user. The user can also enter information regarding his diet, in which case the system determines the suitability of the diet to the user. In order to psychologically motivate the user, the system provides a goal orientated method to facilitate the user to understand ways in which he can improve his performance. The system can also receive information regarding injuries and can take these into account when generating a training program and when assessing the user's diet. The system can also be used for the purpose of weight loss or gain.

Description

REFERENCE TO PENDING APPLICATIONS

This application claims priority of UK Application No. 0306734.5, filed 24 Mar. 2003.

REFERENCE TO MICROFICHE APPENDIX

This application is not referenced in any microfiche appendix.

FIELD OF THE INVENTION

The present invention relates to a computerized system for devising a training scheme for a sports person.

BACKGROUND OF THE INVENTION

It is a problem for an amateur sports person to select a training scheme appropriate to his/her sport. It is a fact that success in sports is highly related to individual body measurements. For instance, it can be seen that the anthropometrical differences between sprinters are far less than between sprinters and the general public. It is suggested that there is a specific idealized anthropometric and physiological profile for the sport of sprinting. There will be different idealized physiological profiles for different sports. General training schemes are widely available, but it is not easy for the amateur sports person to arrive at a training scheme suitable both for his/her sport and also his/her current physiological profile. The present invention aims to address this.

BRIEF SUMMARY OF THE INVENTION

In a first aspect, the present invention provides a training system comprising: a database comprising information regarding the relevance of different physical activities to training categories; and a server for transferring information between a user and the database.

In a second aspect, the present invention provides a training system comprising: a database comprising information regarding the nutritional content of different foodstuffs; and a server for transferring information between a user and the database.

In a third aspect, the present invention provides a training system comprising: a database for storing information regarding a goal of a user; and a server for transferring information between a user and the database.

In a fourth aspect, the present invention provides a training system comprising: a database for storing information regarding an injury sustained by a user; and a server for transferring information between a user and the database.

In a fifth aspect, the present invention provides a computerized system for devising a training scheme for a sports person comprising: first computer means for processing data, which has a database which stores for each of a plurality of sports a record of an idealized physiological profile; wherein: each sports person using the system inputs a selection of a sport and, in response to enquiries generated by the first computer means, information concerning his/her physiological profile; and the first computer means compares the physiological profile input by each sports person with the idealized physiological profile for the relevant sport and from this comparison formulates a training regime which is relayed to the sports person.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a schematic illustration of a computerized training system; [0010]
FIG. 2 shows an introductory web page as seen by a user of the system; [0011]
FIG. 3 shows a fitness status assessment web page, for updating information, as seen by the user; [0012]
FIG. 4 shows a fitness status assessment web page, for displaying an assessment of the user's fitness, as seen by the user; [0013]
FIG. 5 shows a web page for setting goals, as seen by the user; [0014]
FIG. 6 shows a web page for setting outcome goals, as seen by the user; [0015]
FIG. 7 shows a graphical representation of what the user considers to be his strengths and weaknesses, as seen by the user; [0016]
FIG. 8 shows a goal completion web page, as seen by the user; [0017]
FIG. 9 shows a goal history web page, as seen by the user; [0018]
FIG. 10 shows an activity assessment web page, as seen by the user; [0019]
FIG. 11 shows a detailed activity entry web page, as seen by the user, for allowing the user to enter detailed activity information; [0020]
FIG. 12 shows an activity assessment overview web page, as seen by the user, displaying an overview of the user's recent physical activity; [0021]
FIG. 13 shows a detailed activity assessment web page, as seen by the user, displaying a detailed analysis of the user's activities; [0022]
FIG. 14 shows a diet web page, as seen by the user, for entering dietary information; [0023]
FIG. 15 shows detailed diet web page, as seen by the user, for entering detailed dietary information; [0024]
FIG. 16 shows a nutrition assessment web page, as seen by the user, which provides an assessment of the suitability of the user's diet with regard to the number of calories deemed to be required by the user; [0025]
FIG. 17 shows a web page, as seen by the user, that suggests appropriate changes, if deemed necessary, to the user's diet; [0026]
FIG. 18 shows a web page, as seen by the user, that allows the user to indicate, at a coarse level, his intended training activity for the next seven days, and allows the user to cause a proposed training schedule, tailored to his needs, to be generated; [0027]
FIG. 19 shows a web page, as seen by the user, that allows the user to refine the training schedule generated; [0028]
FIG. 20 shows a web page, as seen by the user, that allows the user to enter information regarding injuries that he has sustained; [0029]
FIG. 21 shows a web page, as seen by the user, that allows the user to enter more detailed information regarding injuries that he has sustained; [0030]
FIGS. 22[0031] a to 22 d show the database structure of a database of the training system, with FIG. 22 showing how FIGS. 22a to 22 d should be assembled; and
FIG. 23 shows a schematic illustration of a second embodiment of a computerized training system. [0032]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 is a schematic illustration of an [0033] embodiment 100 of the training system.
The training system allows a user to enter information concerning: (i) “goals” (a goal may be, for example, winning a national sports competition, or losing weight), (ii) details of his current height, weight and fitness, (iii) details of injuries he has sustained, (iv) details of his physical activity during recent days, and (v) details of his food intake over recent days. [0034]
The system processes the information entered by the user and outputs information to the user concerning: i) an assessment of the suitability of his diet, (ii) an assessment of his fitness relative to the fitness of his assumed peers, and (iii) a suggested training program. [0035]
The system comprises a [0036] server 101 which is connected to a personal computer (PC) 102 by a communications link 112. In this embodiment the server 101 implements a relational database 110 and runs software that implements the training system. In this embodiment of the system the database 110 is shown as being a constituent part of the server 101 although in alterative embodiments the database 110 may be separate from the server 101.
The PC [0037] 102 is operated by a user of the system and allows the user to send data to the server 101 and to receive data from the server 101. Data received by the server 101 from the PC 102 can be stored on a hard disk (not shown).
The [0038] server 101 is also connected by a communications link 113 to a payment server 103. A user pays to use the system 100 by entering their credit card details at the PC 102. The credit card details are then encrypted by known means and transferred over the communications link 112 to the server 101 and then transferred from the server 101 over the telecommunications link 113 to the payment server 103.
In this embodiment the [0039] communications links 112, 113 both comprise the internet. When a user contacts the server 101, his PC 102 requests an internet web page from the server 101. The server 101 then generates a web page and transfers the web page over the communication link 112 to the PC 102 for display. The PC 102 uses suitable software such as Internet Explorer or Mozilla to display the web page. In this embodiment the server 102 uses “Flash” software from the company Macromedia, Inc. to embed multimedia objects in the web page. The embedded objects in turn are able to prompt the user to enter information, and are operable to cause the PC 102 to transfer the entered information to the server 101. The user can use different parts of the system 100 by selecting icons on the web pages, for example by using a pointer device such as a mouse and “clicking” the icon. In response to the icon selected, the server 101 then generates the appropriate web page. On some web pages generated by the server 101, the web pages contain “buttons” instead of icons. A button is not a physical button but is a region of the web page that can be selected by the user using a pointing device such as a computer mouse. Unlike icons, buttons do not graphically represent their function.
In this embodiment the database is implemented using the “MySQL” software package available from the company MySQL.com. The majority of the [0040] training system 100 is implemented using the Java programming language available from the company Sun. Thus the Flash software provides a graphical user interface for the Java software, while the MySQL implements the database 110.
Creating an Account [0041]
To create an account (also known as “registering”) with the [0042] server 101, the user asks the server 101 to establish a new account for him. The server 101 prompts the user, via Flash objects embedded in a web page, for relevant information such as: (i) his first name, (ii) his surname, (iii) his age, (iv) his email address, (v) his postal address, (vi) a password which he can use on future occasions to authenticate himself to the server 101, and (vii) his credit card details.
The [0043] server 101 passes the credit card details to the payment server 103. If his credit card details are valid and are successfully processed by the payment server 103 then the payment server 103 informs the server 101 that his account can be activated. Once his account has been activated by the server 101, the user can then authenticate himself to the system 100 using his password and can begin to use the features provided by the system 100.
Introductory Web Page [0044]
FIG. 2 shows a [0045] web page 200 which is initially seen by the user whenever he uses his PC 102 to connect to the server 101. The web page 200 has seven regions 201-207 which act as icons and allow the user to select a particular aspect of the system 100.
In this embodiment, the [0046] system 100 provides a training system for ice skaters and thus the regions 201-207 are customized accordingly. The seven regions are: nutrition 201, competitions 202, fitness 203, ice training 204, goals 205, injury 206 and updates 207.
The [0047] nutrition region 201 allows the user to enter information concerning his diet. The server 101 assesses the user's diet with regard to the user's activity level and injuries and provides an indication of whether the diet is meeting or exceeding the user's requirements. The competitions region 202 reminds the user of forthcoming competitions and allows the user to enter information concerning competitions. The fitness region 203 allows the user to enter information concerning his current fitness levels with regard to various indications of fitness. The ice region 204 allows the user to enter information concerning his skill and training levels on ice. The goal setting region 205 allows the user to enter “goals” that the user wishes to achieve. The injury region 206 allows the user to enter information concerning injuries that the user may inadvertently have sustained. The updates region 207 prompts the user to enter more recent information should the information concerning, for example, his fitness become out of date.
Height, Weight and Detailed Fitness Information [0048]
Once the user's account is activated, the [0049] server 101 still needs to obtain further information from the user concerning: (i) basic physical attributes such as the user's height and weight and (ii) detailed fitness information for the user.
The [0050] fitness region 203 displays a text caption that informs the user that this information is required by the server 101. The user then selects the fitness region 203. In response, the server 101 prompts the user to enter the (i) basic physical attributes and (ii) detailed fitness information.
Firstly, the [0051] server 101 prompts the user to enter his height and weight in imperial units, i.e. feet and inches for height and stones and pounds for weight.
Secondly, the [0052] server 101 prompts the user to enter the following detailed fitness information: (i) the number of pushups that the user can complete in 60 seconds (1 minute), (ii) number of situps in one minute, (iii) vertical jump height, (iv) long jump distance, (v) sit and reach distance, (vi) time to run a distance of one mile (1,609 meters), and (vii) number of “shuttles”. The user needs to have performed the seven tests before he can enter the information. Of course, the user does not need to have performed the tests before creating an account; the user can create his account, perform the seven tests and then log in to the server 101 at a later time and/or date in order to enter the detailed fitness information.
Pushups and situps measure the core stability of the user. The core stability is a measure of the strength of the user's “core” muscles. The core muscles include the abdominal and lower back muscles (i.e. trunk and torso muscles). Core stability is one measure of the fitness of the user. Vertical jump height and long jump distance measure the short-term “explosive” strength of the user. Sit and reach distance measures the flexibility of the lower back and hamstrings of the user. The one mile run time and the shuttles test both give an indication of the cardiovascular endurance of the user. As those skilled in the art will appreciate, the “shuttles” test measures cardiovascular endurance by requiring the user to complete a 20 m distance every time an audible “bleep” is sounded. Every 3 minutes, the rate of the bleeps increases. The test continues until the user can no longer complete the 20 m distance between consecutive bleeps. [0053]
Updates [0054]
The [0055] server 101 also records the calendar date on which each of nine categories of height, weight and fitness information is provided by the user (i.e. seven for fitness together with height and weight). This allows the server 101 to prompt the user to enter more recent information when there is a risk that the current information might be out of date. The updates region 207 as shown at FIG. 2 indicates that more recent height and weight information is required. However, the following example concerns the detailed fitness information.
FIG. 3 shows an example of a [0056] web page 300 as seen by the user. The web page 300 includes a region 301 that lists the seven categories of detailed fitness information. The height and weight categories are not shown by FIG. 3. As shown, the region 301 indicates that the updated information regarding the user's sit and reach ability is required now (i.e. the region 301 displays “Now”), arid indicates that updated information regarding the vertical jump and the long jump will be required in 7 days' time (thus the region 301 displays “7 days” for these two categories). Of course, the user's new sit and reach ability may actually be the same as his previous sit and reach ability.
For each of the nine categories, the [0057] server 101 stores the date of the most recent information and compares this with the current date. The result of the comparison is used by the server 101 to give the user advance warning of when more recent information will be required. If the result of the comparison exceeds a predetermined threshold, i.e., if a category of information is too old, then the server 101 prompts the user for more recent information. In this embodiment, for each of the 9 different categories, the server 101 has a respective threshold to determine the maximum age of the measurement. For example, for the vertical jump and long jump strength categories, more recent information is requested if the current information stored is more than 7 days out of date. For the one mile run and shuttle test cardiovascular categories, more recent information is requested in the current information is more than 33 and 36 days old, respectively. The cardiovascular ability of most users will improve more slowly than their strength and thus less frequent updates are required for the cardiovascular categories. Note that although the user is prompted to enter more recent information when a category has exceeded its respective threshold, the user does not have to wait until a category is out of date but can enter more recent information at any time.
In this embodiment, not only can each of the nine categories have a respective threshold, but the threshold can be different for different users. For example, height (and weight) information is required more frequently when the user is in his/her teens than when fully grown. Thus the thresholds can be different not only for different users but can also vary according to the age or fitness of the user. [0058]
Adolescents have growth spurts which provide both training opportunities and also present risks. During a growth spurt, the bones grow and the ligaments loosen. In this embodiment, height information is required of males at the following intervals: [0059]

ages 8-11 every 4 weeks,

ages 11-17 every 2 weeks,

ages 17-21 every 4 weeks, and

ages 21+ every 6 months.
Height information is required of females at the following intervals: [0060]

ages 8-10 every 4 weeks,

ages 10-14 every 2 weeks,

ages 14-18 every 4 weeks, and

ages 18+ every 6 months.
Once the height, weight and fitness information has been provided to the [0061] server 101 by the user, the server 101 can use the information to assess the fitness of the user. This is discussed in more detail below.
Fitness Status Assessment [0062]
Once the [0063] server 101 has received the fitness information from the user, the user can select a fitness status assessment. FIG. 4 shows an example of a web page 400 illustrating a fitness status assessment 401. In this embodiment the fitness status assessment is a chart 401 that shows the user's current fitness levels compared to those of his nominal peers. As shown, for each of the seven categories of detailed fitness information, a respective segment of the chart is displayed, the radial spacing from the ??? center indicating the user's fitness level compared to that of his nominal peers. For each category, the user's fitness is rated as either excellent, good, average or poor. For the user whose fitness level is shown at FIG. 4 has excellent fitness levels for mile run, sit and reach, long jump, vertical jump and pushups, and good levels for shuttles and situps. The color of the associated segment is selected on the basis of the fitness rating. The chart 401 provides a user with an easily interpretable fitness assessment.
Note that the user's fitness is compared to his nominal peers, not against other users of the system. When a user creates an account, he is required to enter information indicating the skill level at which he skates. For example, the user may indicate that he skates at a “county championship” skill level. The system compares the user's height, age and skating skill level with information stored in the [0064] database 110 of the server 101.
In this embodiment, the stored information summarizes the fitness levels of skaters at various heights, ages and skill levels, as determined by measuring the fitness of real skaters. The [0065] server 101 interpolates and extrapolates the stored information in order to determine the fitness level expected of the user. Note that in an alternative embodiment, the server 101 may store a mathematical formula, instead of stored information, in order to allow the user's height, age and skill level to be related to the fitness level expected of him.
Once the [0066] server 101 has compared the user's actual fitness level with the fitness level expected of him, the fitness assessment results are displayed as the pie chart 401.
Goals—Setting [0067]
By selecting the [0068] goal setting region 205 of FIG. 2, the user can indicate to the server 101 that he wishes to enter, or review, information concerning his goals. In response, the server 102 causes a web page to be displayed on the user's PC.
FIG. 5 shows an [0069] example web page 500 as seen the user. The web page 500 includes sections relating to “outcome” goals 501, “long term” goals 502 and “dream” goals 503. Outcome goals 501 are relatively short term goals. Dream goals 503 represent the ultimate ambition of the user, for example to win a regional or a national competition.
The inventors of the present application have realized that for a user to successfully compete at his desired level, it is not sufficient for the user to train only with regard to his physical fitness. Rather, to ensure that the user competes successfully, it is also necessary to ensure that the user develops an appropriate mental attitude so that under the pressure of competition conditions he performs at the level he has achieved during training. [0070]
The [0071] dream goal section 501 allows the user to specify what he regards as his dream goals. Depending on the ability of the ice skater, his dream goal might be winning a regional championship or winning an Olympic competition. In this embodiment the dream goal section does not provide a selection of pre-prepared options but requires the user to consider his ambitions and to express his ambitions in his own words.
Once the user has formulated his dream goal(s), the user can use the long [0072] term goal section 502 to enter long term goals that will provide a path to achieve his dream goal. For example, the user might consider that an important stepping-stone to achieving his dream goal is that of winning a regional ice skating competition. Accordingly, the user enters this into the long term goal section 502.
Finally, the user can use the [0073] outcome goal section 501 to enter goals that have definite outcomes. The outcome goals are intended to be relatively short term and thus the server 101 allows the user to enter goals for the next 3 months, the next 6 months and the next 12 months. Although a user can enter his goals in any order into the dream goal section 503, long term goal section 502 and outcome goal section 501, it is intended that the user enter his goals in the above order so that he derives maximum benefit from this aspect of the system.
FIG. 6 shows a [0074] web page 600 that enables the user to set his outcome goals. The web page 600 is displayed when the user selects a “Details” button 510 on the web page 500. As shown, the web page 600 allows the user to select outcome goals from a drop-down box 601. The user may enter up to three outcome goals for a 3 month period. Examples of outcome goals are (i) finishing in the top ten rankings for an event, or (ii) beating a certain competitor at an event.
The user can also the [0075] web page 600 to enter the dates of competitions. The dates entered of such competitions are stored by the server 101 in the database 110. When a competition approaches (for example is two weeks away) the server 101 “tapers” an exercise regime for the user, thus ensuring that the user is in peak condition for the competition. The tapering is discussed in more detail further below.
The process of entering his outcome goals into the goal sections [0076] 501-503 facilitates the user to become aware of how he can use outcome goals to achieve his dream goal. Once the user has entered goals into the goal sections 501-503, he will be ready to use a “factors” section 504 and a physical strengths & weaknesses section 505 of the web page 500. The factors section 504 and the physical strengths & weaknesses section 505 together form “process goals”. Process goals are well defined; achievement of the process goals is intended to provide the means by which the user will achieve his outcome, long term and dream goals.
The [0077] factors section 504 allows the user to enter what he regards as key technical and mental factors. In this embodiment the system is suitable for an ice skater. Therefore, the factors section 504 offers a range of predetermined options that are suitable for the technical factors that affect an ice skater. As shown at the factors section 504, the user has selected the following technical factors: (i) clean edges, (ii) high jumps and (iii) centered spins. The user has also selected the following mental factors: (i) maintaining concentration throughout the routine, (ii) coping with mistakes and (iii) coping with the pressure. Note that only the first of these mental factors is shown at the factors section 504.
The physical strengths & [0078] weaknesses section 505 allows the user to enter what he regards as key physical strengths and weaknesses that he needs to develop. The physical strengths and weaknesses section 505 allows the user to select from predetermined options. As shown at the physical strengths and weaknesses section 505, the user has selected cardiovascular and flexibility as his weaknesses. Note that the view of the physical strengths and weaknesses section 505 shown at FIG. 5 does not show any strengths.
Once the user has entered his strengths and weaknesses into the [0079] factors section 504 and the physical strengths & weaknesses section 505, he can select an button 506 to display graphical representation of his strengths and weaknesses.
Goals—Graph [0080]
FIG. 7 shows an [0081] example web page 700 as seen by the user. In this embodiment, the web page 700 includes a chart 701 that allows the user to readily interpret his strengths and weaknesses. The chart 701 has segments corresponding to the following technical factors: (i) double flips, (ii) triple toe, (iii) clean edges, (iv) high jumps, (v) centered spins; the following mental factors: (vi) maintaining:concentration throughout the routine, (vii) coping with mistakes, (viii) coping with the pressure; and the following physical strengths and weaknesses: (ix) core stability, (x) jumping power, (xi) cardiovascular and (xii) flexibility. Note that although the pie chart 701 is shown as having twelve segments, the actual number of segments depends on the number of technical and mental factors and physical strengths and weaknesses entered into the web page 500.
Goals—Completion and History [0082]
FIG. 8 shows a goal [0083] completion web page 800, as seen by the user. The web page 800 is displayed at the user's PC 102 when the user selects an appropriate icon (not shown) from the web page 500. The web page 800 allows the user to review his goals and to indicate to the server 101 when goals have been completed. Thus the system 100 provides a goal orientated method to facilitate the user to understand ways in which he can improve his performance.
The [0084] web page 800 displays goals that have not been completed at a region 801 and displays goals that have been completed at a region 802. A description of a goal that has been selected by the user is displayed at a region 803. Note that FIG. 8 does not actually show any goals.
A user can readily use the [0085] web page 800 to inform the server 101 of the goals that have been completed. For example, if a goal has been completed then the user selects the goal and then selects a button 805 which causes the server 101 to move the goal from an “incomplete” section of the database 110 to a “completed” section of the database 110. The web page 800 is then updated. It will be recalled that the server 101 implements a database 110. Goals that have not been completed are stored in a section of the database 110 allocated for incomplete goals. When the user has completed the goal, he uses the button 805 to cause the server 101 to update the database 110 and move the goal to the section of the database 110 allocated for completed goals.
FIG. 9 shows a goal [0086] history web page 900. The web page 900 helps the user to keep track of his goals. A session date field 901 allows the user to enter a session date, in this case Dec. 1, 2003. In response, the server 101 interrogates the database 110 for goals relevant to the session date and causes an updated web page 900 to be displayed at the user's PC 102. The updated web page 900 displays the relevant goals in a display field 902. Note that in FIG. 9, only a completed long term goal is shown in the display field 902. A goal category field 903 allows the user to select a particular category of goals to be displayed in the display field 902. As shown by FIG. 9, the user has selected long term goals in the field 903 and thus only long term goals having relevant dates are displayed in the display field 902.
Activity Assessment [0087]
The [0088] fitness region 203 of the web page 200 allows the user to cause the server 101 to display an activity assessment web page 1000 on the user's PC 102. FIG. 10 shows the activity assessment web page 1000 as seen by the user. The activity assessment web page 1000 allows the user to inform the server 101 of the physical activities that the user has performed recently. In response, the server 101 calculates the energy expenditure of the user and also calculates the suitability of the user's physical activities to the user's training program.
The activity [0089] assessment web page 1000 shows a field 1001 which, in this embodiment, displays the most recent seven days. (The server 101 in this embodiment includes a real time clock so that the server 101 always knows the current calendar date.) The field 1001 has seven buttons 1002 which the user can select to view and/or edit the physical activities for the respective day. The field 1001 also has seven status indicators 1003 which inform the user when physical activity information as been entered for the respective day. In this embodiment, the server 101 requires information for at least five of the seven days. This ensures that the information is representative of the previous seven days. Note that if the user enters information for all seven days then the user's energy expenditure the suitability of the user's physical activities can be determined directly. On the other hand, if the user enters information for, for example, just five of the seven days then the information for the five days is multiplied by {fraction (7/5)} (1.4) in order to scale the information to a seven day period.
When the user selects one of the [0090] buttons 1002 the server 102 causes a detailed activity assessment web page 1100 to be displayed on the user's PC 102. FIG. 11 shows an example of a detailed activity entry web page 1100, in this case for the date Jan. 6, 2004. The web page 1100 includes two pull down menus 1101 that the user can use to select an activity type. In FIG. 11, the activity type selected is “walking the dog”. The user then uses a “duration” pull down menu 1102 to indicate to the server 101 the duration of the activity. In FIG. 11, the duration selected for the activity is one hour. Finally, the user uses a button 1103 to add the activity to a list 1104. The list 1104 lists all the activities entered for the particular day.
Energy Expenditure [0091]
On the basis of the activity information entered, the [0092] server 101 calculates the energy expenditure for the day (i.e., for the 24 hour period of Jan. 6, 2004). The server 101 calculates the total energy expenditure for the day by adding up the energy expenditure caused by all the separate activities of the day. For the day shown at FIG. 11, the user has entered the activities of “walking the dog” and “baseball.” For each of these activities, the server 101 consults the database 110 and determines the energy expenditure on the basis of: (i) the type of activity (e.g., baseball), (ii) the duration of the activity (e.g., 1 hour), and (iii) the height, weight, age and gender of the user.
For the remaining time of the day, in this [0093] case 22 hours, the server 101 uses “Basal Metabolic Rate” to determine the energy expenditure. As those skilled in the art will appreciate, there are various different formulae for calculating the basal metabolic rate of an individual but the formulae generally relate the individual's height, weight, age and gender to the energy expenditure. For example, according to one formula, a 30 year old male who is 1.72 m tall and weighs 70 kg will have a basal metabolic rate of 1680 kilo-calories for a 24 hour period (where each kilo-calorie is equivalent to 4184 joules of energy). Thus he will require 70 kilo-calories an hour if he is resting or asleep. For the example shown at FIG. 11, the user is deemed to be asleep or resting for 22 hours of the day and active, to different degrees, for the remaining two hours. When walking the dog, the user will expend energy at a greater rate, 224 kCal per hour as shown at the list 1105. Similarly, the user will expend 449 kCal per hour when playing baseball.
When the user has used the [0094] web page 1100 to enter his activities for at least 5 of the most recent 7 days, the server 101 calculates his average daily energy expenditure and displays this at a field 1201 as part of an activity assessment overview web page 1200, shown at FIG. 12. The web page 1200 also includes a field 1204 which displays the average daily time that the user has spent sleeping, training for ice skating and fitness (i.e., non-ice skating training).
The user may use a [0095] button 1203 to view a detailed assessment of the relevance of the past seven days' activities to his training requirements, as shown at FIG. 13.
Detailed Activity Assessment [0096]
FIG. 13 shows a detailed activity [0097] assessment web page 1300, as seen by the user. The web page 1300 displays a field 1301 that provides the user with a detailed analysis of the user's physical exercise during the preceding seven days.
As shown, in this embodiment the [0098] field 1301 displays detailed information for each of six training areas: (i) flexibility, (ii) cardiovascular, (iii) local muscular endurance, (iv) core stability, (v) lower body strength and upper body strength (vi). Local muscular endurance is the ability of a single muscle to perform sustained work.
Each of the training areas relates to a type of exercise that is important to ice skaters. The [0099] field 1301 shown at FIG. 13 displays “actual” and “target” percentages for each of the six training areas although note that, for the web page 1300, all of the actual percentages happen to be 0%. The actual and target percentages are normalized to the training needs of the user, taking into account the skill level of the user.
For example, in this embodiment the [0100] database 110 stores predetermined information indicating that a 30 year old male user, who skates at an advanced level, should be performing 6 hours per week of “normalized” lower body strength exercises. The user can achieve the 6 hours per week either by performing physical exercises such as squat thrusts that are almost 100% appropriate to lower body strength, or could perform 12 hours per week of exercises such as baseball that is 50% appropriate to lower body strength. Conversely, while squat thrusts are an excellent way of improving lower body strength, they do not appreciably develop other training areas such as flexibility. On the other hand, baseball provides better all-round training than squat thrusts.
Based on the activity data entered by the user to the [0101] web page 1100 for each of the days, the server 101 uses the database 110 to assess how relevant the activities are to the training needs of, in this embodiment, an ice skater. The database 110 stores predetermined data values which have been empirically found to give good results when training ice skaters. Here, it has been determined that a good training program for an ice skater should devote, for example, 10% of the training effort to flexibility, 15% to cardiovascular, 10% to local muscle endurance, 25% to core stability, 35% to lower body strength and 5% to upper body strength, as shown by the field 1301.
Note that in this embodiment the percentages displayed at the [0102] field 1301 are normalized to the requirements of the user. Thus for a user who skates at an intermediate level, 3 hours of squat thrusts every week would achieve 100% of his target lower body strength physical activity. Conversely, a user who skates at an Olympic level would need to perform 6 hours of squat thrusts every week to achieve 100% of his target lower body strength physical activity. Thus different physical activities are weighted for their relevance to the six training areas displayed at the field 1301. The weights are stored in the database 110.
As will be described later in more detail, the predetermined information stored in the [0103] database 110 concerning the physical activity requirements for the six training areas can be modified by the server 101 before being used as the target percentages in the field 1301. As those skilled in the art will appreciate, sportsmen/sportswomen typically “taper off” their training regimes before a major competition. This is to reduce the risk of sustaining injuries through training before a competition and to allow the body to recover from the training.
Nutrition—Data Entry [0104]
FIG. 14 shows a [0105] diet web page 1400 which includes a field 1401. The diet web page 1400 is similar to the web page 1000 and allows the user to enter information about the foods he has eaten during the previous week. The system 101 requires the user to enter information for at least five of the preceding seven days in order to perform a meaningful assessment of the user's diet.
By selecting one of seven [0106] buttons 1402, the user can select one of the preceding days.
FIG. 15 shows a [0107] web page 1500 that allows the user to enter dietary information for a particular day. As shown, the web page 1500 is for the date of Jan. 6, 2004. The web page 1500 includes pull down menu 1501 to allow the user to select a dietary group from: (i) bread and cereals, (ii) fast foods, (iii) dairy, (iv) drinks, (v) fats, oils and sugars, (vi) fruit and vegetables and (vii) protein.
A pull down [0108] menu 1502 allows the user to select a particular foodstuff from the dietary group. Examples of foodstuffs are tuna fish, Caesar salad and bread pudding. A pull down menu 1503 allows the user to select a portion size.
By using the pull down menus [0109] 1501-1503, the user can enter his dietary intake for the preceding week. The database 110 stores information listing the nutritional values of the various foodstuffs. For example, 100 g (grams) of tuna fish may be listed as providing 23 g of protein, 0.2 g of carbohydrate, 13 g of unsaturated fat and 4 g of saturated fat.
Once the user has entered his dietary intake for the preceding week, he can use a [0110] button 1403 of the web page 1400 to view an assessment of his diet regarding his needs. The server 101 uses information stored in the database 110, in conjunction with the information provided by the user regarding both the types and quantity of food and drinks he has consumed, to determine how much protein, carbohydrate and fat he has obtained from his diet.
When a user has entered data for a week, this data is stored in the [0111] database 110 for later retrieval. Usually, the user will enter information every week concerning his food intake for the previous week. The data stored in the database 110 avoids the user having to enter the data from scratch each week. Instead, the user can cause the server 101 to retrieve the data from the database 110 and display the data at a web page (not shown) at the user's PC 102. The user then indicates the changes compared to his diet for the previous week. This feature provides the advantage that the user can more readily enter his food intake. For example, if the user eats the same foodstuffs each week then he will not need to enter any information but will merely need to inform the server 101 that his diet was the same as the previous week.
Once the [0112] server 101 has determined the user's food intake, this can be displayed at a web page 1600.
Nutrition—Assessment [0113]
FIG. 16 shows a nutrition [0114] assessment web page 1600 which displays at a field 1601 the daily energy requirement of the user as calculated on the basis of the information provided by the user at web pages 1000 and 1100. The field 1601 displays the same numerical value for the user's daily energy requirement as was calculated by the server 101 for display at the field 1201 of web page 1200.
A [0115] field 1602 of the calorific assessment web page 1600 displays an analysis of the calorific value of the foodstuffs and drinks that the user has consumed during the seven previous days. The analysis is performed by the server 101 on the basis of the dietary information entered by the user at web pages 1400 and 1500. In this embodiment, the server 101 analyses the calories provided by the user's diet in four categories: (i) protein, (ii) saturated fat, (iii) unsaturated fat and (iv) saturated fat. For example, if the various parts of the user's diet together contain 100 g of protein each day then he will receive 350 kCal each day from protein alone. As shown at FIG. 16, here the field 1602 indicates that the user is obtaining an average of 448 kCal a day from protein, 515 kCal a day from carbohydrates, 231 kCal a day from unsaturated fat and 57 kCal a day from saturated fat.
The [0116] field 1602 also provides an indication to the user of the suitability of his dietary food and drink intake. As shown at FIG. 16, here the field 1602 indicates that the user's is obtaining the correct amount of calories from his protein intake, but is receiving too many calories from his unsaturated fat intake. The suitability of the user's calorific intake in the four categories listed above is determined by the server 101. The server 101 analyses the user's food intake for the previous seven days and compares this with a profile that is stored in the database 110. Depending on the results of the comparison, the server 101 causes the field 1602 at the user's PC to display whether the user is obtaining the correct number of calories from the four categories of his diet.
The [0117] server 101 calculates the user's energy requirement by comparing the user's calorific intake with the user's calorific expenditure displayed at the field 1201. In this embodiment, if the user's energy intake is within 10% of his energy expenditure then “OK” is displayed at the field 1602, to indicate to the user that his energy intake is satisfactory. If his energy intake is less than 90% or more than 110% of his energy expenditure then the field 1602 displays “too low” or “too high”, respectively. If his energy intake is less than 70% of more than 130% of his energy expenditure then the field 1602 displays “far too low” or “far too high”, respectively.
In this embodiment, the [0118] server 101 calculates the number of calories that the user should be receiving from saturated fats and from unsaturated fats, as a percentage of his energy expenditure. There is no lower limit for saturated fats. For saturated fats, “too high” is set at 10%, and “far too high” is set at 15% of the user's energy intake. For saturated fats, the lower limits are 15% and 17% and the upper limits 22% and 25%.
In this embodiment the [0119] server 101 calculates the user's protein requirements and carbohydrate requirements on the basis of the user's weight in kilograms (kg). If the user consumes less than 1.20 g of protein per kg of his bodyweight then the field 1602 indicates “too little”. Thus a 70 kg user should consume a total of between 84 g and 105 g of protein a day, for example by eating 411 g of tuna fish (which contains 24 g of protein per 100 g) each day. If he consumes less than 0.70 g per kg per day, the field 1602 will display “far too little”. The upper limits for protein are 1.50 g and 2.00 g for “too much” and “far too much”, respectively. For carbohydrates, the lower limits are 2.00 g and 4.00 g and the upper limits are 7.00 g and 10.00 g.
The upper and lower limits for protein, carbohydrate, unsaturated fat and saturated fat are stored as predetermined values in the [0120] database 110. Each time that the web page 1600 is displayed, the server 101 retrieves the predetermined values and calculates, on the basis of the user's physical activities, his dietary intake and his weight, whether he has been consuming the correct amounts and correct proportions of the various food categories.
Nutrition—Dietary Assessment [0121]
FIG. 17 shows a [0122] web page 1700 that the user can select for display if the field 1602 indicates that he has not been eating appropriate foods. The web page 1700 includes a protein field 1701, a carbohydrate field 1702, a fat field 1703, a fluids field 1704 and a fruit and vegetables field 1705.
The protein, carbohydrates and fat fields [0123] 1701-1703 show both the user's actual consumption 1701 a, 1702 a, 1703 a for the respective food category and the user's target consumption 1701 b, 1702 b, 1703 b for the food category. If the user needs to change his daily food intake then the fields 1701-1703 also indicate to him how large a change he needs to make.
The [0124] web page 1700 also includes a field 1704 that provides information regarding the user's fluid intake, and a field 1705 that provides information regarding the user's fruit and vegetable consumption. For the field 1704, the server 101 determines whether the user has been consuming sufficient quantities of fluids (i.e., water). If the user's daily intake of water is outside the range 31 (liters) to 51, then the field 1704 indicates that user needs to drink more or less water. For the field 1705, the server 101 calculates the user's intake of fruit and vegetable based on the user's dietary intake as entered at web page 1500. For example, Caesar salad would count towards the user's fruit and vegetable intake whereas tuna fish would not be regarded by the server 101 as forming part of the user's required fruit and vegetable intake. The server 101 consults the database 110 to assess the relevance of the foods towards the fruit and vegetable intake. For example, in this embodiment the database 110 stores predetermined information indicating that 100 g of Caesar salad counts as 50 g towards the user's fruit and vegetable intake quota.
Training Schedule—Coarse [0125]
FIG. 18 shows a [0126] web page 1800,as seen by the user, that the user can use to generate a personalized training schedule. The web page 1800 allows the user to indicate, at a coarse level, the time slots that he will have available for training during the following seven days. Here, the web page 1800 represents dates ranging from “tomorrow” (Jan. 7, 2004) through to Jan. 13, 2004. The web page 1800 includes a field 1801 that the user can use to indicate his availability for morning training sessions, both for skating training and fitness training. A field 1802 allows the user to indicate his availability for afternoon skating and fitness training sessions. As shown at FIG. 18, here the user has indicated that he can perform ice skating training on the mornings of Jan. 7, 2004 and Jan. 11, 2004, and in the afternoons of Jan. 9, 2004 and Jan. 13, 2004. Although the web page 1800 shown at FIG. 18 does not indicate that the user will be performing any fitness training during the week, it is expected that in normal use of the system 100 he would perform a mixture of both ice skating training and fitness training.
Once the user has indicated his availability, he can click a [0127] button 1803 on the web page 1800. This causes the server 101 to interact with the database 110 to suggest a proposed training schedule for review by the user.
The proposed training schedule is devised by the [0128] server 101 taking into account the user's fitness and his weaknesses. Although at FIG. 4 seven different measures of the user's fitness are shown, in this embodiment the server 101 lumps these into four categories: (i) flexibility, (ii) cardiovascular, (iii) strength and (iv) core stability. In this embodiment, flexibility is determined solely on the basis of the user's sit and reach capability. Cardiovascular is determined on the basis of the user's one mile run time and shuttles ability; in this embodiment the one mile run time and the shuttles ability are given equal weighting. Strength is determined on the basis of the user's long jump distance and high jump height. Core stability is determined on the basis of the user's situps score and pushups score. In this embodiment, the factors making up the strength and core stability categories are also given equal weighting.
For example, referring to FIG. 4, the user has scores of 100% except for pushups which is 58%, situps 68% and shuttles 72%. Thus in the core stability category, the user has a score of (68%+58%)/2=63%. In the cardiovascular category, the use has a score of(100%+72%)/200=86%. Thus of all the four categories, the user's core stability score is his weakest, while his cardiovascular is his second weakest as he has 100% in the other categories (strength and flexibility). [0129]
Thus for this user, the [0130] server 101 proposes a training schedule that concentrates primarily on improving the user's core stability score. The server 101 also attempts, with secondary importance, to develop the user's cardiovascular score.
Although for the [0131] web page 1800 at FIG. 18 the user had not selected any fitness training sessions, suppose that the user had selected four fitness training sessions. The server 101 allocates the majority of the training sessions to the primary weakness, in this case core stability, and the remaining training sessions (if any) to the secondary weakness, in this case cardiovascular. Here the user can attend four training sessions and therefore three of these are devoted to situps with the remaining session being devoted to cardiovascular exercises. If the user had selected three or fewer training sessions then they would all be devoted to core stability. On the other hand, if the user had selected five or more training sessions then the server 101 would devote one of the five training sessions to a tertiary weakness.
Once the [0132] server 101 has determined what type(s) of training are required for the training schedule, the server 101 then determines the intensity of training required.
In the case of core stability, the intensity is determined on the basis of the user's pushups and situps score. For example, here the user is capable of performing 45 pushups in one minute and 30 situps in one minute. The [0133] server 101 determines the total number of pushups and situps that the user should perform during a training slot by multiplying the user's pushups and situps scores by 1.6, to arrive at 72 and 48, respectively. (Note that as is discussed further below, the multiplier may be reduced from 1.6 to 1.0 during the week immediately before a competition.) The server 101 then separates the total number into groups that will be performed by the user at different times within a training slot. The reason that the total number is split up is to ensure that the user is overloaded during the training but without becoming excessively overloaded. Here, the user's pushups and situps scores are at the limit of the user's capability and therefore he would not be able to complete 72 pushups (or 48 situps) in one go. Distributing the total number at different parts of the training session ensures that the user derives maximum training benefit.
In the case of cardiovascular, the intensity is determined on the basis of the user's deemed maximum achievable heart rate. In this embodiment, the user's maximum achievable heart rate is estimated by subtracting the user's age from 220. Thus a 20 year old user would be deemed to be capable of achieving a heart rate of 200 beats per minute at maximum exertion. To improve the user's cardiovascular score, he is required to perform an activity such as swimming, running, cycling or skating such that his heart rate is maintained at a specified proportion of his maximum achievable heart rate. The specified proportion will depend on the user's fitness level. In this embodiment, a relatively unfit user will be required to increase his heart rate to 55% of his maximum achievable heart rate. On the other hand, an athlete of high fitness would be required to maintain his heart rate at 85% of his maximum achievable score. [0134]
Training Schedule—Fine [0135]
Once the [0136] server 101 has determined a proposed training schedule for the user, the server 101 causes the user's PC 102 to display a web page 1900, as shown at FIG. 19. The web page 1900 allows the user to review the proposed training schedule and refine the proposed training schedule until it fits in with his diary. Thus there is a two stage procedure by which the user interactively causes the server 101 to generate a training program that is tailored to the user. Firstly, the user uses the web page 1800 to inform the server 101 at a coarse level of the training that he can perform during the following week. Secondly, the user uses the web page 1900 to refine the proposed training program so that it fits in with his other activities (such as leisure and work) during the following week. An advantage of this two stage procedure is that the proposed training schedule will meet the basic requirements of the user. By contrast, a single stage procedure would run the risk of providing a poor user interface as the proposed training schedule would not take into account the user's other activities during the week (and would then require the user to extensively edit the proposed training schedule, for example by editing and moving a proposed a training slot from a day originally proposed to different day that does not clash with say, work).
The [0137] web page 1900 includes a field 1901 that represents each of the 24 hours of each of the following seven days. FIG. 19 shows days in the range Jan. 8, 2004 to Jan. 14, 2004. Each hour is divided into 15 minutes intervals. The field 1901 uses color coding to represent the types of activity allocated to the field 1901. A field 1902 provides a key to the user and explains the color codes. The field 1902 shows the colors that are used for the following activities: (i) nutrition, (ii) on-ice training, (iii) fitness, (iv) competition, (v) leisure, (vi) work, (vii) fitness test, (viii).“other” and (ix) sleep.
The [0138] web page 1900 provides a graphical user interface that allows the user to inform the server 101 of the detailed timings of his weekly schedule. For example, suppose the proposed training schedule specifies a training slot of one hour on Jan. 11, 2004 from 6 am to 7 am. In this example the server 101 knows, from the information entered by the user at web page 1800, that the user will be able to train on Jan. 11, 2004. However, the server 101 does not know the exact time that the user is available for training.
The user uses a [0139] field 1903 to inform the server that he can actually perform the training between 7.45 am and 8.45 am on that particular day (see FIG. 19). The server 101 stores the actual times (that the user will be available for training) in the database 110. This allows the user to consult the database 110 via the server 101 at any time and review or check his schedule.
If the user has entered the times and dates of forthcoming competitions using the [0140] competitions region 202 of the web page 200 then, if any competitions are due to occur during the next seven days, the competition(s) are displayed in the appropriate time slots of the field 1901. As was mentioned earlier, the server 101 can “taper off” the intensity of training in the run up to a competition, in order to minimize the risk of injury to the user before the competition.
Injuries [0141]
In case the user sustains an injury, the [0142] system 101 allows the user to enter information regarding the injury (or injuries). FIG. 20 shows a web page 2000 that allows the user to enter injury information. The web page 2000 includes an icon 2001 that represents the front of the body (a button 2002 allows the user to select the back of the body in case the injury is at the rear of the user). The user selects the icon 2001 to cause a web page 2100 to be displayed.
FIG. 21 shows the [0143] web page 2100. The web page 2100 allows the user to enter detailed information concerning the location of an injury and the severity of an injury. An icon 2101 allows the user to select a region of the body. Fields 2102 and 2103 allow the user to specify the exact locations and severity of injuries, respectively. A field 2104 allows the user to specify the date of the injury. The server 101 then stores this information in the database 110.
The [0144] field 2103 allows the user to select one of several predetermined categories of severity, for example mild (i.e., pain is not intense and ceases immediately when physical activity ceases) or severe (pain occurs immediately upon any activity using the injured area and remain for 12-24 hours after the activity ceases).
If the user has any injuries that are more serious than “mild” then the [0145] server 101 prohibits all training when proposing a training schedule for the user at web pages 1800 and 1900.
A benefit of storing the injury information in the [0146] database 110 is that the database 110 can be interrogated to determined the injury history of the user. For example, by maintaining the injury profile over the course of several years, patterns in the injuries sustained can be discerned. Some users may have technique deficiencies or muscular imbalance, resulting in an excess of injuries on one side of the body.
Coach [0147]
The system allows coaches to be associated with users. As far as the system is concerned, a coach is similar to a user in that he also has a user coach also has an account and a password for accessing the system. [0148]
A difference between a coach and a user is that the coach monitors the performance of his trainees. As the [0149] database 110 stores information associated with each user, the coach can use the server 101 to interrogate the database 110, and thus can monitor the progress of his trainees.
Before a coach can access information concerning a user, that user must first inform the [0150] server 101 that the particular coach is authorized to view his performance information. This security feature prevents coaches from monitoring users that they are not training (e.g. competing users).
Database Structure [0151]
FIGS. 22[0152] a, 22 b, 22 c and 22 d when assembled as shown in FIG. 22 show a block diagram 2200 of some of the major structures within the database 110. In this embodiment, the data that comprises the database 110 is stored on a hard disk drive (not shown).
As can be seen, in this embodiment the [0153] database 110 is a relational database having tables. Each table comprises one or more records. Each record comprises one or more fields. At least one database key is associated with each table. All tables are indexed by a primary key. The primary key allows the records of a particular table to be uniquely specified for read or write accesses. In some tables, one or more of the fields will be a foreign key. When a table contains foreign keys, that table can index records stored in a related table.
A table [0154] 2201 stores basic information concerning a user. The user is uniquely identified by a key “user_id” which allows users having identical names to be distinguished. This table also stores the date of birth of the user, his/her gender, residence address and email address. The user_id is the primary key of many of the tables that make up the database 110.
The system uses passwords to allows users to authenticate themselves to the system. A table [0155] 2202 stores each user's password.
A table 2203 relates each user, by his user_id, to his respective coach (if any). Although it is not essential that a user has a coach, it is expected that many users would have a coach to train them. Each coach has a coach_id which uniquely identifies that coach, even if several coaches have the same name. To ensure that only the intended coach is able to view the user's profile, each coach is allocated a “pin_number”. When a user and coach meet, for example during a coaching session, the coach communicates his pin_number to the user. The user can then enter the coach_id of his coach into the [0156] system 100, which stores the pin_number in the table 2204.
A table [0157] 2205 stores basic information concerning a user such as the user's height and weight.
A table [0158] 2206 stores financial information for the user, for example a transaction_id to identify a particular credit card transaction. A table 2207 stores information concerning the user's account, for example the date of activation of the account and the date of expiry of the account.
A table [0159] 2208 stores, for a variety of different data, the date that an update for the data is next required. In this embodiment the table 2208 stores the update dates of core stability, strength, growth, a mood profile of the user, goals for setting by the user (see table 2211), and the user's height and weight. Each time that the user enters data for these data types, the server 101 calculates the due date of the next update. For example, if an 14 year old male user entered height information on Jan. 14, 2004 then the due date for updating his height and weight information would be Jan. 14, 4004 plus 2 weeks, i.e. Jan. 28, 2004. The value of Jan. 28, 2004 would be stored in the table 2208 for his height and weight information. Whenever the user logs on to the server 101, the server 101 compares the actual calendar date to the dates specified by the table 2208 for updates and, if an update is required, informs the user. The use of the table 2208 increases the performance of the system 100. This is because the server 101 only needs to check the dates in the table 2208 against the calendar date.
By contrast, if, in an alternative embodiment, the system did not use the table [0160] 2208, it would be necessary, each time the user logged on to the server 101, for the server 101 to interrogate a variety of tables of the database (i.e., each table where information such as core stability was stored) as rather than storing the update dates centrally in a table 2208, the update dates would be scattered amongst a variety of tables of the database 110. Such an embodiment would require more processing time to access the various tables, due to the need for the server 101 to traverse the database hierarchy. In some situations, the increased processing time would lead to unacceptable delays while the user waited for the server 101 to interrogate the various tables of the database 110.
A table [0161] 2209 associates the user_id, a “goal_session_id”, a creation date for the session and a flag to indicate whether or not the coach (if any) is allowed to view the data associated with a particular goal_session id. The use of a goal_session_id allows the process whereby a user enters his dream, outcome and process goals (see web pages 500-900) to be broken down into separate steps if the user prefers. Typically, it will take about 20 minutes for a user to analyze his goals in conjunction with the web pages shown at web pages 500-900. Without the use of the goal_session_id, the user would have to complete the goal entering process in a single session. (If the user did not complete the session, he would have to enter all of the data all over again in a later session).
The use of a goal_session_id allows the user to enter a portion of the required data. The data entered is then stored in the [0162] database 110 and is associated with the goal_session_id. When the user is ready to enter more of the required data, the data previously entered is retrieved from the database 110 and is used to continue the goal setting process.
A table [0163] 2210 stores the data entered during a particular session and associates the data with a goal_session_id.
A table [0164] 2211 stores the results of user's goal assessments. The table 2211 stores a “psych_perf_id” which is used to relate table 2211 to a table 2212. The table 2211 stores information including the user's assessment of his own abilities, the coach's assessment of the user's abilities, and text entered by the user as part of his assessment of his abilities. The inventors of the present application have realized that a significant problem during sports training can be when the user and the coach have different assessments of the user's abilities. The fact that the table 2211 stores both the user's self assessment and the coach's assessment allows these two assessments to be compared for discrepancies.
The table [0165] 2212 stores information regarding the user's short term goals. The table 2212 not only stores specific goals but also allows the user to enter when a specific goal has been completed. In addition, the table 2212 includes a field specifying a review period for the short term goals. This ensures that the user will be prompted to periodically review his short term goals. An example of a short term goal for a user is that of ensuring that he maintains “clean heels” during an ice skating maneuver.
A table [0166] 2213 associates user_ids with “competition_id”s. A competition_id is an identifier for various competitions. The competition_id is used as a key for an event table 2214. Each event in the event table 2214 is identified by its name, start and end dates and region. The competition_id key is a composite key and comprises a plurality of the fields of the various records in the table 2214. This allows, for example, annual competitions held on different years to be distinguished on the basis of their dates.
A table [0167] 2215 stores an analysis of the user's abilities. The table 2215 stores the results of an analysis that compares the user fitness rating with his goals. In effect, the table 2215 acts as a cache to store the results of the analysis.
A table [0168] 2216 stores the dietary history of the user(s). For each user, the table 2216 records the type of food and drink that the user consumed, the number of portions, which meal the food was eaten for and the date that the food was eaten. The table 2216 includes a field “food_type_id” which is used as a key for another table, table 2217. Table 2217 is itself a database of a variety of foods and drinks, and associates the nutritional breakdown of each type of food with the respective food_type_id of the foods.
A table [0169] 2218 stores data for custom foodstuffs that are not by default included in the database 110. When a user eats a type of food or drink that is not included in the food table 2217, he has the choice of (i) entering nutritional data for the food as a one-off or (ii) creating a new type of food category and entering the nutritional data for that food. The table 2218 has two keys, the user_id and “custom_food_id”. The custom_food_id has the same function as the food_type_id of table 2217 but is personal to the user. Thus any user can select a foodstuff in the default food table 2217; on the other hand, a user can only enter custom foodstuffs that he has entered. As the data entered for a custom foodstuff is entered by the user, the authenticity of such data cannot be regarded as high as that for the foodstuff in the table 2217. Ensuring that a user can only select the custom foodstuffs that he has himself entered prevents one user from entering a foodstuff that has been incorrectly entered by another user. The table 2218 allows users to, in effect, set up a cache for food items that they frequently consume but that are not in the table 2217. Tables 2217 and 2218 store information for foodstuffs such as their sugar content, protein content, portion size, calcium content and type of food category.
A table [0170] 2219 uses “injury_id” as a unique identifier for each injury that any user sustains. The table 2219 also stores the user_id together with details on which side of the body the injury occurred and the number of injuries that have been sustained on that side. The table 2219 also stores a foreign key “injury_status_id” to a table 2220 and a foreign key “injury_kb_id” to table 2221. Table 2220 records the status of an injury and associates this with the injury_id and a rating of the severity of the injury. Table 2221 stores a knowledge base that may be consulted by the user to obtain detailed information about an injury. Table 2221 includes information about the location of an injury, the type of injury and advice concerning the various types of injuries.
A table [0171] 2222 stores the activity schedule displayed by web page 1900. The table key for table 2222 is “schedule_id” which is used to distinguish the various schedules that will be generated by the system 100. The table 2222 associates the schedule_id with the user_id and also includes information regarding the dates of activities, the start and end times, the type of activity that is to be performed during a training slot and the energy that is predicted to be expended by the user during a training slot if he trains to the specified intensity and for the specified duration.
A table [0172] 2223 stores the preliminary schedules entered into web page 1800. The key for this table is “schedule_session_id” which associates the date of a particular session, whether the user will be performing morning and/or afternoon on-ice training and whether the user will be performing morning and/or afternoon fitness training.
A table [0173] 2224 relates the various user_ids to a “skating_level_id”. There are various skating_level_ids which relate a specific ice skating skill level. A table 2225 relates the various skating_level_ids to a description of what is expected of the user at each skating_level_id. When the user creates an account, he reads the descriptions provided in table 2225 so that he can choose a skating_level_id that is appropriate to his skill level.
A table [0174] 2226 is concerned with the activity assessment for a user. The fields of the table 2226 include the duration of an activity, an “activity_id”, the date of the activity, the start time of the activity and the user_id. The key for table 2226 is a combination of the date, start time and user_id. The activity assessment table 2226 records the actual activity of the user as opposed to the intended activity stored in table 2222. The activity_id is used as a key for a table 2227 and a table 2228.
Table [0175] 2227 is keyed by activity_id and associates the various activity_ids with descriptions of the activity. Table 2228 is also keyed by activity_id and provides a predetermined breakdown of an activity for various physical categories. In this embodiment, the key activity_id indexes records that contain six fields. The six fields are cardiovascular, core strength, upper body strength, lower body strength, flexibility and local muscular endurance.
An activity analysis table [0176] 2229 contains a breakdown of a user's physical activity. For each user_id, the table 2229 records the dates of exercise and the contributions of the exercise to the user's requirements. Here, the table 2229 records the contribution of a physical activity in the cardiovascular, core strength, upper body strength, lower body strength, flexibility and local muscular endurance categories. The table 2229 also records the user's energy expenditure on each date that resulted from the physical activity.
A table [0177] 2230 records the scores of users' fitness assessments. The key for table 2230 is “fitness_assessment_score_id” which uniquely identifies each fitness assessment. Other fields in the table 2230 are the user_id; the test score(s) of the user for shuttles, the sit and reach test etc; the percentage rating of the user's scores compared to his expected rating; and a record of the date when his fitness score was last updated.
A table [0178] 2231 is used to relate users' shuttle test scores to their bodies' mlO₂/kg capability, where mlO₂/kg is a measure of the users' ability to transport oxygen, measured in ml of O₂, around his body per kg of body weight. Given the level at which a user completed the shuttle test (i.e. the period between successive “bleeps”) and the number of shuttles completed at the final level, a formula is used to calculate the expected mlO2/kg rating of the user. In this embodiment the formula has been developed by Loughborough University of Great Britain and has been found to give a good indication of the user's mlO₂/kg score.
A table [0179] 2232 is used to relate the fitness assessment scores of a user to target values for each of the categories of measurement. In this embodiment the table 2232 has target values that would be expected of an elite skater for each of the categories in the fitness assessment test (shuttles, 1 mile run, sit and reach etc.). Table 2232 has expected scores for both males and females of ages 8-60. Thus the expected fitness assessment scores of, for example, a 23 year old female ice skater are determined by looking up the most appropriate fitness assessment scores from the table 22322. Note that the table 2232 also includes the mlO₂/kg expected of a user, again indexed by age and gender. Although the fitness tests do not directly measure the mlO₂/kg ability of a user, this can be inferred as was explained for table 2231 above and so is included in the table 2232.

Description of a Second Embodiment

At FIG. 23 there can be seen a [0180] server 10 with accompanying computer terminal 11. The server 10 is connected via a telecommunication network, e.g. the Internet, to remotely located personal computers 12, 13, and 14. In the example given the server 10 has a website which can be accessed via the Internet and users of the system use web-browser software on the personal computers 12, 13 and 14 to access the website hosted by the server 10.
On the [0181] server 10 there is maintained a database which for each of the plurality of sports maintains a record of an idealized physiological profile for the sport.
To obtain a meaningful physiological profile the second embodiment can use items such as: [0182]
Maximum capacity to transport oxygen to tissues(VO[0183] _2max),
% of VO[0184] _2maxthat may be maintained without accumulation of lactate (OBLA),
Maximum strength measured as the greatest weight that can be lifted just once (1-RM), [0185]
Maximum power measured as the work output in a unit of time (POW) [0186]
Core strength measured as the maximum number of sit-ups (COR[0187] 1), push-ups(COR2) and crunchies (COR3) that can be performed without rest.
Local muscular endurance (LME). [0188]
As an example, an elite marathon runner is likely to have relatively high VO[0189] _2max, very high OBLA, low 1-RM, low POW, low COR1, low COR2, low COR3 and low LME when compared to a gymnast, or a figure skater.
Similarly, the marathon runner will have a different psychological, nutritional and injury profile from the gymnast or an overweight person due to the dissimilar demands of the respective sports and goals. [0190]
In the system, the stored idealized physiological profile for a sport is used to determine where the weakness in a particular athlete lies, and an ongoing training and assessment schedule is generated. [0191]
When a sports person first accesses the website hosted by the [0192] server 10 he/she is asked to supply the following information (hypothetical figures are given as illustrations):

Variable Athlete

Gender Male

Age 24

Height (m) 1.76

Resting Heart rate (bpm) 34

Weight (kg) 76

Sport Long distance runner (10 km+)
The [0193] server 10 then retrieves from the database the idealized physiological profile for the sport selected by the sports person, in this case long distance running. The retrieved measurements of the idealized profile are then scaled having regard to the body weight of the sports person, the gender and age. The resulting figures for these hypothetical examples are given in the table below.

Variable Idealized Measurements

VO_2max(mlO₂/kg) 80

OBLA (% VO_2max) 65

1-RM (kg) 385

Aerobic Power (W/kg) 28

Core strength 100

LME (mmol/l) 2.25
The sports person is prompted by a visual display on the local personal computer to input measurements of his/her Vo[0194] _2max, OBLA, 1-RM, POW, COR1, COR2, COR3 and LME. The server 10 then calculates from the input POW and weight information an aerobic power figure and from the input COR1, COR2 and COR3 figures a core strength figure. Then the server 10 makes a comparison between the current physiological profile of the sports person and the idealized physiological profile for the selected sport (normalized by weight, age and gender) as illustrated by the table below.

Optimum Actual

Variable value Value % difference

VO_2max(ml/kg) 80 60 75

OBLA 65 60 92

Aerobic Power (W/kg) 26 21.7 83.5

1-RM squat 85 kg 75 88

Core strength 100 95 95

LME 2.25 2.30 102.2
From the comparison the system can establish that the most important area to improve for this particular athlete is VO[0195] _2max.The system would now recommend a training regime to maximize the key component.
Optimizing the VO[0196] _2maxcan be achieved by establishing a training regime that has a high volume and relatively low intensity. For running, the scheme follows that shown below (which would be relayed to the sports person as information displayed on the video display unit of his/her personal computer and printed locally by the sports person).

Factor (component) Lower Value Upper Value

Sessions/week (volume) 3 4

Distance % of competition (volume) 150 180

Intensity % of maximal heart reserve 65 75

(intensity)
The volume of training is evaluated as shown: [0197]
Volume_run=Sessions*Distance, where
Sessions=number of sessions per week and distance=distance run in each session.
In the hypothetical example, the athlete is recommended to complete 3 training sessions with distance=150% of competition distance (i.e., 15 km). There should be 2 days rest between training. [0198]
The intensity is evaluated as a percentage of Maximum output from following the Karvonen formula: [0199]
THR=HR _rest +INT*(HR _max −HR _rest), where
THR=training heart rate
INT=Intensity percentage/100 (e.g. 80%=0.8)
HR_rest=Resting heart rate and
HR _max=Maximal heart rate (this is either available from a maximal test or can be estimated from 220−age (years))
For our athlete, the THR=34+0.70*((220−24)−34)=163 beats/minute
The actual training run can be done within a band of 5 beats/minute either side of THR (at this level of athlete, one would expect that a heart rate monitor is used). [0200]
In a variation of the system the sports person is assessed for symptoms of overtraining, and research has shown that psychological assessment tools such as a Profile of Mood States (POMS) can be used to indicate risk of overtraining. [0201]
Mood data for the sports person are obtained by appropriate questions relayed via the local personal computer. Categories are established as shown in the table below. The base value represents the average value from all of the data obtained during the off-season. For details of the specific method for eliciting data from a profile of mood states questionnaire see Terry et al. (1999). [0202]

Last session

Mood dimension Base Value value

Anger

4 6

Tension 5 8

Vigor 9 4

Depression 1 5

Fatigue 2 7

Total 21 30
The system compares current POMS scores to historical base values (obtained during an off-season). Two tests are used: [0203]
Test 1: is the current total POMS score more than 50% above reference values? In our case, 21+50%=31.5 indicating that it is not. [0204]
Test 2: Is the current measure of Fatigue higher than current measure for Vigor? In our case this is true. [0205]
The overtraining risk is used to modify the proposed training schedule by reducing the recommended training volumes and training intensities by the percentage figures below (overtraining risk is 0% if the answers to both of the above questions are “no”, 50% if one answer is “yes” and one is “no” and 100% if both answers are “yes”). [0206]

Overtraining Training Training

Risk % Volume Intensity

0 0 0

50 15 20

100 60 50

Alternative Embodiments

The training systems have been described above in terms of a single user. In alternative embodiments the systems may be used for a plurality of different users. In this case, each user is allocated a respective user_id when he/she creates an account with the [0207] server 101.
The training systems described in the first embodiment above comprised a [0208] server 101 which communicated with a PC 102. In alternative embodiments the server 101 may be connected to a plurality of PCs 102. The server 101 may either be connected to any one of a number of different PCs 102 or may be simultaneously connected to a plurality of separate PCs 102. In embodiments where the server 101 is simultaneously connected to different PCs 102 it is anticipated that each PC 102 would be used by a respective user of the system 100.
The training system uses a [0209] PC 102 to provide a graphical user interface to a Java program which controlled the server 101. The PC 102 was caused to display internet pages using a web browser. In an alternative embodiment the server 101 may communicate with dedicated software installed on the PC 102. In this alternative embodiment, the dedicated software provides the graphical user interface.
The training system uses a [0210] server 101 which accesses a database 110. Communication between the user's PC 102 and the server 101 is performed using a telecommunications link. In an alternative embodiment, software is installed on the PC 102 of a user who wishes to use the training system. In this alternative embodiment, the software programs the PC 102 to implement the database 110 on the hard disk of the user's PC. An advantage of this embodiment is that the PC 102 need not communicate with a remote server. However, an advantage of operating the system using a central server 101 that is used by all user PCs 102 is that improvements and upgrades may more readily be made to the system. For example, when using a server 101, it is relatively straightforward to update an incorrect database entry for a particular foodstuff. In an embodiment where software for implementing the training system is installed separately on each PC 102 then it will be harder to update the databases as an updated database entry will need to be sent to each PC 102.
In some embodiments, dedicated circuitry may be used to implement the required functionality of the training system. However, for reason of cost, it is expected that most embodiments will include an element of software. Such software may be supplied on a suitable data carrier such as a floppy disk or a CD-ROM. Alternatively, software may be supplied over a telecommunications channel such as the internet. [0211]
The training system uses circular charts to display the user's fitness assessment and the user's goals. In an alternative embodiment other graphical formats may be used instead, for example column charts. However the use of circular charts is preferred as this provides an intuitive user interface for the user(s). [0212]
The training system of the first embodiment enables ice skaters to become more proficient at ice skating by helping such users to organize their training schedules, eat appropriate foodstuffs and to perform physical activities appropriate to their aims. In an alternative embodiment, the training system is be used to train other types of sports persons. For example, in an alternative embodiment the [0213] database 110 is modified to allow long distance runners to train effectively. In such an embodiment the database 110 is expanded so that as well as containing information primarily dedicated to training ice skater, the database also contains information primarily dedicated to training long distance runners. In such an alternative embodiment the tables 2224, 2225 and 2232 are modified to include predetermined skill level categories for long distance runners together with descriptions of the skill categories of long distance runners. Table 2232 would also require modification to be keyed by the type of sport being performed by the user (this is because table 2232 when described earlier included the scores expected of various ages of elite ice skaters, but did not include the corresponding scores that could be expected of various ages of long distance runners). In a yet further alternative embodiment, separate databases are used for different types of users. For example, ice skaters may use a first database 110 and long distance runners may use a second database. In the yet further embodiment, either a common server 101 is used to access the two databases, or separate servers are used, one for each database.
The training system of the first embodiment facilitates ice skaters to become more proficient at their sport. In an alternative embodiment, the [0214] server 101 and a modified database facilitate a user to, for example, lose weight. In an yet further embodiment, a modified database facilitates a user to gain weight (for example body builders who wish to increase their muscle mass).
In an alternative embodiment of the [0215] training system 100 described above, the presence of any injuries as entered at the web pages 2000 and 2100 is used to modify the dietary assessment shown at web page 1700. Normally, a user's required protein intake was determined on the basis of his body weight. When a user has a soft tissue injury he will in some situations require additional protein in order to allow his body to repair the damage. In an alternative embodiment, the server 101 is operable to use the database 110 to determine whether the user has an injury having a severity that exceeds a predetermined threshold. If so, then the suggested daily protein intake for the user is increased accordingly. Similarly, in alternative embodiments of the system 100 the user's calcium intake in monitored. In the event that the user breaks a bone then his recommended calcium intake is increased to facilitate repair of the broken bone.
In the first preferred embodiment described above, the [0216] server 101 compared the user's water intake with predetermined lower and upper limits of 31 (litres) to 51 of water per day. In that embodiment the user was deemed to be an ice skater (i.e. an athlete), due to the level at which the user was training. In an alternative embodiment, the user need not be deemed an athlete, in which case the server 101 calculates the user's fluid requirements based on the user's body weight. For example, the lower limits are set at 25.00 ml (milli-litres) and 30.00 ml of water per kg of bodyweight per day, and the upper limits are set at 40.00 ml and 45.00 ml of water per kg per day. The server 101 also increases the deemed water requirement by 500 ml for each hour of exercise per day.
The training system of the first embodiment described above calculated the user's actual energy expenditure on the basis of the activities performed by the user and the basal metabolic rate of the user. In an alternative embodiment, the user's energy expenditure may be calculated on the basis of the training program suggested at [0217] web page 1900, on the assumption that the user will perform the suggested training schedule faithfully and that there will be little or difference between the suggested training and the actual training performed by the user.
The training system of the first embodiment described above used the internet to transfer information between users, the server and the payment server. In an alternative embodiment, dedicated telecommunications links may be used to transfer information. Such dedicated telecommunications links may comprise wires or wireless links. [0218]

Claims

What is claimed is:

1. A training system comprising:

a database comprising information regarding the relevance of different physical activities to fitness categories; and

a server for transferring information between a user and the database.

2. A training system according to claim 1, wherein the database comprises information regarding the relevance of different physical activities to at least one of the following fitness categories: flexibility, cardiovascular, local muscular endurance, core stability, lower body strength and upper body strength.

3. A training system according to claim 2, wherein the server is operable to receive information from a user regarding the duration of a physical activity that the user has performed and to calculate the contribution of the physical activity performed to the user's fitness in at least one of the fitness categories.

4. A training system according to claim 1, wherein the database comprises information regarding the energy expenditure of the physical activities.

5. A training system according to claim 4, wherein the server is operable to receive information from a user regarding the duration of a physical activity that the user has performed and to calculate the energy expended by the user as a result of the physical activity that the user has performed.

6. A training system according to claim 1, wherein the server is operable to receive from the user information regarding a fitness profile of the user, wherein the fitness profile comprises information regarding the actual ability of the user to perform one or more measures of physical fitness.

7. A training system according to claim 6, wherein the server is operable to receive an indication from the user of a target physical fitness profile for the user.

8. A training system according to claim 7, wherein the server is operable to compare the actual fitness profile of the user with the target physical fitness profile of the user to generate difference information.

9. A training system according to claim 8, wherein the server is operable to output the difference information to the user.

10. A training system according to claim 9, wherein the server is operable to output the difference information as a chart.

11. A training system according to claim 1, wherein the server is operable to receive from the user an indication of the availability of the user for training.

12. A training system according to claim 7, wherein the server is operable to receive from the user an indication of the availability of the user for training.

13. A training system according to claim 12, wherein the server is operable to generate a recommended training regime for the user as a function of the difference information and the availability of the user for training.

14. A training system according to claim 13, wherein the server is operable to receive information from the user regarding the availability of the user for the recommended training regime, and

wherein the server is operable to modify the recommended training regime in accordance with the availability of the user for the recommended training regime, to generate a modified recommended training regime.

15. A training system according to claim 13,

wherein the difference information comprises fitness category difference information regarding the differences between i) the actual fitness of the user in two or more fitness categories and ii) the target fitness of the user in two or more fitness categories,

wherein the server is operable to compare the fitness category difference information to determine for which of the two or more fitness categories there is the greatest difference between the actual fitness of the user and the target fitness of the user, and

wherein the server is operable to prioritize the suggested training regime for the fitness category in which there is the greatest difference between the actual fitness of the user and the actual fitness of the user.

16. A training system according to claim 13, wherein the server is operable to receive information from the user regarding a date of a competition, and wherein the server is operable to reduce an intensity of the training in the recommended training regime in a run-up to a competition.

17. A training system according to claim 13, wherein the server is operable to receive information from the user regarding an injury that the user has sustained, and wherein the server is operable to reduce an intensity of the training in the recommended training regime according to the information reg

18. A training system according to claim 1, further comprising a payment server for processing a financial transaction, wherein the payment server and the server are operable to transfer data using a telecommunications link.

19. A method of training a user, comprising using a training system according to claim 1.

20. A computer program product storing processor executable instructions for programming a processor to implement a training system according to claim 1.

21. A training system comprising:

a database comprising information regarding the nutritional content of different foodstuffs; and

a server for transferring information between a user and the database.

22. A training system according to claim 21, wherein the database comprises information regarding the nutritional content of foodstuffs in at least one of the following categories: protein, carbohydrate, unsaturated fat, saturated fat and calcium.

23. A training system according to claim 21, wherein the server is operable to receive information from a user regarding the type of foodstuffs and quantity of foodstuffs that the user has consumed and wherein the server is operable to use the information stored in the database regarding the nutritional content of the foodstuffs to calculate the actual nutrition gained by the user as a result of the foodstuffs that the user has consumed.

24. A training system according to claim 21, wherein the server is operable to predict a nutritional requirement of the user.

25. A training system according to claim 24, wherein the server is operable to predict the nutritional requirement of the user on the basis of an energy requirement of the user.

26. A training system according to claim 25, wherein the server is operable to receive information from the user regarding one or more physical activities that the user has performed and to calculate the energy requirement of the user on the basis of the one or more physical activities that the user has performed.

27. A training system according to claim 26, wherein the server is operable to use information concerning a basal metabolic rate of the user to calculate the energy requirement of the user.

28. A training system according to claim 24, wherein the server is operable to compare the actual nutrition gained by the user with the predicted nutritional requirement of the user.

29. A training system according to claim 28, where the server is operable to output, to the user, information regarding a difference between the actual nutrition gained by the user and the predicted nutritional requirement of the user.

30. A training system according to claim 29, wherein the server is operable, on the basis of the difference between the actual nutrition gained and the predicted nutritional requirement, to output, to the user, information specifying modifications to a diet of the user for reducing the difference between the actual nutrition gained and the predicted nutritional requirement.

31. A training system according to claim 28, wherein the server is operable to output information specifying modifications to the diet of the user in at least one of the following categories: protein, carbohydrate, unsaturated fat, saturated fat and calcium.

32. A training system according to claim 21, wherein the server is operable to receive information from a user regarding the nutritional content of a foodstuff, and to cause the information to be stored in the database.

33. A training system according to claim 32, wherein the server is operable to receive information from two or more users regarding the nutritional content of foodstuffs, and wherein the server is operable to prevent a first user from accessing information provided by a second user.

34. A training system comprising:

a database for storing information regarding a goal of a user; and

a server for transferring information between a user and the database.

35. A training system according to claim 34, wherein the server is operable to prompt a user to enter information regarding a long term goal.

36. A training system according to claim 34, wherein the server is operable to prompt a user to enter information regarding a medium term goal.

37. A training system according to claim 34, wherein the database stores information regarding a short term goal.

38. A training system according to claim 34, wherein the server is operable to receive information from the user indicating an performance of the user with regard to one or more goals, wherein the server is operable to compare the performance with the one or more goals, and wherein the server is operable to output to the user information representing a result of the comparison.

39. A training system according to claim 38, wherein the server is operable to output the information to the user in the form of a pie chart.

40. A training system according to claim 38, wherein the server is operable to prompt the user to enter information specifying what the user regards as priority goals, and wherein the server is operable to output to the user information representing the result of the comparison for only the goals specified by the user as priority goals.

41. A training system comprising:

a database for storing information regarding an injury sustained by a user; and

a server for transferring information between a user and the database.

42. A training system according to claim 41, wherein the server is operable to receive information from the user specifying the location of an injury.

43. A training system according-to claim 41, wherein the server is operable to receive information from the user specifying a severity of an injury.

44. A training system according to claim 41, wherein the server is operable to receive information from the user specifying a date that the injury was sustained.

45. A computerized system for devising a training scheme for a sports person comprising:

first computer means for processing data, which has a database which stores for each of a plurality of sports a record of an idealized physiological profile; wherein:

each sports person using the system inputs a selection of a sport and, in response to enquiries generated by the first computer means, information concerning his/her physiological profile; and

the first computer means compares the physiological profile input by each sports person with the idealized physiological profile for the relevant sport and from this comparison formulates a training regime which is relayed to the sports person.

46. A system as claimed in claim 45 wherein:

the first computer is connected via a telecommunications network to a plurality of remotely located computer means; and

each sports person uses one of the plurality of remotely located computer means to input data to the first computer means via the telecommunications network and to receive enquiries and the formulated training regime from the first computer means via the telecommunications network.

47. A system as claimed in claim 46 wherein:

the first computer means for each sports person scales the stored idealized physiological profile for the selected sport having regard to the weight of the sports person and compares the input physiological profile with the scaled identical physiological profile when formulating the training regime.

48. A system as claimed in claim 47 wherein:

the first computer means for each sports person scales the stored idealized physiological profile for the selected sport having regard to the gender of the sports person and compares the input physiological profile with the scaled idealized physiological profile when formulating the training regime.

49. A system as claimed in claim 47 wherein:

the first computer means for each sports person scales the stored idealized physiological profile for the selected sport having regard to the age of the sports person and compares the input physiological profile with the scaled idealized physiological profile when formulating the training regime.

50. A system as claimed in claim 45 wherein:

each stored record of an idealized physiological profile comprises measurements taken from the set of: maximum capacity to transport oxygen to tissues; percentage of maximum oxygen transport capacity that may be maintained without accumulation of lactate; greatest weight that can be lifted once; maximum power; maximum number of sit-ups performed without rest; maximum number of push-ups performed without rest; maximum number of crunches performed without rest; and local muscle endurance; and

the first computer means generates enquiries relayed to the sports person which require data matching the measurements stored for the idealized physiological profile.

51. A system as claimed in claim 45 wherein:

the training regime formulated by the first computer means comprises recommendations for training session frequency.

52. A system as claimed in claim 45 wherein:

the training regime formulated by the first computer means comprises recommendations for heart rate during training.

53. A system as claimed in claim 46 wherein:

each sports person inputs periodically, in response to enquiries generated by the first computer means, data to establish a psychological profile for the sports person; and

the first computer means compares each input psychological profile for each sports person with a stored base psychological profile for the sports person and dependent on the comparison can modify the training regime formulated by the first computer means.

54. A method of devising a training scheme for a sports person comprising the steps of:

storing on a database on the first computer means an idealized physiological profile for each of a plurality of sports;

a sports person inputting to the first computer means a selection of a sport and, in response to enquiries generated by the first computer means, information concerning his/her physiological profile; and

a computer program running on the first computer means comparing the physiological profile input by each sports person with the idealized physiological profile for the relevant sport and from the comparison formulating a training regime which is then relayed to the sports person.

55. A computerized system for devising a training scheme for a sports person comprising:

first computer means for processing data, which has a database which stores a record of an pre-programmed physiological profile; wherein

each sports person using the system inputs, in response to enquiries generated by the first computer means, information concerning his/her physiological profile;

each sports person using the system can vary the pre-programmed physiological profile by inputting a target or targets selected from options provided by the first computer means;

the first computer means compares the physiological profile input by each sports person with the varied physiological profile selected by the sports person and from this comparison formulates a training regime which is relayed to the sports person.