REFERENCE TO PENDING APPLICATIONSThis application claims priority of UK Application No. 0306734.5, filed 24 Mar. 2003.[0001]
REFERENCE TO MICROFICHE APPENDIXThis application is not referenced in any microfiche appendix.[0002]
FIELD OF THE INVENTIONThe present invention relates to a computerized system for devising a training scheme for a sports person.[0003]
BACKGROUND OF THE INVENTIONIt 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.[0004]
BRIEF SUMMARY OF THE INVENTIONIn 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.[0005]
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.[0006]
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.[0007]
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.[0008]
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.[0009]
BRIEF DESCRIPTION OF THE DRAWINGSFIG. 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]ato22dshow the database structure of a database of the training system, with FIG. 22 showing how FIGS. 22ato22dshould be assembled; and
FIG. 23 shows a schematic illustration of a second embodiment of a computerized training system.[0032]
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTSFIG. 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]server101 which is connected to a personal computer (PC)102 by acommunications link112. In this embodiment theserver101 implements arelational database110 and runs software that implements the training system. In this embodiment of the system thedatabase110 is shown as being a constituent part of theserver101 although in alterative embodiments thedatabase110 may be separate from theserver101.
The PC[0037]102 is operated by a user of the system and allows the user to send data to theserver101 and to receive data from theserver101. Data received by theserver101 from the PC102 can be stored on a hard disk (not shown).
The[0038]server101 is also connected by acommunications link113 to apayment server103. A user pays to use thesystem100 by entering their credit card details at the PC102. The credit card details are then encrypted by known means and transferred over thecommunications link112 to theserver101 and then transferred from theserver101 over thetelecommunications link113 to thepayment server103.
In this embodiment the[0039]communications links112,113 both comprise the internet. When a user contacts theserver101, his PC102 requests an internet web page from theserver101. Theserver101 then generates a web page and transfers the web page over thecommunication link112 to the PC102 for display. The PC102 uses suitable software such as Internet Explorer or Mozilla to display the web page. In this embodiment theserver102 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 PC102 to transfer the entered information to theserver101. The user can use different parts of thesystem100 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, theserver101 then generates the appropriate web page. On some web pages generated by theserver101, 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 system100 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 thedatabase110.
Creating an Account[0041]
To create an account (also known as “registering”) with the[0042]server101, the user asks theserver101 to establish a new account for him. Theserver101 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 theserver101, and (vii) his credit card details.
The[0043]server101 passes the credit card details to thepayment server103. If his credit card details are valid and are successfully processed by thepayment server103 then thepayment server103 informs theserver101 that his account can be activated. Once his account has been activated by theserver101, the user can then authenticate himself to thesystem100 using his password and can begin to use the features provided by thesystem100.
Introductory Web Page[0044]
FIG. 2 shows a[0045]web page200 which is initially seen by the user whenever he uses hisPC102 to connect to theserver101. Theweb page200 has seven regions201-207 which act as icons and allow the user to select a particular aspect of thesystem100.
In this embodiment, the[0046]system100 provides a training system for ice skaters and thus the regions201-207 are customized accordingly. The seven regions are:nutrition201,competitions202,fitness203,ice training204,goals205,injury206 and updates207.
The[0047]nutrition region201 allows the user to enter information concerning his diet. Theserver101 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. Thecompetitions region202 reminds the user of forthcoming competitions and allows the user to enter information concerning competitions. Thefitness region203 allows the user to enter information concerning his current fitness levels with regard to various indications of fitness. Theice region204 allows the user to enter information concerning his skill and training levels on ice. Thegoal setting region205 allows the user to enter “goals” that the user wishes to achieve. Theinjury region206 allows the user to enter information concerning injuries that the user may inadvertently have sustained. Theupdates region207 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]server101 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 region203 displays a text caption that informs the user that this information is required by theserver101. The user then selects thefitness region203. In response, theserver101 prompts the user to enter the (i) basic physical attributes and (ii) detailed fitness information.
Firstly, the[0051]server101 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]server101 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 theserver101 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]server101 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 theserver101 to prompt the user to enter more recent information when there is a risk that the current information might be out of date. Theupdates region207 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 page300 as seen by the user. Theweb page300 includes aregion301 that lists the seven categories of detailed fitness information. The height and weight categories are not shown by FIG. 3. As shown, theregion301 indicates that the updated information regarding the user's sit and reach ability is required now (i.e. theregion301 displays “Now”), arid indicates that updated information regarding the vertical jump and the long jump will be required in 7 days' time (thus theregion301 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]server101 stores the date of the most recent information and compares this with the current date. The result of the comparison is used by theserver101 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 theserver101 prompts the user for more recent information. In this embodiment, for each of the 9 different categories, theserver101 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]server101 by the user, theserver101 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]server101 has received the fitness information from the user, the user can select a fitness status assessment. FIG. 4 shows an example of aweb page400 illustrating afitness status assessment401. In this embodiment the fitness status assessment is achart401 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. Thechart401 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]database110 of theserver101.
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]server101 interpolates and extrapolates the stored information in order to determine the fitness level expected of the user. Note that in an alternative embodiment, theserver101 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]server101 has compared the user's actual fitness level with the fitness level expected of him, the fitness assessment results are displayed as thepie chart401.
Goals—Setting[0067]
By selecting the[0068]goal setting region205 of FIG. 2, the user can indicate to theserver101 that he wishes to enter, or review, information concerning his goals. In response, theserver102 causes a web page to be displayed on the user's PC.
FIG. 5 shows an[0069]example web page500 as seen the user. Theweb page500 includes sections relating to “outcome”goals501, “long term”goals502 and “dream”goals503.Outcome goals501 are relatively short term goals.Dream goals503 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 section501 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 section502 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 longterm goal section502.
Finally, the user can use the[0073]outcome goal section501 to enter goals that have definite outcomes. The outcome goals are intended to be relatively short term and thus theserver101 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 thedream goal section503, longterm goal section502 andoutcome goal section501, 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 page600 that enables the user to set his outcome goals. Theweb page600 is displayed when the user selects a “Details”button510 on theweb page500. As shown, theweb page600 allows the user to select outcome goals from a drop-down box601. 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 page600 to enter the dates of competitions. The dates entered of such competitions are stored by theserver101 in thedatabase110. When a competition approaches (for example is two weeks away) theserver101 “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 sections501-503, he will be ready to use a “factors”section504 and a physical strengths &weaknesses section505 of theweb page500. Thefactors section504 and the physical strengths &weaknesses section505 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 section504 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, thefactors section504 offers a range of predetermined options that are suitable for the technical factors that affect an ice skater. As shown at thefactors section504, 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 thefactors section504.
The physical strengths &[0078]weaknesses section505 allows the user to enter what he regards as key physical strengths and weaknesses that he needs to develop. The physical strengths andweaknesses section505 allows the user to select from predetermined options. As shown at the physical strengths andweaknesses section505, the user has selected cardiovascular and flexibility as his weaknesses. Note that the view of the physical strengths andweaknesses section505 shown at FIG. 5 does not show any strengths.
Once the user has entered his strengths and weaknesses into the[0079]factors section504 and the physical strengths &weaknesses section505, he can select anbutton506 to display graphical representation of his strengths and weaknesses.
Goals—Graph[0080]
FIG. 7 shows an[0081]example web page700 as seen by the user. In this embodiment, theweb page700 includes achart701 that allows the user to readily interpret his strengths and weaknesses. Thechart701 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 thepie chart701 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 theweb page500.
Goals—Completion and History[0082]
FIG. 8 shows a goal[0083]completion web page800, as seen by the user. Theweb page800 is displayed at the user'sPC102 when the user selects an appropriate icon (not shown) from theweb page500. Theweb page800 allows the user to review his goals and to indicate to theserver101 when goals have been completed. Thus thesystem100 provides a goal orientated method to facilitate the user to understand ways in which he can improve his performance.
The[0084]web page800 displays goals that have not been completed at aregion801 and displays goals that have been completed at aregion802. A description of a goal that has been selected by the user is displayed at aregion803. Note that FIG. 8 does not actually show any goals.
A user can readily use the[0085]web page800 to inform theserver101 of the goals that have been completed. For example, if a goal has been completed then the user selects the goal and then selects abutton805 which causes theserver101 to move the goal from an “incomplete” section of thedatabase110 to a “completed” section of thedatabase110. Theweb page800 is then updated. It will be recalled that theserver101 implements adatabase110. Goals that have not been completed are stored in a section of thedatabase110 allocated for incomplete goals. When the user has completed the goal, he uses thebutton805 to cause theserver101 to update thedatabase110 and move the goal to the section of thedatabase110 allocated for completed goals.
FIG. 9 shows a goal[0086]history web page900. Theweb page900 helps the user to keep track of his goals. Asession date field901 allows the user to enter a session date, in this case Dec. 1, 2003. In response, theserver101 interrogates thedatabase110 for goals relevant to the session date and causes an updatedweb page900 to be displayed at the user'sPC102. The updatedweb page900 displays the relevant goals in adisplay field902. Note that in FIG. 9, only a completed long term goal is shown in thedisplay field902. Agoal category field903 allows the user to select a particular category of goals to be displayed in thedisplay field902. As shown by FIG. 9, the user has selected long term goals in thefield903 and thus only long term goals having relevant dates are displayed in thedisplay field902.
Activity Assessment[0087]
The[0088]fitness region203 of theweb page200 allows the user to cause theserver101 to display an activityassessment web page1000 on the user'sPC102. FIG. 10 shows the activityassessment web page1000 as seen by the user. The activityassessment web page1000 allows the user to inform theserver101 of the physical activities that the user has performed recently. In response, theserver101 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 page1000 shows afield1001 which, in this embodiment, displays the most recent seven days. (Theserver101 in this embodiment includes a real time clock so that theserver101 always knows the current calendar date.) Thefield1001 has sevenbuttons1002 which the user can select to view and/or edit the physical activities for the respective day. Thefield1001 also has sevenstatus indicators1003 which inform the user when physical activity information as been entered for the respective day. In this embodiment, theserver101 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]buttons1002 theserver102 causes a detailed activityassessment web page1100 to be displayed on the user'sPC102. FIG. 11 shows an example of a detailed activityentry web page1100, in this case for the date Jan. 6, 2004. Theweb page1100 includes two pull downmenus1101 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 downmenu1102 to indicate to theserver101 the duration of the activity. In FIG. 11, the duration selected for the activity is one hour. Finally, the user uses abutton1103 to add the activity to alist1104. Thelist1104 lists all the activities entered for the particular day.
Energy Expenditure[0091]
On the basis of the activity information entered, the[0092]server101 calculates the energy expenditure for the day (i.e., for the 24 hour period of Jan. 6, 2004). Theserver101 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, theserver101 consults thedatabase110 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, theserver101 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 list1105. Similarly, the user will expend 449 kCal per hour when playing baseball.
When the user has used the[0094]web page1100 to enter his activities for at least 5 of the most recent 7 days, theserver101 calculates his average daily energy expenditure and displays this at afield1201 as part of an activity assessmentoverview web page1200, shown at FIG. 12. Theweb page1200 also includes afield1204 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]button1203 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 page1300, as seen by the user. Theweb page1300 displays afield1301 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]field1301 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]field1301 shown at FIG. 13 displays “actual” and “target” percentages for each of the six training areas although note that, for theweb page1300, 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]database110 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 page1100 for each of the days, theserver101 uses thedatabase110 to assess how relevant the activities are to the training needs of, in this embodiment, an ice skater. Thedatabase110 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 thefield1301.
Note that in this embodiment the percentages displayed at the[0102]field1301 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 thefield1301. The weights are stored in thedatabase110.
As will be described later in more detail, the predetermined information stored in the[0103]database110 concerning the physical activity requirements for the six training areas can be modified by theserver101 before being used as the target percentages in thefield1301. 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 page1400 which includes afield1401. Thediet web page1400 is similar to theweb page1000 and allows the user to enter information about the foods he has eaten during the previous week. Thesystem101 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]buttons1402, the user can select one of the preceding days.
FIG. 15 shows a[0107]web page1500 that allows the user to enter dietary information for a particular day. As shown, theweb page1500 is for the date of Jan. 6, 2004. Theweb page1500 includes pull downmenu1501 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]menu1502 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 downmenu1503 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. Thedatabase110 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]button1403 of theweb page1400 to view an assessment of his diet regarding his needs. Theserver101 uses information stored in thedatabase110, 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]database110 for later retrieval. Usually, the user will enter information every week concerning his food intake for the previous week. The data stored in thedatabase110 avoids the user having to enter the data from scratch each week. Instead, the user can cause theserver101 to retrieve the data from thedatabase110 and display the data at a web page (not shown) at the user'sPC102. 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 theserver101 that his diet was the same as the previous week.
Once the[0112]server101 has determined the user's food intake, this can be displayed at aweb page1600.
Nutrition—Assessment[0113]
FIG. 16 shows a nutrition[0114]assessment web page1600 which displays at afield1601 the daily energy requirement of the user as calculated on the basis of the information provided by the user atweb pages1000 and1100. Thefield1601 displays the same numerical value for the user's daily energy requirement as was calculated by theserver101 for display at thefield1201 ofweb page1200.
A[0115]field1602 of the calorificassessment web page1600 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 theserver101 on the basis of the dietary information entered by the user atweb pages1400 and1500. In this embodiment, theserver101 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 thefield1602 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]field1602 also provides an indication to the user of the suitability of his dietary food and drink intake. As shown at FIG. 16, here thefield1602 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 theserver101. Theserver101 analyses the user's food intake for the previous seven days and compares this with a profile that is stored in thedatabase110. Depending on the results of the comparison, theserver101 causes thefield1602 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]server101 calculates the user's energy requirement by comparing the user's calorific intake with the user's calorific expenditure displayed at thefield1201. In this embodiment, if the user's energy intake is within 10% of his energy expenditure then “OK” is displayed at thefield1602, 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 thefield1602 displays “too low” or “too high”, respectively. If his energy intake is less than 70% of more than 130% of his energy expenditure then thefield1602 displays “far too low” or “far too high”, respectively.
In this embodiment, the[0118]server101 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 theupper limits 22% and 25%.
In this embodiment the[0119]server101 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 thefield1602 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, thefield1602 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]database110. Each time that theweb page1600 is displayed, theserver101 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 page1700 that the user can select for display if thefield1602 indicates that he has not been eating appropriate foods. Theweb page1700 includes aprotein field1701, acarbohydrate field1702, afat field1703, afluids field1704 and a fruit andvegetables field1705.
The protein, carbohydrates and fat fields[0123]1701-1703 show both the user'sactual consumption1701a,1702a,1703afor the respective food category and the user's target consumption1701b,1702b,1703bfor the food category. If the user needs to change his daily food intake then the fields1701-1703 also indicate to him how large a change he needs to make.
The[0124]web page1700 also includes afield1704 that provides information regarding the user's fluid intake, and afield1705 that provides information regarding the user's fruit and vegetable consumption. For thefield1704, theserver101 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 thefield1704 indicates that user needs to drink more or less water. For thefield1705, theserver101 calculates the user's intake of fruit and vegetable based on the user's dietary intake as entered atweb page1500. For example, Caesar salad would count towards the user's fruit and vegetable intake whereas tuna fish would not be regarded by theserver101 as forming part of the user's required fruit and vegetable intake. Theserver101 consults thedatabase110 to assess the relevance of the foods towards the fruit and vegetable intake. For example, in this embodiment thedatabase110 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 page1800,as seen by the user, that the user can use to generate a personalized training schedule. Theweb page1800 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, theweb page1800 represents dates ranging from “tomorrow” (Jan. 7, 2004) through to Jan. 13, 2004. Theweb page1800 includes afield1801 that the user can use to indicate his availability for morning training sessions, both for skating training and fitness training. Afield1802 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 theweb page1800 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 thesystem100 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]button1803 on theweb page1800. This causes theserver101 to interact with thedatabase110 to suggest a proposed training schedule for review by the user.
The proposed training schedule is devised by the[0128]server101 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 theserver101 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]server101 proposes a training schedule that concentrates primarily on improving the user's core stability score. Theserver101 also attempts, with secondary importance, to develop the user's cardiovascular score.
Although for the[0131]web page1800 at FIG. 18 the user had not selected any fitness training sessions, suppose that the user had selected four fitness training sessions. Theserver101 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 theserver101 would devote one of the five training sessions to a tertiary weakness.
Once the[0132]server101 has determined what type(s) of training are required for the training schedule, theserver101 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]server101 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.) Theserver101 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]server101 has determined a proposed training schedule for the user, theserver101 causes the user'sPC102 to display aweb page1900, as shown at FIG. 19. Theweb page1900 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 theserver101 to generate a training program that is tailored to the user. Firstly, the user uses theweb page1800 to inform theserver101 at a coarse level of the training that he can perform during the following week. Secondly, the user uses theweb page1900 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 page1900 includes afield1901 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. Thefield1901 uses color coding to represent the types of activity allocated to thefield1901. Afield1902 provides a key to the user and explains the color codes. Thefield1902 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 page1900 provides a graphical user interface that allows the user to inform theserver101 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 theserver101 knows, from the information entered by the user atweb page1800, that the user will be able to train on Jan. 11, 2004. However, theserver101 does not know the exact time that the user is available for training.
The user uses a[0139]field1903 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). Theserver101 stores the actual times (that the user will be available for training) in thedatabase110. This allows the user to consult thedatabase110 via theserver101 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 region202 of theweb page200 then, if any competitions are due to occur during the next seven days, the competition(s) are displayed in the appropriate time slots of thefield1901. As was mentioned earlier, theserver101 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]system101 allows the user to enter information regarding the injury (or injuries). FIG. 20 shows aweb page2000 that allows the user to enter injury information. Theweb page2000 includes anicon2001 that represents the front of the body (abutton2002 allows the user to select the back of the body in case the injury is at the rear of the user). The user selects theicon2001 to cause aweb page2100 to be displayed.
FIG. 21 shows the[0143]web page2100. Theweb page2100 allows the user to enter detailed information concerning the location of an injury and the severity of an injury. Anicon2101 allows the user to select a region of the body.Fields2102 and2103 allow the user to specify the exact locations and severity of injuries, respectively. A field2104 allows the user to specify the date of the injury. Theserver101 then stores this information in thedatabase110.
The[0144]field2103 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]server101 prohibits all training when proposing a training schedule for the user atweb pages1800 and1900.
A benefit of storing the injury information in the[0146]database110 is that thedatabase110 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]database110 stores information associated with each user, the coach can use theserver101 to interrogate thedatabase110, 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]server101 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,22b,22cand22dwhen assembled as shown in FIG. 22 show a block diagram2200 of some of the major structures within thedatabase110. In this embodiment, the data that comprises thedatabase110 is stored on a hard disk drive (not shown).
As can be seen, in this embodiment the[0153]database110 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 thedatabase110.
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]system100, which stores the pin_number in the table2204.
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 table2207 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 table2208 stores the update dates of core stability, strength, growth, a mood profile of the user, goals for setting by the user (see table2211), and the user's height and weight. Each time that the user enters data for these data types, theserver101 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 table2208 for his height and weight information. Whenever the user logs on to theserver101, theserver101 compares the actual calendar date to the dates specified by the table2208 for updates and, if an update is required, informs the user. The use of the table2208 increases the performance of thesystem100. This is because theserver101 only needs to check the dates in the table2208 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 theserver101, for theserver101 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 table2208, the update dates would be scattered amongst a variety of tables of thedatabase110. Such an embodiment would require more processing time to access the various tables, due to the need for theserver101 to traverse the database hierarchy. In some situations, the increased processing time would lead to unacceptable delays while the user waited for theserver101 to interrogate the various tables of thedatabase110.
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 pages500-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 pages500-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]database110 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 thedatabase110 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 table2211 stores a “psych_perf_id” which is used to relate table2211 to a table2212. The table2211 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 table2211 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 table2212 not only stores specific goals but also allows the user to enter when a specific goal has been completed. In addition, the table2212 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 table2214. Each event in the event table2214 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 table2214. 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 table2215 stores the results of an analysis that compares the user fitness rating with his goals. In effect, the table2215 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 table2216 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 table2216 includes a field “food_type_id” which is used as a key for another table, table2217. Table2217 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 thedatabase110. When a user eats a type of food or drink that is not included in the food table2217, 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 table2218 has two keys, the user_id and “custom_food_id”. The custom_food_id has the same function as the food_type_id of table2217 but is personal to the user. Thus any user can select a foodstuff in the default food table2217; 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 table2217. 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 table2218 allows users to, in effect, set up a cache for food items that they frequently consume but that are not in the table2217. Tables2217 and2218 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 table2219 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 table2219 also stores a foreign key “injury_status_id” to a table2220 and a foreign key “injury_kb_id” to table2221. Table2220 records the status of an injury and associates this with the injury_id and a rating of the severity of the injury. Table2221 stores a knowledge base that may be consulted by the user to obtain detailed information about an injury. Table2221 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 byweb page1900. The table key for table2222 is “schedule_id” which is used to distinguish the various schedules that will be generated by thesystem100. The table2222 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 intoweb page1800. 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 table2225 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 table2225 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 table2226 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 table2226 is a combination of the date, start time and user_id. The activity assessment table2226 records the actual activity of the user as opposed to the intended activity stored in table2222. The activity_id is used as a key for a table2227 and a table2228.
Table[0175]2227 is keyed by activity_id and associates the various activity_ids with descriptions of the activity. Table2228 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 table2229 records the dates of exercise and the contributions of the exercise to the user's requirements. Here, the table2229 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 table2229 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 table2230 is “fitness_assessment_score_id” which uniquely identifies each fitness assessment. Other fields in the table2230 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' mlO2/kg capability, where mlO2/kg is a measure of the users' ability to transport oxygen, measured in ml of O2, 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 mlO2/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 table2232 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.). Table2232 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 table22322. Note that the table2232 also includes the mlO2/kg expected of a user, again indexed by age and gender. Although the fitness tests do not directly measure the mlO2/kg ability of a user, this can be inferred as was explained for table2231 above and so is included in the table2232.
Description of a Second EmbodimentAt FIG. 23 there can be seen a[0180]server10 with accompanyingcomputer terminal11. Theserver10 is connected via a telecommunication network, e.g. the Internet, to remotely locatedpersonal computers12,13, and14. In the example given theserver10 has a website which can be accessed via the Internet and users of the system use web-browser software on thepersonal computers12,13 and14 to access the website hosted by theserver10.
On the[0181]server10 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]server10 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]server10 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 |
| |
|
| VO2max(mlO2/kg) | 80 |
| OBLA (% VO2max) | 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, COR
1, COR
2, COR
3 and LME. The
server10 then calculates from the input POW and weight information an aerobic power figure and from the input COR
1, COR
2 and COR
3 figures a core strength figure. Then the
server10 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 |
| |
|
| VO2max(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]
Volumerun=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=HRrest+INT*(HRmax−HRrest), where
THR=training heart rate
INT=Intensity percentage/100 (e.g.80%=0.8)
HRrest=Resting heart rate and
HRmax=Maximal heart rate (this is either available from a maximal test or can be estimated from 220−age (years))
For our athlete, theTHR=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 | BaseValue | value |
| |
|
| 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 | |
|
|
Alternative EmbodimentsThe 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]server101.
The training systems described in the first embodiment above comprised a[0208]server101 which communicated with aPC102. In alternative embodiments theserver101 may be connected to a plurality ofPCs102. Theserver101 may either be connected to any one of a number ofdifferent PCs102 or may be simultaneously connected to a plurality ofseparate PCs102. In embodiments where theserver101 is simultaneously connected todifferent PCs102 it is anticipated that eachPC102 would be used by a respective user of thesystem100.
The training system uses a[0209]PC102 to provide a graphical user interface to a Java program which controlled theserver101. ThePC102 was caused to display internet pages using a web browser. In an alternative embodiment theserver101 may communicate with dedicated software installed on thePC102. In this alternative embodiment, the dedicated software provides the graphical user interface.
The training system uses a[0210]server101 which accesses adatabase110. Communication between the user'sPC102 and theserver101 is performed using a telecommunications link. In an alternative embodiment, software is installed on thePC102 of a user who wishes to use the training system. In this alternative embodiment, the software programs thePC102 to implement thedatabase110 on the hard disk of the user's PC. An advantage of this embodiment is that thePC102 need not communicate with a remote server. However, an advantage of operating the system using acentral server101 that is used by alluser PCs102 is that improvements and upgrades may more readily be made to the system. For example, when using aserver101, 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 eachPC102 then it will be harder to update the databases as an updated database entry will need to be sent to eachPC102.
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]database110 is modified to allow long distance runners to train effectively. In such an embodiment thedatabase110 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 tables2224,2225 and2232 are modified to include predetermined skill level categories for long distance runners together with descriptions of the skill categories of long distance runners. Table2232 would also require modification to be keyed by the type of sport being performed by the user (this is because table2232 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 afirst database110 and long distance runners may use a second database. In the yet further embodiment, either acommon server101 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]server101 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 system100 described above, the presence of any injuries as entered at theweb pages2000 and2100 is used to modify the dietary assessment shown atweb page1700. 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, theserver101 is operable to use thedatabase110 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 thesystem100 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]server101 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 theserver101 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. Theserver101 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 page1900, 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]