Method and apparatus for a health phone

The present application claims the benefit of U.S. Provisional Application Ser. No. 60/795,398, filed Apr. 26, 2006.

The present invention relates to health data, and more particularly to a health phone to monitor user activity.

NTT DoCoMo, Inc. is marketing the F672i (Raku Raku Phone III) in Japan, the first mobile phone that also is a pedometer. The pedometer phone records your steps, and it also can e-mail them once a day to the address of the user's choice, or others can message the pedometer phone with a specific subject line to find out your pedometer data. Given the high rates of chronic conditions such as obesity, hypertension, diabetes and other conditions as well as broad cell phone adoption by teens in the US and Canada, adding a pedometer to cell phones will be a big public health benefit to encourage activity.

However, the NTT DoCoMo system provides very limited accountability, and no real-time data. Furthermore, there is no central data collection mechanism.

A method and apparatus providing a health phone utilizing a pedometer or accelerometer incorporated into a cellular telephone. The system is designed to receive activity data from the pedometer or accelerometer, and communicate the activity data to a remote server, the cellular telephone further designed to receive suggestions from the server, the suggestions generated based on the activity data received from the cellular telephone.

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

FIG. 1 is a block diagram of one embodiment of the network which may be used with the present invention.

FIG. 2 is a block diagram of one embodiment of the MACS system.

FIGS. 3A and 3B are exemplary sketches of the user system which may incorporate a health monitor and a mobile communications system.

FIG. 3C is a block diagram of one embodiment of the server.

FIG. 4 is a flowchart of one embodiment of utilizing the health phone system including coaching.

FIG. 5 is a flowchart of one embodiment of correlation evaluation and feedback.

FIG. 6 is a block diagram of one embodiment of the community system.

FIG. 7 is a flowchart of one embodiment of setting up competitions based on the health parameter data, to encourage a health regimen.

FIGS. 8A-F are exemplary screen shots.

The method and apparatus described uses a cellular telephone as a health phone. The health phone monitors user motion, activity and inactivity, and provides an unobtrusive and simple way of tracking key health information, such as activity level, heart rate, etc. In one embodiment, the system includes a feedback mechanism which provides the ability to remind a user after a period of inactivity to move. In one embodiment, the feedback mechanism may also suggest that a user do certain stretches or particular motions, in accordance with the user's health status. The health status includes health condition data and current activity data, as maintained on a server. In one embodiment, the activity monitoring is performed by a pedometer or accelerometer integrated into the user's mobile phone, creating a health phone.

In one embodiment, the system is a health phone with an integrated accelerometer. In one embodiment, the health phone may further include a receiver to communicate with a heart rate monitor, glucose monitor, and/or other health monitors. The heart rate monitor may be a chest strap type monitor, for example. The receiver may, in one embodiment, be a Bluetooth receiver, a wireless network receiver, a wired connection, or another type of receiving mechanism that enables the health phone to receive data from external sensors, monitors, and/or devices (SMDs). The health data, which may include the activity data and corresponding heart rate, is then sent to a central health data repository, which may reside on a remote server. The remote server may maintain cumulative data, and further provide analysis based on the data. In one embodiment, the remote server may also provide feedback to the user.

In one embodiment, the system includes an activity coach that reacts to the data from the health phone and reminds the user to maintain a certain level of activity throughout the day. In one embodiment, the activity coach also provides reminders based on the health data received through health monitors, whether coupled to the health phone or not. The user may have the option, in one embodiment, to select the message type, messaging mechanism, and messaging frequency.

One utility for the health phone—or more generally the health monitor/wireless communicator—is providing diabetes management. The data collected from the health monitor and cellular device is sent to a server. The server, in one embodiment, cross tabulates activity (measured by the activity/health monitor) versus blood glucose and insulin taken (or alternative health indicators) to have a more complete picture of what is going on with the diabetic user. It is useful for diabetics to see steps/activity level cross graphed with blood glucose levels. In one embodiment, the system can then make concrete recommendations. For example, a recommendation may be to walk another 2,000 aerobic steps to lower glucose levels to a better level. Walking a certain amount at a certain pace has a predictable effect on a person's blood glucose levels. There is some variation across different users, but the effects generally remain the same for a particular user from day to day. In one embodiment, the activity/glucose adjustment levels may be calibrated for the individual user, based on the data received from the system. As the user becomes more fit, these effects may change, but the change is gradual. In one embodiment the system utilizes the continuous data to update these correlations for the user. Similarly, a correlation may be found between blood pressure (for example from stress) and walking, resting heart rate and walking, etc.

In one embodiment, the activity monitor is a pedometer. The pedometer is a great way to measure the activity level of an everyday person. In one embodiment, in addition to being able to monitor steps via a pedometer, the accelerometer integrated into the health phone is also capable of detecting and monitoring other activities, such as bicycling, roller skating, etc. Cellular telephones are becoming more popular, and are one of the few devices that are carried constantly on the user's person, and thus are capable of providing health data such as steps (pedometer), heart rate (heart rate monitor), etc. Furthermore, by providing a community around the health data, the user receives support as well as a level of accountability unavailable with systems that do not include actual health monitor data.

In one embodiment, the system, in addition to collecting data, enables the creation of communities. Furthermore, the system is designed to encourage participation in the communities. While the user need not participate in order to receive the benefits of correlated health data and feedback, members in such communities generally encourage each other to do better. In one embodiment, the communities enable the user to compare their progress. In one embodiment, users can create peer competitions. The peer competition may be biased (i.e. handicapped like in golf), so that people of unequal health status can compete fairly. In one embodiment, each person gets an individualized “health score” based on the health data known about the person, and this health score is used to bias the competition. This enables an older fit person to fairly compete with a younger less fit person, a disabled person to compete with an able person, etc. In one embodiment, the system may create a handicapping based on the user health data in the server.

In one embodiment, in order to encourage walking, the system may enable setting up a virtual walk. A virtual walk enables users to track their walking goal, as the miles accumulate. For example, a goal may be to walk across America, or between any other start and destination. In one embodiment, the system may use third party mapping software to identify the length and steepness of the terrain, and prompt accordingly. In one embodiment, the system may further provide image-based feedback (for example showing representative images from a city or town virtually crossed by the user.

FIG. 1 is a block diagram of one embodiment of the network which may be used with the present invention. The user's mobile device 115 may be a cellular phone, a wearable computer, or any other device which is generally carried by the user and provides at least a periodic ability to establish a connection to the Internet 140 . In one embodiment, the user's mobile device 115 connects to the Internet 140 via carrier network 130 . At least one sensor, monitor, and/or device (SMD) 110 , 120 is coupled to mobile device 115 , or is part of the mobile device 115 . Additional SMDs 110 , 120 which may include various health monitors such as heart rate monitor, blood pressure monitor, blood glucose level monitor, pedometer, etc. send their data to the server 100 via user mobile device 115 , or directly through carrier network 130 or Internet 140 .

The health monitor and user device data is passed to server 100 . Server 100 , in one embodiment includes a fitness system 100 . Fitness system 100 includes, in one embodiment SIMS 150 , community system 170 , and coaching logic 180 . In one embodiment, each of the elements of the fitness system 100 may be on a separate server, or multiple servers. Alternatively, the elements may share a server or servers.

FIG. 2 is a block diagram illustrating one embodiment of a Virtual Management, Access, Control, Share (MACS) device on the SIMS server and its relationship to the actual SMD. The actual SMD 210 has an intermittent connection 215 to a server 220 . The connection 215 may be through the Internet, through a carrier network, or through other means. The server 220 may be located in the same location as the real SMD 210 .

The data receiving logic 225 receives the data from the actual SMD 210 or the user via an intermittent connection 215 . The data is stored in historical database 230 . The historical data is used by data mining engine 235 , to present virtual MACS device 250 via a reliable always-on connection 260 to various recipients 275 . In a healthcare setting for example, the recipients may include the user, healthcare providers, and family.

In one embodiment, data mining engine 235 may further interface with user alerts and rules 240 to generate notifications through intelligent notification engine 255 . Intelligent notification engine 255 can send automatic notifications to designated recipients 275 , when certain threshold or alert conditions are met. The threshold or alert conditions may include historical data, trend analysis, variance from charted trends, simple threshold, or any combination of the use of historical and current data from the actual SMD 210 , or combination of SMDs. In one embodiment, the data mining engine 235 constantly monitors the database 230 , to ensure that the alert rules and user thresholds 240 have not been triggered. Intelligent notification engine 255 can, in one embodiment, trigger a notification in an appropriate format to any designated recipient.

In one embodiment, in addition to the database 230 , data from other relevant actual SMDs may be received as well via logic 245 . For example, in health setting, in addition to the glucose meter, exercise data, medical reports, and/or other relevant conditions may be monitored. The threshold and alert rules 240 may utilize a combination of data from more than one real SMD to trigger a notification or command 270 .

FIGS. 3A and 3B are exemplary sketches of the user system which may incorporate a health monitor and a mobile communications system.

FIG. 3A is a diagram of the client system elements. Health phone 310 includes mobile telephone functionality, a pedometer or other activity monitor, and the ability to send health data to a server. In one embodiment, additional health monitoring devices 315 may be coupled via Bluetooth or other connection 320 to health phone 310 . Health phone 310 is carried by a user 305 .

In one embodiment, the user's activity is tracked by an accelerometer in the health phone 310 . In one embodiment, the accelerometer comprises a three-dimensional accelerometer. In one embodiment, the accelerometer comprises a two-dimensional accelerometer. In one embodiment, the accelerometer comprises two two-dimensional accelerometers arranged to enable detection of motion along all three axes. Alternative configurations for obtaining accelerometer data may be used.

The health phone 310 sends the activity data to SIMS server(s) 325 . If additional health monitors 315 are coupled to health phone 310 , the data from the health monitors 315 is also sent to the SIMS server(s) 325 . In one embodiment, health phone 310 sends its data via cellular network or via the Internet if it is a WAP enabled phone. In one embodiment, SIMS server 325 shares parts of the data, or analyzed data, with community 330 . Community 330 is designed to provide encouragement to the user 310 , to maintain a fitness regimen. In one embodiment, user 305 accesses community 330 on the World Wide Web, via a browser, or via health phone 310 . In one embodiment, the community 330 may also provide encouragement via email, instant messaging, or another format.

FIG. 3B is a block diagram of one embodiment of the client system. The client system includes an activity monitor 336 . In one embodiment, the activity monitor 336 is a pedometer. In one embodiment, the activity monitor 336 is an accelerometer. The accelerometer may be a one, two, or three-dimensional accelerometer. In one embodiment, if the accelerometer is one or two-dimensional there may be two or more accelerometers that are part of the activity monitor 336 . In one embodiment, the activity logic 336 , which includes activity monitor 336 and temporary data storage for the activity monitor, is separately powered by activity monitor power system 335 . The activity monitor power system 335 enables the activity monitor 336 to operate even when the client system (mobile telephone) is turned off.

The activity data from activity monitor logic 336 is transmitted to the server system via health data transmitter 340 . In one embodiment, an external health monitor interface 338 is also included in the system. The external health monitor interface 338 is designed to receive health data from external health SMDs, such as glucose meters, heart rate monitors, etc. In one embodiment, external health monitor interface 338 is a Bluetooth interface, which is configured to receive health data from external health monitors. In another embodiment, external health monitor interface 338 may be a wired interface designed to receive a physically connected device. The data received via external health monitor interface is buffered, in one embodiment, and then passed on to health data transmitter 340 .

In one embodiment, the health data is stored on the client system until health data transmitter 340 receives an acknowledgement that the data has been successfully received at the server (not shown). In one embodiment, a cyclic redundancy check (CRC) is included with the data, to ensure that the correct uncorrupted data was received by the server.

In one embodiment, the server may send feedback data to the health phone. The feedback data is received via communication logic 334 . Communication logic 334 , in one embodiment, passes feedback designed for the user to user interface 330 . Feedback data, in one embodiment, may be text, audio data, or other types of data. In one embodiment, communication logic 334 may send some of the feedback data directly to activity monitor logic 336 . For example, if the server determines that the accelerometer settings must be altered in some way, this data may be received from the server.

FIG. 3C is a block diagram of one embodiment of the server. The server receives data from the health phone via data receiving logic 355 . Data receiving logic, in one embodiment, receives data from the health phone. In one embodiment, the data may include activity data as well as other available data. In one embodiment, the health data is pedometer data, which includes time & date information in addition to the step information.

The data received is then stored as user data 360 . In one embodiment, user data is stored in a central database/repository. In one embodiment, this central database/repository includes security, so that user data is not directly accessible or modifiable.

Correlation logic 365 utilizes the data in user data store 360 to determine whether there needs to be an alert or suggestion made to the user. Alerts indicate that the user should do something right away. For example, if the health data includes glucose level data, and the trending analysis determines that the user's glucose levels will be causing a problem shortly, an alert may be sent, via alert logic 375 . The alert may indicate an action to take, or an action to stop, in order to prevent a problem. In one embodiment, alerts may be in response to data, data trends, correlations between data sets, or pre-set alert levels. For example, a user may prefer to alert a third party if certain health indications happen.

Relationship analyzer 362 determines relationships between activity data (i.e. steps taken, speed of the steps, etc.) and other health data (i.e. blood glucose level, stress level, resting heart rate). The relationship analyzer 362 uses the correlation data and user data. In one embodiment, the relationships may be multi-level, with various factors obtained from various health monitors creating a complex relationship. In one embodiment, this relationship is user-specific. In one embodiment, the relationship analyzer 362 creates and stores an adjustment relationship.

Suggestion logic 370 is designed to utilize the correlation data from correlation logic 365 and propose actions to the user. For example, the suggestion logic 370 may suggest actions to the user based on the currently received data, historical/trend data analysis, and the user's other available data. In one embodiment, the suggestion may be a multi-step process. For example, the suggestion for a blood glucose level at a certain level may be to take 2000 aerobic steps now, and eat some high fiber, low glycemic index carbohydrates in one hour. In one embodiment, one of the suggestions is to walk, when the health phone includes a pedometer. In one embodiment, the suggestion logic 370 may send out an initial multi-step suggestion, and follow-up as the user follows or fails to follow the suggestion. In one embodiment, the initial suggestion may be a single step, with follow-up suggestions sent depending on whether the user followed the initial suggestion or not.

Web interface 350 enables the user, and other authorized viewers, to view user data 360 , and adjust settings. In one embodiment, the web interface may be used to present the data to the user. FIG. 8A illustrates an exemplary screen shot showing the user's health data over time. FIG. 8D illustrates an exemplary display including the pedometer data collected, as well as goals and weight data. This type of data may be very motivational to users.

In one embodiment, the system also includes a community system 380 . The community system 380 is designed to provide a community aspect to exercise and health monitoring. The community system 380 is described in more detail below, with respect to FIG. 6 .

FIG. 4 is a flowchart of one embodiment of the client-side process. This process is active whenever the user carries the health phone (block 410 ). The health phone may receive data from other external health monitors as well. These external health monitors may include any monitors that can communicate with health phone, that are used to assess the user's current health status. For example, the health monitors may include a blood glucose monitor, a heart rate monitor, a blood pressure monitor, a blood oxygen level monitor, or any other type of health monitor. These health monitors communicate their data to the health phone, in one embodiment. (block 415 ) In another embodiment, the health monitors may communicate their data directly to the server, without going through the health phone. In that case, block 415 may be skipped.

The health data is stored temporarily by the health phone (block 420 ). In one embodiment, the health phone simply stores data received from external health monitors, and whenever it sends its own pedometer data, it packages the external health monitor data along with it. In one embodiment, the health phone stores the pedometer/internal health data as well.

The process then determines whether it is time to send data to server (block 425 ). In one embodiment, the pedometer collects data continuously. In one embodiment, health monitors also may collect data continuously. The system, however, in one embodiment, only sends data periodically. In one embodiment, data is sent at preset intervals. In one embodiment, this interval may be one minute. In another embodiment, data may be sent only when at least a preset number of steps have been taken or a preset amount of health data has been collected, or a preset amount of time has elapsed, whichever occurs first. In another embodiment, the sending interval may be set based on another factor. If it is not yet time to send the data, the process returns to block 410 to continue collecting pedometer data. If it is time to send the data, the process continues to block 430 .

In another embodiment, the data is stored in a buffer and immediately sent when received. In one embodiment, the pedometer data is stored separately by the pedometer aspect of the health phone, and only transmitted to the mobile-aspect of the health phone periodically. In one embodiment, in such a case the pedometer data is immediately forwarded when it is received by the mobile-aspect of the health phone.

The data is sent to the central server (block 430 ). In one embodiment, the data may be sent as an email, SMS, MMS, via WAP, or in another format. In one embodiment, the system awaits an acknowledgement that the data was correctly received by the server. In one embodiment, the data is erased from the health phone once the acknowledgement is received.

At block 435 , the process determines whether any instructions or alerts have been received from the server. The server may return data to the user's health phone. The instructions/alerts may be received in response to the data sent, cumulative data from the user whether received through the health phone or other sources, or other occurrences. If no alerts are received, the process returns to block 410 to continue collecting data.

If an alert is received, the process informs the user (block 440 ). In one embodiment, the system uses the standard SMS/email alerting system which is part of the health phone. Thus, the system itself need not do anything to alert the user. In one embodiment, the data received may be an adjustment to the health device, or something else that need not trigger a user alert. In that case, in one embodiment, the system does not inform the user. In another embodiment, the user is informed of the update, but the information is passed without an alert.

The process then returns to block 410 , to continue collecting data. Note that while this is described as a flowchart, these processes generally occur simultaneously. That is data is constantly collected, and whenever it is time, the data is sent. The system continuously monitors for data received from the server. The other flowcharts utilized in this application also need not be executed in a linear form.

FIG. 5 is a flowchart of one embodiment of correlation evaluation and feedback. Note that the example provided here correlates pedometer data (steps taken) with blood glucose data (blood sugar levels). However, this is merely an example, and the creation of correlation between two or more measurements would be understood by one of skill in the art. For example, heart rate over time may be correlated with blood oxygen levels or blood glucose levels. Blood pressure may be correlated to amount walked, etc. One of skill in the art would understand that there are other correlations which may be used.

At block 510 , blood glucose and pedometer data is received. In one embodiment, the pedometer data is sent periodically by the health phone. In one embodiment, the blood glucose data is also received through the health phone. In another embodiment, the blood glucose data is received through a different path. In one embodiment, blood glucose data includes data from a blood glucose monitor as well as an insulin pump, or from a user indicating how much insulin was used.

The new data is added to the user's data set. As discussed in prior application U.S. Ser. No. 11/192,549, entitled “M ONITOR , C ONTROL , A ND S HARE (MACS) SYSTEM,” incorporated herein by reference, the system maintains a central data store. This central store enables the system to not only identify long-term trends, but also determine user history, and user-specific correlations. In one embodiment, additional data regarding any medicines or materials used to affect insulin levels may be included in the user's dataset. In one embodiment, the user's food data may also be included in this data set.

At block 520 , the number of steps taken (i.e. pedometer data) is correlated with glucose levels. In one embodiment, other factors such as insulin taken, medicines taken, etc. are also included in the correlation. In one embodiment, the system continuously performs this correlation, as data is received. In one embodiment, the time of day is also taken into consideration for blood glucose levels. Generally, blood glucose levels are highest shortly after a meal. In one embodiment, meal data may be received from the user. In another embodiment, the system may determine when meals were consumed based on time-of-day data. In another embodiment, if the health phone has GPS (global positioning system) enabled, or if the pedometer data provides location information, the system may utilize this data to determine when the user eats.

At block 525 , the process determines whether the glucose levels are in the optimal range. If the glucose levels are in the optimal range, the process terminates, at block 530 . Otherwise, the process continues to block 535 .

At block 535 , the process identifies the necessary change in the glucose levels, to move them to optimal level. This may be to increase or decrease the blood glucose levels by a certain amount or percentage.

At block 540 , the process uses user data to identify necessary steps for change. The user data collected indicates the correlation between changes in level of movement, level of insulin, food consumption, and other medicines and changes in blood glucose levels.

At block 545 , the process determines the number of steps that should be taken, which would correlate with the necessary change. In one embodiment, the process takes into account a walking speed as well, in this evaluation. In one embodiment, for example, the system may know that walking 1000 aerobic steps reduces the user's blood glucose level by 2%. Therefore, the system may determine that the user should walk 2000 steps to reduce the blood glucose levels appropriately. Of course, while the pedometer-based recommendation is shown here, other recommendations—including eating something, taking medicines, performing other activities, may be recommended.

At block 550 , the suggestion alert is sent to the user, indicating steps the user should take to appropriately alter the blood glucose levels. In one embodiment, the alert is sent using the mechanism selected by the user. In one embodiment, the suggestion alert is sent to the health phone. In one embodiment, the alert-type may be different depending on the level of deviation from the acceptable glucose levels. For example, if the level of deviation indicates that there may be a medical event, the alert may be sent to third parties as well. In one embodiment the notification process described in co-pending application Ser. No. 11/192,549 may be used. The process then ends at block 530 .

FIG. 6 is a block diagram of one embodiment of the community system. The community system 380 is useful to encourage users to follow their exercise programs. There are multiple features.

Competition logic 610 administers competitions between users. Users can sign up for public competitions (i.e. visible to all users) or private competitions (i.e. visible only to those users who are invited to participate). Competitions administered by competition logic 610 may, in one embodiment, be handicapped. This enables unequal competitors to compete with each other. For example, if one of the competitors is a 10 year old, it would not be fair to compare step-for-step with a 24-year-old. Therefore, handicap logic 615 is used to generate a “fair” comparison. In one embodiment, handicap logic 615 takes into account the calculated fitness level of the user, based on the health data in the system about each user.

Competition logic 610 , in one embodiment, calculates a “conversion to standard step” mechanism. Thus, for example, for a child, 1000 steps may be equivalent to 1200 “standard steps.” Similarly, the level of exertion for “aerobic steps” may be different for an older person than for a younger person. FIG. 8F illustrates an exemplary display of a current competition. It shows the relative place of each participant in the Walk Off. FIG. 8C illustrates an exemplary display showing more information about the Walk Off, including current placement, how to catch up, etc.

Tracking logic 620 tracks how each user is doing in each competition. Award logic 625 shows the user's placements. This is shown in FIG. 8C . In one embodiment, the user's awards (i.e. final placements in various competitions) may be displayed publicly, if the user wishes. In one embodiment, current standings in on-going competitions may also be generated and displayed, in accordance with the user's preference. In one embodiment, award logic 625 may display standings in public competitions in the blogging system 650 , next to entries on the message board 680 , and in other places. In one embodiment, lower placements may be replaced by a “participant” icon. This again provides positive feedback to the user, and incentives to excel. In one embodiment, competitions may focus on “steps taken” for pedometer-type devices, length and frequency of workouts, vigorousness of workout, or other metrics.

Destination trek logic 630 enables the system to provide competitions for taking a particular trek. For example, users may decide to walk across America, climb the Rockies, walk to their home town, or select an alternative “destination” or series of destinations. In one embodiment, the starting and ending points for the trek may be arbitrarily defined by the user. Step-to-map conversion logic 635 takes the source and destination, and step size data from the user. This is used to calculate how far the user travels, using the pedometer data. FIG. 8E is an exemplary display of the trek Walk America, and the user's progress on that trek.

In one embodiment, the health phone data is used to chart progress. In one embodiment, self-reporting may be used, and the user may enter, for example, miles from a treadmill. Image logic 640 enables the destination trek logic 630 to insert images from actual location which is being virtually walked. Thus, for example, the user may set as a target walking from the Golden Gate Bridge to Coit Tower. The system may provide images along that walk for further motivation. In one embodiment, the system may also provide feedback/motivation based on the virtual locations. For example, in the Golden Gate Bridge to Coit Tower trek, the feedback may encourage the user to continue walking with messages such as “You are already at Fort Mason, that's more than half-way there!” etc.

Blog logic 650 enables the user to keep a personal web log. An exemplary web blog display is shown in FIG. 8B . In one embodiment, an existing blogging engine may be used. In one embodiment, the user may be permitted to post from a mobile device, using mobile system interface 655 . In one embodiment, the blog logic 650 may automatically post blog posts for various fitness sessions. For example, the blog logic 650 may automatically generate an entry for each workout session. In one embodiment, the entry may describe the user's workout. Again, this provides positive feedback to the user, and may encourage the formation of communities. In one embodiment, external blog link logic 660 enables the user to transmit blog entries in blog logic 650 to another blogging platform.

Favorite workout system 670 enables users to describe their favorite workouts, including fitness routines, walking paths, and other types of workouts. An exemplary favorite workout is shown in FIG. 8C . Again, this is designed to encourage community, and to encourage other users to try someone else's favorite workout. In one embodiment, the system may display these favorite workouts to users looking for new routines. In one embodiment, the system may further provide location-based filtering. For example, for a user known to be residing in Northern California, only local walks would be shown. In one embodiment, the user may further add “places I visit” or similar indications to see favorite walks elsewhere. In one embodiment, the system may receive location information from the user's mobile device, and use this information to tailor the “local walks” in the favorite workout system 670 . This may enable a visitor to an area to find a nice workout.

Message board 680 enables users to communicate in other ways. Communities are designed to encourage people to meet.

In one embodiment, message board communities may be formed by the system. For example, there may be a message board for each identified type of medical status. For example, a board may focus on people having a particular type of condition, such as Type 2 Diabetes. In one embodiment, as the system acquires data about the user's condition and health status, it recommends message boards 680 which may be useful to the user. In one embodiment, as communities are formed on the message boards, competition logic 610 recommends friendly competitions between the members of the message boards.

FIG. 7 is a flowchart of one embodiment of setting up competitions based on the health parameter data, to encourage a health regimen. At block 710 , the system receives an instruction to create a new competition. In one embodiment, a new competition is created by a user. In one embodiment, the user may name the competition arbitrarily. At block 715 , a list of participants is received. In one embodiment, the list of participants may be entered by the user. In another embodiment, the user may simply designate that the competition is open to the public. If the participant list is open to the public, in one embodiment, as each user signs up, the below steps are performed. If the list of participants is provided, the below steps may be performed immediately, or when an invited participant indicates an intention to join the competition.

At block 720 , the health data of the participants—i.e. those who have indicated an intention to participate—is retrieved. In one embodiment, this is done as each participant joins. In another embodiment, this is done for all participants at the same time, when the competition actually starts. In another embodiment, this is done for all participants at the same time, when all invited participants have indicated their intention to participate, or not participate, in the competition.

At block 725 , the process determines whether the participants are well matched. If so, the process continues to block 735 . Otherwise, at block 730 , an adjustment is created. This is referred to as handicapping. At its most basic, the adjustment may be for age and height. More complexly, the adjustment may include age, fitness level, past participation and success rate in competitions, health conditions, and any other relevant information. The adjustment is designed to ensure that each participant has an equal opportunity to win the competition. In another embodiment, this step may be skipped. In one embodiment, the user organizing the competition may select whether handicapping should be included.

Once the competition starts, the process described in blocks 735 through 755 is performed. Fitness data is received—continuously or on a periodic basis—from each of the participants, at block 735 . In one embodiment, pedometer data is received as described above. At block 740 , any handicap adjustments are applied to the fitness data, and the standings in the competition are updated. In one embodiment, the standings are always visible to the participants.

At block 745 , the process determines whether the competition is finished. If the competition is not yet finished, the process returns to block 735 , to continue receiving data from the participants.

If the competition is finished, the process continues to block 750 . At block 750 , placement information is added to the user's data. In one embodiment, the user's top 3 placements may be displayed along with his or her name/ID on message boards, blogs, and other interactions. This is designed to provide additional incentive for participation. In one embodiment, the placement information is displayed during the competition as well, to encourage people to use the network and the system. In one embodiment, any user can click update and get the latest data from all participants and see the latest results.

In one embodiment, at block 755 , awards are provided. In one embodiment, the user organizing the competition may designate awards—whether connected to the system or not. In one embodiment, for system-created competitions (i.e. all people with Type 2 diabetes, or members of a particular message board) the system may provide awards which may range from free service, additional feature availability, to cash awards or other prizes. The process then ends at block 760 .

In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.