System and method for predicting personal performance in athletic activity

Abstract

A computing system receives, from a user device, a request to generate an estimated activity profile for a user of the exercising user device. The computing system identifies route information for the exercise. The computing system generates an initial estimated heart rate of the user via a trained prediction system based on the personalized training process of the user. The computing system generates, via a prediction system of the training, a duration of a portion of the exercise based on the route information and the environmental information associated with the time and date of the exercise. The computing system generates, via a trained prediction system, a predicted heart rate of the user during exercise based on the initial estimated heart rate of the user and the generated duration. The computing system outputs an estimated activity profile corresponding to the exercise based on the predicted heart rate of the user.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. application serial number 17 / 808,806, filed on June 24, 2022, the entire contents of which are incorporated herein by reference. Technical Field

[0003] According to example embodiments, the present disclosure generally relates to systems and methods for predicting individual performance of a sporting activity. Background Art

[0004] With the popularity of wearable devices and fitness trackers, it has become commonplace for athletes and fitness enthusiasts to be able to track their workouts to identify trends or improvements in their fitness capabilities. Such devices provide users with real-time or near real-time feedback on biometric data, such as their heart rate, and other metrics, such as pace. Summary of the invention

[0005] In some embodiments, a method is disclosed herein. A computing system receives a request from a user device to generate an estimated activity profile for a user of the user device exercising. The computing system identifies route information for the exercise. The route information includes at least one data point associated with the route information. The computing system generates an initial estimated heart rate of the user for at least one data point in the route information through a trained prediction system based on the user's personalized training process. The computing system generates a duration of a portion of the exercise through the trained prediction system based on at least one data point in the route information and environmental information associated with the time and date of the exercise. The computing system generates an expected heart rate of the user during the exercise through the trained prediction system based on the user's initial estimated heart rate and the generated duration. The computing system outputs an estimated activity profile corresponding to the exercise based on the user's expected heart rate. The estimated activity profile includes the user's expected heart rate.

[0006] In some embodiments, a non-transitory computer-readable medium is disclosed herein. The non-transitory computer-readable medium includes one or more instruction sequences, which, when executed by a processor, cause a computing system to perform operations. The operation includes receiving a request from a user device by a computing system to generate an estimated activity profile for a user of a user device exercising. The operation further includes identifying route information of the exercise by the computing system. The route information includes at least one data point associated with the route information. The operation further includes generating an initial estimated heart rate of the user for at least one data point in the route information by the computing system through a trained prediction system based on the personalized training process of the user. The operation further includes generating a duration of a portion of the exercise by the computing system via the trained prediction system based on at least one data point in the route information and environmental information associated with the time and date of the exercise. The operation further includes generating an estimated heart rate of the user during the exercise by the computing system based on the initial estimated heart rate of the user and the generated duration via the trained prediction system. The operation further includes outputting an estimated activity profile corresponding to the exercise by the computing system based on the expected heart rate of the user. The estimated activity profile includes the expected heart rate of the user.

[0007] In some embodiments, a system is disclosed herein. The system includes a processor and a memory. The memory has programming instructions stored thereon, and when executed by the processor, the programming instructions cause the system to perform operations. The operation includes receiving a request from a user device to generate an estimated activity profile for a user of the user device exercising. The operation further includes identifying route information for the exercise. The route information includes at least one data point associated with the route information. The operation further includes generating an initial estimated heart rate of the user for at least one data point in the route information based on the user's personalized training process via a trained prediction system. The operation further includes generating a duration of a portion of the exercise via the trained prediction system based on at least one data point in the route information and environmental information associated with the time and date of the exercise. The operation further includes generating an expected heart rate of the user during the exercise via the trained prediction system based on the user's initial estimated heart rate and the generated duration. The operation further includes outputting an estimated activity profile corresponding to the exercise based on the user's expected heart rate. The estimated activity profile includes the user's expected heart rate. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to be able to understand the above-mentioned features of the present disclosure in detail, the present disclosure briefly summarized above may be described in more detail with reference to the embodiments, some of which are shown in the accompanying drawings. However, it should be noted that the accompanying drawings only illustrate typical embodiments of the present disclosure and are therefore not to be considered as limiting the scope thereof, as the present disclosure may allow other equally effective embodiments.

[0009] Figure 1is a block diagram illustrating an exemplary computing environment according to an example embodiment.

[0010] Figure 2A is a block diagram illustrating a preprocessing system according to an example embodiment.

[0011] Figure 2B is a diagram showing a method according to an example embodiment Figure 2A Block diagram of the validation data pipeline of the preprocessing system.

[0012] Figure 2C is a diagram showing a method according to an example embodiment Figure 2A Block diagram of the unverified data pipeline of the preprocessing system.

[0013] Figure 3A is a block diagram illustrating a training system according to an example embodiment.

[0014] Figure 3B is a block diagram illustrating a training system according to an example embodiment.

[0015] Figure 3C is a block diagram illustrating a training system according to an example embodiment.

[0016] Figure 3D is a block diagram illustrating a training system according to an example embodiment.

[0017] Figure 3E is a block diagram illustrating a training system according to an example embodiment.

[0018] Figure 3F is a block diagram illustrating a training system according to an example embodiment.

[0019] Figure 4 is a block diagram illustrating a prediction system according to an example embodiment.

[0020] Figure 5 is a flow chart illustrating a method of generating an estimated activity file for a user according to an example embodiment.

[0021] Fig. 6A is a block diagram illustrating a computing device according to an example embodiment.

[0022] Figure 6B is a block diagram illustrating a computing device according to an example embodiment.

[0023] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation. DETAILED DESCRIPTION

[0024] Assessing fitness performance is a topic of interest to athletes and coaches of all ability levels. Traditional methods of assessing fitness performance tend to focus on individual elements of performance. For example, traditional methods may focus on predicting race results from a known shorter distance, estimating maximum heart rate in relation to age, understanding the effect of treadmill incline on speed, etc. These traditional methods are limited because they fail to take a holistic, individualized view to assess each athlete's fitness.

[0025] One or more techniques described herein improve upon conventional methods by utilizing machine learning methods in which relevant metrics from an activity tracking device can be analyzed to predict the fitness performance of an activity or exercise while also controlling for multivariate effects of physical environment, climate, training load, and physiological limitations such as aging. For example, one or more techniques described herein can generate a predicted or estimated activity file for an activity or exercise. In some embodiments, the predicted or estimated activity file can be based on, for example, location coordinates associated with the activity or exercise.

[0026] Figure 1 1 is a block diagram illustrating an exemplary computing environment 100 according to an example embodiment. The computing environment 100 may include at least one or more user devices 102, a backend computing system 104, and a fitness tracking device 106 communicating via a network 105.

[0027] Network 105 can be of any suitable type, including a separate connection via the Internet, such as a cellular or Wi-Fi network. In some embodiments, network 105 can use a direct connection to connect terminals, services, and mobile devices, such as radio frequency identification (RFID), near field communication (NFC), Bluetooth, etc. TM , Bluetooth Low Energy TM (BLE), Wi-Fi TM 、ZigBee TM , Ambient Backscatter Communication (ABC) protocol, USB, WAN, or LAN. Because the information being transmitted may be personal or confidential, one or more of these types of connections may need to be encrypted or otherwise protected for security reasons. However, in some embodiments, the information being transmitted may not be very personal, and therefore, a network connection may be selected for convenience rather than security.

[0028] Network 105 may include any type of computer network arrangement for exchanging data. For example, network 105 may be the Internet, a private data network, a virtual private network using a public network, and / or other suitable connections that enable components in computing environment 100 to send and receive information between components of computing environment 100.

[0029] The user device 102 may be operated by a user. The user device 102 may represent a mobile device, a tablet computer, a desktop computer, or any computing system having the capabilities described herein. The user device 102 may communicate with the fitness tracking device 106. In some embodiments, the user device 102 may communicate with the fitness tracking device 106 via one or more wired or wireless connections, such as, but not limited to, a Bluetooth connection.

[0030] In operation, when a user utilizes the fitness tracking device 106, the fitness tracking device 106 may be configured to record the user's movements during the activity. In some embodiments, the fitness tracking device 106 may record various data and save the data in a file corresponding to the activity or exercise. In some embodiments, the various data in the file may include coordinate information (e.g., timestamp, latitude coordinates, longitude coordinates) based on the user's movements during the activity or exercise. In some embodiments, the various data in the file may further include one or more metrics associated with the exercise, such as, but not limited to, altitude, heart rate, pace, device temperature, etc. In some embodiments, one or more metrics may be associated with each set of coordinate information. For example, assuming that the activity file includes three sets of coordinates, (lat1, long1), (lat2, long2), (lat3, long3), each set of coordinates may include a set of metrics associated with it (e.g., altitude, heart rate, pace, device temperature, etc.).

[0031] In some embodiments, the activity file may take the form of a GPS Exchange Format (GPX) file type, a FIT file format, a Training Center XLM format, a Keyhole Markup Language format, or the like.

[0032] The fitness tracking device 106 may generate an activity file in one of these file formats when an activity or workout is completed.

[0033] The user device 102 may include at least an application 112. The application 112 may represent an application associated with the backend computing system 104. In some embodiments, the application 112 may be a stand-alone application associated with the backend computing system 104. In some embodiments, the application 112 may represent a web browser configured to communicate with the backend computing system 104. In some embodiments, the user device 102 may communicate over the network 105 to request a web page, for example, from a web client application server 114 of the backend computing system 104. For example, the user device 102 may be configured to execute the application 112 to access the user's estimated fitness performance generated by the backend computing system 104. For example, through the application 112, the user may access and view their estimated fitness performance generated by the backend computing system 104 for an upcoming activity or workout. Via the application 112, the user may further access and view their historical fitness performance maintained by the backend computing system 104.

[0034] Content displayed to the user device 102 may be transmitted from the web client application server 114 to the user device 102 and subsequently processed by the application 112 for display via a graphical user interface (GUI) of the user device 102 .

[0035] The backend computing system 104 may include a web client application server 114 and a fitness performance system 116. The fitness performance system 116 may be configured to plan or estimate a user's fitness performance for an upcoming activity or workout based on the user's historical activity data. For example, given the details of an upcoming workout or activity, the fitness performance system 116 may be configured to generate a predicted activity profile for the workout or activity based on learned information about the user.

[0036] The fitness performance system 116 may include a pre-processing system 120, a training system 122, and a prediction system 124. Each of the pre-processing system 120, the training system 122, and the prediction system 124 may be composed of one or more software modules. One or more software modules are a collection of codes or instructions stored on a medium (e.g., a memory of the back-end computing system 104), which represent a series of machine instructions (e.g., program code) that implement one or more algorithm steps. Such machine instructions may be actual computer code that the processor of the back-end computing system 104 interprets to implement the instructions, or alternatively, may be a higher-level encoding of instructions that is interpreted to obtain the actual computer code. One or more software modules may also include one or more hardware components. One or more aspects of the example algorithm may be performed by the hardware component (e.g., circuit) itself, rather than as a result of the instructions.

[0037] The pre-processing system 120 can be configured to process the activity records received from the user device 102 and / or the fitness tracking device 106. For example, the pre-processing system 120 can be configured to perform two byproduct collections of the activity records to be stored in the database. In some embodiments, the activity records can include post-massage activity records and training-ready activity records.

[0038] Pre-processing system 120 may be configured to generate a post-massage activity record based on raw activity data received from user device 102 and / or fitness tracking device 106. Pre-processing system 120 may store the post-massage activity record for quick retrieval by an end user who wishes to view their activity analysis via application 112.

[0039] The pre-processing system 120 may be further configured to generate training-ready activity records for use in training prediction models of the fitness performance system 116. The training-ready activity records may represent activity records that have been processed or "massaged" by the pre-processing system 120 in a manner suitable for feeding directly into model training. The training-ready activity records may prevent the fitness performance system 116 from performing duplicate calculations because the training-ready activity records may be combined as is with newer first-time activities to update or retrain the model.

[0040] The training system 122 may be configured to train the predictive model of the fitness performance system 116. In some embodiments, the training system 122 may train the predictive model based on athlete-specific data and athlete-agnostic data. In this way, the training system 122 may generate a robust set of predictive models based on the aggregated wisdom of a wider group of users or athletes.

[0041] Prediction system 124 may be configured to generate a user's predicted performance for an upcoming activity or workout based on a training process. For example, prediction system 124 may include a set of prediction models, each of which is trained to predict various performance metrics at one or more points in an activity or workout.

[0042] In some embodiments, computing environment 100 may further include one or more third-party systems 108. In some embodiments, one or more third-party systems 108 may represent various mapping systems or services, such as, but not limited to, Google Maps and Open Street Maps. In some embodiments, one or more third-party systems 108 may represent various weather services for obtaining weather or climate information for a given location.

[0043] Figure 2Ais a block diagram illustrating a pre-processing system 120 according to an example embodiment. The pre-processing system 120 may be configured to filter input activity data 202 (e.g., device activity records) in a manner suitable for training a set of predictive models. For example, the pre-processing system 120 may be configured to annotate the input activity data 202 with features relevant to performance modeling.

[0044] Due to the relative commonality of omissions and / or errors in raw activity data, pre-processing system 120 can implement a dual data massage pipeline. For example, an athlete's heart rate monitoring chest strap may come loose during training, which may render their heart rate data invalid. In another example, an inaccurate GPS signal may cause extreme drift in location. Because the manufacturer of fitness tracking device 106 processes irregular data points in a black box manner that is inconsistent at best and unmodified at worst, with serious consequences, pre-processing system 120 can clean the raw activity data before model training.

[0045] The pre-processing system 120 can pre-process or massage the raw activity data in two pipelines - a first pipeline (validation data pipeline 206) is used to support historical activity records (massage-validation), and a second pipeline (unvalidation data pipeline 208) is used to support general activities from unknown sources (massage-unvalidation) entering the prediction. In the validation data pipeline 206, the verified activities performed by the athlete can be assumed to originate from the athlete's own authentication device or through direct explicit upload to the application 112. As an output from the validation data pipeline 206, the pre-processing system 120 can generate validation massage data 210, which can be a pre-processed or massage pipeline of the raw validation data. The validation massage data 210 can be stored in an annotation database. In this way, features of interest that can be used for input into model training can also be viewed by the athlete in an isolated environment to display metrics such as distance, location, weather, location / time / duration of rest, etc.

[0046] In contrast to verified activity data, unverified activity generally does not guarantee the validity of timestamps or attribute data (eg, heart rate) and is only used in the prediction system 124. Therefore, the pre-processing system 120 can utilize the unverified data pipeline 208 to process the unverified activity data.

[0047] In operation, the import module 204 can be configured to decrypt between verified data and unverified data. If the activity data is uploaded directly from the athlete's own authentication device, or is explicitly declared as the athlete's own activity through manual file upload, the activity data can be considered verified data. Unverified data may refer to all other activities that have not been verified by the athlete. Although the verification data can be used to train various prediction models, the unverified data can only be used for massage activities for prediction. Based on this determination, the import module 204 can input a subset of the verification data into the verification data pipeline 206 to generate the verification massage data 210. Similarly, the import module 204 can further input a subset of the unverified data into the unverified data pipeline 208 to generate the unverified massage data 212.

[0048] The import module 204 can be configured to receive or import raw activity data from the fitness tracking device 106 and / or the user device 102. Based on the raw activity data, the import module 204 can be configured to identify core features. The core features can include, but are not limited to, timestamp, latitude, longitude, altitude, heart rate, pace, and device temperature. Although the raw activity data may include additional attributes, such as but not limited to device information, activity name, activity description, and exercise type, the import module 204 can store these additional attributes as metadata for additional activity context when available. The latitude, longitude, and altitude can be used downstream to construct a geo-located polyline to represent the path of travel of the activity.

[0049] In some embodiments, the import module 204 can be configured to generate secondary features from the core equipment features. Exemplary secondary features can include, but are not limited to, the athlete's altitude ascent and descent, i.e., vertical movement, trajectory relative to true north, relative trajectory changes between location points, and gait transitions, such as a transition from walking to running (or running to walking).

[0050] For example, suppose an athlete is running on a flat road, wearing a barometer-enabled smartwatch to record the activity. Due to the relatively sensitive nature of a barometer's air pressure measurement, minute centimeter-range changes are discernible when the device is positioned up and down on the wrist, stretched overhead, or hovering near the ground while lacing shoes. With this in mind, the ingestion module 204 can utilize developer-defined "thresholds." For example, the developer might specify that a two-meter climb needs to occur continuously over a ten-meter distance before a two-meter climb is added to the total elevation gain.

[0051] For example, consider the first altitude measurement as a golden reference point, from which the upper and lower control limits (UCL and LCL) can be determined by fixed meters derived from experience. As long as the altitude measurement remains within these limits, the vertical offset rise and fall will be considered zero. However, once one of the two thresholds is exceeded, such as in the ascending transition in the case of UCL and the descending transition in the case of LCL, the introduction module 204 can perform a buffered lookback to find the leading transition point where the rise or fall begins. The introduction module 204 can mark the leading transition point as a new reference point. If the introduction module 204 fails to find the location where the change of direction begins in the buffered lookback, the introduction module 204 can regard the nearest point as a new reference. In a given flat, ascending or descending area, the relative change relative to the reference point can be considered as a vertical athlete movement. In addition, if the ascending or descending area can transition to an area with a slope steepness lower than the near-horizontal threshold, the introduction module 204 can reset the area back to flat.

[0052] This approach may not be limited to a microscopic scale of a few meters (i.e., variable position of the recording device). Instead, the introduction module 204 may apply the same approach at a macroscopic scale to gain an understanding of the peaks and valleys along the active route where the UCL and LCL are set at a larger range of meters. Not only is this useful as a model training input feature, since athletes are more likely to rest at peaks rather than downhill, but it also makes the relative prominence between the previous peak / valley and the next valley / peak quantifiable. In other words, the athlete's patterns regarding effort, rest, etc., may be reflected in the prominence of the climb, the relative percentage of completion along the way, the final high point elevation, and how steep it is.

[0053] Vertical movement relative to the horizontal plane may result in a variable energy expenditure, called metabolic value (MC), which is primarily affected by gravity and secondarily by gait. To this extent, the decomposition of the horizontal distance traveled during each respective ascent and descent is carried forward so that the MC can be calculated with the downstream points aggregated.

[0054] In some embodiments, the introduction module 204 can be further configured to generate derived features. The introduction module 204 can generate derived features based on the core device features and the secondary features. The derived features can be roughly divided into subsets related to heart rate, rest duration, sun altitude and position (daytime, nighttime, sunrise, etc.), speed, and slope. In addition, the derived features can include a cumulative sum between the three feature sets (e.g., the total horizontal distance traveled so far).

[0055] Figure 2B2 is a block diagram illustrating the validation data pipeline 206 in greater detail according to an example embodiment. As shown, the validation data pipeline 206 may include a number of operations performed by the pre-processing system 120.

[0056] In box 240, the pre-processing system 120 can remove outliers from the activity data. Often, sensors are prone to erroneous measurements. The pre-processing system 120 can identify outliers from a variety of data, such as, but not limited to, GPS location data, altitude data, speed data, and heart rate data. In some embodiments, if the pre-processing system 120 determines that a feature is found to be an outlier at a particular timestamp point, the pre-processing system 120 can clear the entire data set associated with that point from the activity record. In some embodiments, an exception to this rule may occur when only the HR feature is found to be an outlier. In such an embodiment, the pre-processing system 120 can mask the HR feature with a null value instead of clearing the entire data set associated with that point.

[0057] The purpose of removing all outliers is to reduce the impact on the rest of the live data, since there is no meaningful way to compute an effective replacement value. The bar used for outlier identification can be kept slightly conservative to avoid over-removal, and downstream filtering in later stages is expected to smooth out the remaining wrinkles.

[0058] Regarding location outliers, the pre-processing system 120 can be configured to remove outliers in the horizontal and vertical planes. The pre-processing system 120 can identify clusters of outlier locations, where the locations deviate significantly in location and / or distance from previous and subsequent points of the cluster, and where the total activity distance will be shortened due to their removal. In some embodiments, the pre-processing system 120 can use a DBSCAN (DBSCAN) clustering algorithm to identify clusters.

[0059] Regarding speed outliers, the pre-processing system 120 can calculate speed outliers by normalizing the passing speed Poisson distribution through the Yeo-Johnson power transform. The pre-processing system 120 can then generate a surrogate speed by dividing the horizontal distance by the sum of the passing time and the given ε value. The pre-processing system 120 can then flag any surrogate speeds greater than the outlier for removal. The pre-processing system 120 can use slower surrogate speeds as a selection criterion because points captured at low second intervals are inherently variable and will result in over-removal.

[0060] With respect to heart rate outliers, heart rate monitoring devices are often susceptible to loss of wireless connectivity and electrode contact, resulting in lost data points, sudden drops in measurements, or HR being locked at the last measured value until the activity ends. In some embodiments, optical heart rate devices may be sensitive to light pollution and may enter a lock phase at the athlete's running pace, which may result in abnormally high values, or erroneously locked values ​​for long periods of time. The pre-processing system 120 may identify clusters of locked values ​​where a measurement remains constant over a minimum number of consecutive samples. In some embodiments, the pre-processing system 120 may use a hierarchical DBSCAN (HDBSCAN) clustering algorithm to identify clusters.

[0061] At block 242, the pre-processing system 120 may smooth the activity data after removing outliers. For example, while it is generally desirable that outlier removal prunes most instances of suspicious points from the activity record, the pre-processing system 120 may perform a filtering process to eliminate smaller defects associated with measurement variability (i.e., noise). However, in contrast to outlier removal, during the smoothing process, the pre-processing system 120 may replace existing values ​​of features with new values ​​without completely removing data points. For example, the pre-processing system 120 may use a Kalman filter to smooth the activity data.

[0062] In box 244, preprocessing system 120 can identify the resting position and resting duration of a given athlete. For example, preprocessing system 120 can use clustering technology, wherein, when the athlete rests (that is, does not move), the group of continuous time stamp points is clustered together. This clustering can be used to distinguish the active elapsed (that is, wall clock) time from the potential shorter duration of movement time, which can be used as an indicator of effort. In certain embodiments, preprocessing system 120 can use DBSCAN (DBSCAN) clustering algorithm or inertial measurement unit (IMU) to identify clustering.

[0063] At block 246, the pre-processing system 120 can create a geographic location representation of the activity data by creating a buffer polygon that contains all location points, e.g., within one hundred meters of the activity. This representation can be used as the region extent of the annotation. For example, if the activity is completely contained within New York City's Central Park, the fitness performance system 116 should only download road network maps from the adjacent area, plus an additional buffer around the adjacent area to account for errors in GPS data or map accuracy.

[0064] At block 248, the pre-processing system 120 may annotate the geographic location representation of the activity data. The annotation process may include road and trail network annotations, point of interest annotations, and climate annotations.

[0065] Regarding road and trail network annotations, road and trail networks may be a useful source of activity metadata. The pre-processing system 120 can be configured to store road and trail networks in a graph, represented by a collection of nodes (vertices / intersections) and edges (node ​​pairs). These graphs can not only save attributes about surface conditions (e.g., paved / unpaved) that indicate how fast an athlete can move, but also describe the complexity of the surrounding environment, and thus where and how long an athlete can rest voluntarily or involuntarily. However, unlike vehicle travel, which is mostly linear in direction, human-driven activities may appear relatively unstable in comparison, so a series of inferences about the network are required to assign correct use. The inferred feature set tells the surface type (e.g., road vs. trail), road intersections (e.g., traffic signals), trail intersections, and transition nodes between surfaces (e.g., changing from a paved street to a trail). In some embodiments, the pre-processing system 120 can capture the type of each intersection and a globally unique identifier for each intersection.

[0066] Exemplary paved annotations may include, but are not limited to, paved, asphalt, sealcoated, concrete, concrete driveway, concrete slab, paving stone, block paving, uncut cobblestone, cobblestone, metal, wood, etc. Exemplary unpaved annotations may include, but are not limited to, unpaved, compacted, fine gravel, gravel, rock, cobblestone, ground, dirt, mud, grass, pavers, mud, sand, wood chips, salt, etc.

[0067] Points of interest (POI) annotations can identify locations where activity records are close to man-made landmarks or natural features. The presence of these POIs may have properties related to the athlete's speed or rest, and may particularly be the locations of unusually long rest stops.

[0068] Climate annotations can be used to convert weather-related environmental conditions to corresponding activity records. In some embodiments, the pre-processing system 120 can adjust the climate annotations for altitude. In some embodiments, to generate climate annotations, the pre-processing system 120 can utilize one or more third-party systems 108 to obtain climate metadata. In some embodiments, the pre-processing system 120 can utilize device records (e.g., fitness tracking device 106) to obtain temperature data. Exemplary climate annotations can consider one or more of temperature, humidity, altitude, wind speed, air quality, snow accumulation, etc.

[0069] As output, the pre-processing system 120 can generate validation massage data 210 , which can be processed and annotated with information for training a predictive model.

[0070] Figure 2Cis a block diagram illustrating the unverified data pipeline 208 in greater detail according to an example embodiment. As shown, the unverified data pipeline 208 may include a number of operations performed by the pre-processing system 120.

[0071] At block 260, the pre-processing system 120 may remove athlete-specific metrics from the unverified activity data. For example, the pre-processing system may force athlete-specific features (e.g., HR, pace, etc.) to null values ​​to avoid any possibility of these attributes contaminating the prediction seed conditions or confusing the user. Such a process is performed because it may not be practical to guarantee the source of the activity. For example, the activity data may be generated by different individuals.

[0072] At box 262, the pre-processing system 120 can set the athlete's speed for the activity data. For example, as described above, the pre-processing system 120 can override the activity speed in the massage unverified pipeline 208 to provide a consistent set of time-related features for the prediction. Routes drawn on mapping services such as GaiaGPS or AllTrails often have inconsistent timestamps or no timestamps at all. The pre-processing system 120 can initialize the speed to a reasonable value because other features, such as time of day and weather conditions, may depend on the athlete's speed. In some embodiments, the pre-processing system 120 can set the normal walking speed of an adult (e.g., 1.4m / s) as the initial condition. This speed setting can allow for faster convergence of activity predictions. Because most activities are completed in a short period of time, less than a day, the initial conditions may not cause the prediction to differ greatly from the actual behavior.

[0073] At block 264, the pre-processing system 120 may remove outliers from the activity data. Often, sensors are prone to erroneous measurements. The pre-processing system 120 may identify outliers from a variety of data, such as, but not limited to, GPS location data, altitude data, etc. Unlike the validation data pipeline 206, the pre-processing system 120 may not remove speed outliers or heart rate outliers from the activity data.

[0074] In some embodiments, if the pre-processing system 120 determines that a feature is found to be an outlier at a particular timestamp point, the pre-processing system 120 may purge the entire data set associated with that point from the activity record.

[0075] The purpose of removing all outliers is to reduce the impact on the rest of the live data, since there is no meaningful way to compute an effective replacement value. The bar used for outlier identification can be kept slightly conservative to avoid over-removal, and downstream filtering in later stages is expected to smooth out the remaining wrinkles.

[0076] Regarding position outliers, the pre-processing system 120 may be configured to remove outliers in both the horizontal and vertical planes.

[0077] At step 266, the pre-processing system 120 may break up excess distances in the activity data into smaller segments. For example, point-to-point distances may be limited to the maximum distance in the massage unverified pipeline 208. This is done to ensure that downstream inputs to activity predictions do not exceed the distance representation range during model training, as this may make predictions less reliable. Therefore, any single measurement that exceeds a predetermined maximum distance may be broken into n equally spaced straight line segments. This situation is common in mapped activity routes, as providers of these services typically simplify the geometry of the routes as much as possible to reduce the number of points and, in turn, their memory footprint.

[0078] When a single point is segmented into multiple points, the pre-processing system 120 can linearly interpolate the latitude, longitude, and altitude features along the segment. Any other features such as HR can remain unchanged because it is not known what the actual value should be relative to the segmentation location, so the assumption is invalid.

[0079] Such a process may not be part of the massage validation pipeline 206 because excessive point-to-point distances in an athlete's activity may generally be attributed to some form of measurement error, long stretches of unmeasured locations (e.g., tunnels), or the athlete pausing their activity and forgetting to continue until they have traveled a distance. Due to the low resolution of the per-meter traveled data, this data may not be useful for training a predictive model. Keeping the point-to-point distances constant in the massage validation pipeline 206 may allow statistical analysis to annotate them as outliers in box 248 of the validation data pipeline 206.

[0080] At block 268, the pre-processing system 120 may smooth the activity data after removing outliers. For example, while it is generally desirable that outlier removal prunes most instances of suspicious points from the activity record, the pre-processing system 120 may perform a filtering process to eliminate smaller defects associated with measurement variability (i.e., noise). However, in contrast to outlier removal, during the smoothing process, the pre-processing system 120 may replace existing values ​​of features with new values ​​without completely removing data points. For example, the pre-processing system 120 may use a Kalman filter to smooth the activity data.

[0081] At block 270, the pre-processing system 120 may identify a resting position and resting duration for a given athlete. For example, the pre-processing system 120 may use a clustering technique in which groups of consecutive time stamp points are clustered together when the athlete is resting (i.e., not moving). Such clustering may be used to distinguish between elapsed (i.e., wall clock) time of activity and movement time, which may be used as an indicator of effort.

[0082] At block 272 , the pre-processing system 120 may create a geo-location representation of the activity data.

[0083] At block 274, the pre-processing system 120 may annotate the geographic location representation of the activity data. The annotation process may include road and trail network annotations, point of interest annotations, and climate annotations.

[0084] Regarding road and trail network annotations, road and trail networks may be a useful source of activity metadata. The pre-processing system 120 can be configured to store road and trail networks in a graph, represented by a collection of nodes (vertices / intersections) and edges (node ​​pairs). These graphs can not only save attributes about surface conditions (e.g., paved / unpaved) that indicate how fast an athlete can move, but also describe the complexity of the surrounding environment, and thus where and how long an athlete can rest voluntarily or involuntarily. However, unlike vehicle travel, which is mostly linear in direction, human-driven activities may appear relatively unstable in comparison, so a series of inferences about the network are required to assign correct use. The inferred feature set tells the surface type (e.g., road vs. trail), road intersections (e.g., traffic signals), trail intersections, and transition nodes between surfaces (e.g., changing from a paved street to a trail). In some embodiments, the pre-processing system 120 can capture the type of each intersection and a globally unique identifier for each intersection.

[0085] Exemplary paved annotations may include, but are not limited to, paved, asphalt, sealcoated, concrete, concrete driveway, concrete slab, paving stone, block paving, uncut cobblestone, cobblestone, metal, wood, etc. Exemplary unpaved annotations may include, but are not limited to, unpaved, compacted, fine gravel, gravel, rock, cobblestone, ground, dirt, mud, grass, pavers, mud, sand, wood chips, salt, etc.

[0086] Points of interest (POI) annotations can identify locations where activity records are close to man-made landmarks or natural features. The presence of these POIs may have properties related to the athlete's speed or rest, and may particularly be the locations of unusually long rest stops.

[0087] Climate annotations can be used to convert weather-related environmental conditions to corresponding activity records. In some embodiments, the pre-processing system 120 can adjust the climate annotations for altitude. In some embodiments, to generate climate annotations, the pre-processing system 120 can utilize one or more third-party systems 108 to obtain climate metadata. In some embodiments, the pre-processing system 120 can utilize device records (e.g., fitness tracking device 106) to obtain temperature data. Exemplary climate annotations can consider one or more of temperature, humidity, altitude, wind speed, air quality, snow accumulation, etc.

[0088] As an output, the pre-processing system 120 can generate unverified massage data 212 , which can be processed and annotated for use as input to a predictive model.

[0089] Figures 3A-3F is a block diagram illustrating training system 122 in more detail according to an example embodiment. Figures 3A-3F As shown, six separate performance models can be created during the training pipeline. The six separate performance models may include a duration model 308, a heart rate (HR) model 318, a maximum HR (max HR) model 328, a typical HR model 338, a minimum HR (min HR) model 348, and a seed HR model 358. The duration model 308, the HR model 318, and the seed HR model 358 can be used by the prediction system 124 to make activity predictions when the expected effort level is known. When depicting a range of potential efforts, the maximum HR model 328, the typical HR model 338, and the minimum HR model 348 can be used.

[0090] The training system 122 can generally include a pre-processing module 302. The pre-processing module 302 can be configured to perform one or more pre-processing operations on the output data from the validation massage pipeline 206.

[0091] In some embodiments, the pre-processing module 302 can be configured to simplify the data from the validation data pipeline. For example, the pre-processing module 302 can remove the "wiggle" common in the validation massage data 210 so that the validation massage data 210 looks fairly close to a mapped activity characterized by straighter lines. This crude simplification is a balancing act because the more simplified the activity, the more difficult it is to train a model to distinguish between conditions that are perceptible to the athlete.

[0092] In some embodiments, the preprocessing module 302 can be configured to compress the data. The preprocessing module 302 can compress the data using one or more compression methods. In some embodiments, the preprocessing module 302 can assign points to groups of variable distances based on a Gaussian distribution with a given target mean and standard deviation. In some embodiments, the preprocessing module 302 can assign points to groups of variable distances based on a random distribution between a minimum and maximum distance. Due to the non-uniformity of the individual points, compression is not meant to produce an exact target distance, but rather to target as close a target distance as possible without violating the minimum and maximum criteria.

[0093] The rationale for using the random distance compression method during the model training phase is to reduce the likelihood of overfitting the model. In the extreme case of overfitting, the model will provide near-perfect predictions for the data it was trained on, but poor predictions for any slight deviations, even for feature values ​​within the training range. The second rationale is to enable dataset augmentation, which is the practice of modifying the same data in different ways to enhance the diversity of feature inputs (i.e., increasing the size of the sample population). This practice is common in image processing applications, using complex networks (CNNs) to increase the number of unique training samples. The pre-processing module 302 can achieve a similar effect of increasing the number of unique training samples by compressing the activity records into multiple permutations, each under its own grouped distance target. The pre-processing module 302 can discard any duplicate points that may exist.

[0094] A beneficial side effect of compression is that it significantly reduces the number of points, which in turn translates into a reduced memory footprint and relaxes the computational requirements for both model training and model serving (i.e. predictions). Additionally, compression increases the probability that a point sent to training will have a non-zero rest duration, which in turn brings more general context to when and why this happens.

[0095] In certain embodiments, pre-processing module 302 can be configured to supplement the activity record of athlete if the activity record set can be used for training point (for example, small sample size) or in narrow characterization scope (for example, there is no diversity in the sample population) is not enough.In certain embodiments, in order to supplement the activity record of athlete, pre-processing module 302 can use the training activity record of pre-compression from other athletes.In certain embodiments, in order to supplement the activity record of athlete, pre-processing module 302 can gather the training activity record of other athletes.For example, pre-processing module 302 can identify one or more athletes similar to target athlete based on the combination of sex, age and fitness level.In certain embodiments, pre-processing module 302 can fuzzy the data points belonging to other athletes.

[0096] In some embodiments, the pre-processing module 302 can further annotate outliers in the data set. As those skilled in the art will appreciate, points hidden in the data corpus that will be fed into the model training are certainly not representative of actual performance and should therefore be removed from consideration. To identify outliers, the pre-processing module 302 can be configured to utilize various methods to identify statistical outliers.

[0097] After preprocessing the data, the training modules 304-354 can be configured to train their respective machine learning models 306-356 to generate optimized predictive models for deployment.

[0098] refer to Figure 3A , the training module 304 can be configured to train the machine learning model 306 to generate the duration model 308. In some embodiments, the machine learning model 306 can represent a deep neural network regression architecture. As will be appreciated by those skilled in the art, although the machine learning model 306 can represent a deep neural network regression architecture, other more complex architecture types can also be used. For example, in some embodiments, the machine learning model 306 can represent a long short-term memory (LSTM) variant of a recurrent neural network because it is able to embed feedback states into a deep neural network, thereby allowing the network to learn from past long-term dependencies when making future predictions.

[0099] In some embodiments, such as when the machine learning model 306 represents a deep neural network regression architecture, the machine learning model 306 may include at least two hidden layers.

[0100] To train the machine learning model 306, the training module 304 may divide the dataset into three random groups: training, validation, and testing.

[0101] In some embodiments, the training module 304 can use the training group to iteratively fit batches of features to their respective outputs. In some embodiments, the training module 304 can use the validation group to independently test the goodness of fit between each of these iterations (epochs). In some embodiments, the training module 304 and the test group are completely unknown to the fitting process and are used to test the generalizability of the complete model. In some embodiments, the data set can be randomized before segmentation to prevent the machine learning model 306 from learning consecutive similar points.

[0102] The train-val-test process can allow for stratification of one or more explicitly requested features, dividing them equally into three groups based on their ratio relative to the entire sample population. For example, each activity (i.e., a unique start timestamp) can be stratified so that an equal portion of its points can be assigned to the three groups, reducing the likelihood that an activity containing many points will overwhelm an activity with a small number of points. For example, combining multiple data records associated with an ultramarathon with a short, nearby run would present a needle-in-a-haystack scenario. The training module 304 can perform a similar process to ensure equal distribution of heart rate and exercise / non-exercise ratios. These stratifications can effectively enhance the diversity of training.

[0103] In some embodiments, in addition to or instead of stratification, a more targeted segmentation method called oversampling can be used. Oversampling separates a specific range of feature values ​​into their own segmentation process and then randomly combines their train-val-test groups together.

[0104] The training module 304 can be configured to train the machine learning model 306 to generate activity time (e.g., exercise time + recovery time) and exercise time based on, for example, heart rate data. In some embodiments, other input data may include, but is not limited to, information about the route corresponding to the activity, climate conditions when the activity is performed, athlete information, etc. In some embodiments, the machine learning model 306 can implement an architecture of two dense node layers with a dropout layer between the two dense node layers to reduce overtraining.

[0105] The training module 304 can utilize a custom loss function that addresses the fundamental problem of multi-output regression modeling, which may occur when the distributions of the outputs are significantly different. Among them, the loss of one output may be higher than another, resulting in more time being spent optimizing the higher loss at the expense of the lower loss. Although the movement time may be limited to the inverse of the minimum human speed, the activity time may be at near zero speed, converted to hours per hundred meters of distance. Therefore, if a standard loss function like mean squared error is used, or in this case, a more appropriate Poisson is used, then the training optimization will inevitably be biased towards activity time.

[0106] The custom loss function can work by first applying the Yeo-Johnson power transform to the true and predicted values ​​of each output, thereby bringing each individual distribution into closer alignment. The Yeo-Johnson parameters can be pre-defined during training dataset creation. The normalized distributions can then be fed into two standard loss functions, e.g., two of Huber, mean absolute error, mean squared error, and / or Poisson. The training module 304 can return the average of the two loss functions as a representative loss metric, resulting in a clearer balance of typical scenarios and tail optimization.

[0107] After training, the training module 304 can output a fully trained duration model 308 that is optimized to generate activity times and movement times.

[0108] refer to Figure 3B , the training module 314 can be configured to train the machine learning model 316 to generate the HR model 318. In some embodiments, the machine learning model 316 can have a combination of the above Figure 3A The machine learning model 316 may have a similar architecture to the machine learning model 306 discussed above. In some embodiments, the machine learning model 316 may include an architecture of two dense node layers with a dropout layer between the two dense node layers to reduce the risk of overtraining. The training module 314 may utilize a standard mean square error (MSE) loss during training.

[0109] The training module 314 may be configured to train the machine learning model 316 to generate the athlete's heart rate and exercise heart rate at various points in the activity based on one or more of the activity time, exercise time, accumulated rest time, heart rate at previous points, etc. In some embodiments, other input data may include, but is not limited to, information about the route corresponding to the activity, climate conditions when performing the activity, athlete information, etc.

[0110] After training, the training module 314 may output a fully trained HR model 318 that is optimized to generate the athlete's heart rate and exertion heart rate at various points in the activity.

[0111] refer to Figure 3C , the training module 324 can be configured to train the machine learning model 326 to generate the maximum HR model 328. In some embodiments, the machine learning model 316 can have a combination of the above Figure 3A The machine learning model 306 discussed above may have a similar architecture. For example, the machine learning model 306 may include an architecture of a single dense node layer to implement a nonlinear continuous function. The training module 324 may utilize a special type of quantile-based loss function during training, called PinballLoss.

[0112] The training module 324 can be configured to train the machine learning model 326 to generate the athlete's maximum heart rate at various points in the activity based on the time and environmental characteristics of the activity. In some embodiments, other input data can include, but is not limited to, information about the route corresponding to the activity, climate conditions when performing the activity, athlete information, etc.

[0113] After training, the training module 324 may output a fully trained maximum HR model 328 that is optimized to produce the athlete's maximum heart rate at various points in the activity.

[0114] refer to Figure 3D , the training module 334 can be configured to train the machine learning model 336 to generate a typical HR model 338. In some embodiments, the machine learning model 336 can have a combination of the above Figure 3A The machine learning model 306 discussed above may have a similar architecture. For example, the machine learning model 336 may implement an architecture of a single dense node layer to implement a nonlinear continuous function. The training module 334 may use a custom loss function that transforms the predicted value and the actual value through the Yeo-Johnson transform and then returns the Huber loss.

[0115] The training module 334 can be configured to train the machine learning model 336 to generate the heart rate and exercise heart rate of the athlete at various points in the activity based on the time and environmental characteristics of the activity. In some embodiments, other input data may include, but is not limited to, information about the route corresponding to the activity, climatic conditions when performing the activity, athlete information, etc.

[0116] After training, the training module 334 may output a fully trained typical HR model 338 that is optimized to generate the athlete's heart rate and exercise heart rate at various points in the activity.

[0117] refer to Figure 3E , the training module 344 can be configured to train the machine learning model 346 to generate a minimum HR model 348. In some embodiments, the machine learning model 346 can have a combination of the above Figure 3A The machine learning model 306 discussed above may have a similar architecture. For example, the machine learning model 346 may implement an architecture of a single dense node layer to implement nonlinear continuous functions. The training module 344 may utilize a special type of quantile-based loss function during training, called PinballLoss.

[0118] The training module 344 can be configured to train the machine learning model 346 to generate the athlete's minimum rhythm at various points in the activity based on time and environmental characteristics. In some embodiments, other input data can include, but is not limited to, information about the route corresponding to the activity, weather conditions when performing the activity, athlete information, etc.

[0119] After training, the training module 344 may output a fully trained minimum HR model 348 that is optimized to produce the athlete's minimum heart rates at different points in the activity.

[0120] refer to Figure 3F , the training module 354 can be configured to train the machine learning model 356 to generate a seed HR model 358. In some embodiments, the machine learning model 356 can have a combination of the above Figure 3A The machine learning model 306 discussed above may have a similar architecture. For example, the machine learning model 356 may implement an architecture with two dense node layers with a dropout layer between the two dense node layers to reduce the risk of overtraining. The training module 354 may use a custom loss function that transforms the predicted value and the actual value through the Yeo-Johnson transform and then returns the Huber loss.

[0121] The training module 354 may be configured to train the machine learning model 356 to generate the heart rate and exercise heart rate of the athlete at various points in the activity based at least on the target average HR (i.e., effort level) of the activity. In some embodiments, other input data may include, but is not limited to, information about the route corresponding to the activity, weather conditions when performing the activity, athlete information, etc.

[0122] After training, the training module 354 can output a fully trained seed HR model 358 that is optimized to generate the athlete's heart rate and exercise heart rate. The seed HR model 358 can be the first model used in activity prediction to set the initial HR value at each point of the activity. The seed HR model 358 can be optimized to tease out the nuances of effort changes at specific points throughout the activity (e.g., the increase in effort when transitioning from a flat slope to an uphill climb, or when cool morning weather turns to hot midday).

[0123] Figure 4 4 is a block diagram illustrating the prediction system 124 in more detail according to an example embodiment. As shown, the six models created by the training system 122 can be integrated or assembled into the prediction model 412 to generate activity predictions. For example, as shown, the prediction system 124 can include the duration model 308, the HR model 318, the maximum HR model 328, the typical HR model 338, the minimum HR model 348, and the seed HR model 358.

[0124] In some embodiments, only a subset of the prediction models 412 may be used to generate activity predictions. For example, at a minimum, the prediction system 124 may generate activity predictions using the duration model 308, the HR model 318, and the seed HR model 358. In some embodiments, the prediction system 124 may further use the maximum HR model 328, the typical HR model 338, and the minimum HR model 348 to determine a range of potential heart rate efforts.

[0125] In some embodiments, when a request to generate an activity prediction for a user comes from a user device 102, the pre-processing module 402 may receive the request. In some embodiments, the request may include details of the activity or workout. For example, the user device 102 may provide the pre-processing module 402 with route information for an upcoming activity or workout. In some embodiments, the pre-processing module 402 may receive the details of the route information directly from the user device 102. In some embodiments, the pre-processing module 402 may retrieve the details of the route information from one or more third-party systems 108, such as Open Street Maps, Google Maps, etc.

[0126] In some embodiments, the request may further include a time and date for the upcoming workout. Pre-processing module 402 may communicate with one or more third-party systems 108 to receive or retrieve climate information for a suggested time and date for the upcoming workout.

[0127] In some embodiments, the preprocessing module 402 may perform one or more preprocessing operations before providing the input data to the prediction model. For example, the preprocessing module 402 may perform a simplification and / or compression process to prepare the data for input to the prediction model. In some embodiments, the simplification process and / or compression process may be similar to the above combined Figure 3A The simplification and compression processes discussed.

[0128] In the case where the user's effort level is unknown, the maximum HR model 328, typical HR model 338, and minimum HR model 348 can be used to describe the activities. Such a process can result in a set of predicted activities being anchored by minimum effort and maximum effort, with the user's typical effort falling somewhere between the minimum effort and maximum effort. Based on the generated maximum effort, minimum effort, and typical effort, the prediction system 124 can use the duration model 308, HR model 318, and seed HR model 358 to generate a set of hierarchical activity predictions for the user. However, if the user's effort level is known or provided to the prediction system 124, the prediction system 124 can use the duration model 308, HR model 318, and seed HR model 358 without the maximum HR model 328, typical HR model 338, and minimum HR model 348.

[0129] The prediction system 124 can be configured to generate multi-point predictions and single-point predictions using the prediction model. The difference between multi-point predictions and single-point predictions is that chained multi-point activities can refresh their timestamps and derived features before returning to the activity because these features are used to guide the next iteration of the prediction. In contrast, single-point predictions may not be able to refresh these features because of the lack of accumulated point-to-point context.

[0130] As an output, the prediction system 124 can generate a predicted activity profile for the upcoming activity. The predicted activity profile can be similar to the actual activity profile generated by the fitness tracking device 106. For example, at each point in the predicted activity profile, the prediction system 124 can generate a set of metrics, such as duration, heart rate, pace, etc. In this way, an estimated activity profile can be provided to the user based on the upcoming workout.

[0131] Figure 5 is a flow chart illustrating a method 500 of generating an estimated activity profile for a user according to an example embodiment. The method 500 may begin at step 502 .

[0132] In step 502, the backend computing system 104 may receive a request from the user device 102 to generate an estimated activity profile for an upcoming activity or workout for the user. In some embodiments, the request may include an indication of an activity route. In some embodiments, the request may include an estimated date and time for the upcoming activity or workout. In some embodiments, the request may include a target effort level for the user. For example, the user may indicate a target heart rate for their activity or workout.

[0133] At step 504, backend computing system 104 may retrieve information from one or more third-party systems 108 based on the request. In some embodiments, based on the request, forecasting system 124 may interface with one or more mapping systems to retrieve route information for the workout or activity. In some embodiments, based on the request, forecasting system 124 may interface with one or more weather systems to retrieve weather-related information for the workout or activity.

[0134] At step 506 , backend computing system 104 may determine whether the request includes a target heart rate for the activity or exercise. If, at step 506 , prediction system 124 determines that the request does not include a target heart rate, method 500 may proceed to step 508 .

[0135] At step 508, the backend computing system 104 may predict a typical heart rate, a maximum heart rate, and a minimum heart rate of the user based on the time and environmental characteristics of the activity. For example, the prediction system 124 may use the maximum HR model 328 to generate a maximum heart rate of the user based on the time and terrain information. The prediction system 124 may further use the minimum HR model 348 to generate a minimum heart rate of the user based on the time and terrain information. The prediction system 124 may further use the typical HR model 338 to generate a typical heart rate of the user based on the time and terrain information. The generated minimum heart rate, maximum heart rate, and typical heart rate may be used in place of the target heart rate to generate a predicted activity profile for a workout or activity.

[0136] At step 510, the backend computing system 104 may generate an initial or seed heart rate and an initial or seed exercise heart rate for the athlete at each point in the activity. For example, based on at least a target average HR (i.e., effort level) for the activity or a minimum heart rate, maximum heart rate, and typical heart rate (if no target average heart rate is provided), the seed HR model 358 may generate an initial estimated heart rate and an initial exercise heart rate at each point in the activity or workout.

[0137] At step 512, the backend computing system 104 may generate an estimated duration for each point of the exercise or activity. For example, based on the initial heart rate data generated by the seed HR model 358, the duration model 308 may generate an activity time (e.g., exercise time + recovery time) and an exercise time for the exercise or activity at each point of the exercise or activity.

[0138] In step 514, the backend computing system 104 may generate an estimated heart rate and exercise heart rate for each point of the activity based on the initial heart rate, climate information, and / or duration information. For example, the HR model 318 may be configured to generate an estimated heart rate and exercise heart rate for a given point of the activity based on the initial heart rate at the given point of the activity, the duration information for the point of the activity, and the climate information for the point of the activity.

[0139] At step 516, backend computing system 104 may determine whether there is convergence between the HR generated for the activity (at step 516) and the target HR. If, at step 516, prediction system 124 determines that there is no convergence, method 500 may return to step 512, and prediction system 124 may generate a new duration and a new estimated heart rate for the user.

[0140] However, if at step 516, the backend computing system 104 determines that there is convergence, the method 500 may proceed to step 518. At step 518, the backend computing system 104 may output an estimated activity profile for the user based on the prediction. For example, the prediction system 124 may generate an activity profile that includes various metrics at each point in the workout or activity. The various metrics may include heart rate, duration, pace, etc.

[0141] Fig. 6AThe system bus architecture of a computing system 600 according to an example embodiment is shown. The system 600 may represent at least a portion of a user device 102 and / or a backend computing system 104. One or more components of the system 600 may communicate electrically with each other using a bus 605. The system 600 may include a processing unit (CPU or processor) 610 and a system bus 605, which couples various system components including a system memory 615, such as a read-only memory (ROM) 620 and a random access memory (RAM) 625, to the processor 610. The system 600 may include a cache of high-speed memory directly connected to the processor 610, adjacent to the processor 610, or integrated as part of the processor 610. The system 600 may copy data from the memory 615 and / or the storage device 630 to the cache 612 for quick access by the processor 610. In this way, the cache 612 may provide a performance boost, thereby avoiding delays in the processor 610 when waiting for data. These and other modules may control or be configured to control the processor 610 to perform various actions. Other system memories 615 may also be available for use. Memory 615 may include a variety of different types of memory with different performance characteristics. Processor 610 may include any general purpose processor and hardware modules or software modules, such as service 1 632, service 2 634, and service 3 636 stored in storage device 630, which are configured to control processor 610 as well as special purpose processors, where the software instructions are incorporated into the actual processor design. Processor 610 may essentially be a completely independent computing system, including multiple cores or processors, buses, memory controllers, caches, etc. Multi-core processors may be symmetric or asymmetric.

[0142] To enable a user to interact with the computing system 600, the input device 645 may represent any number of input mechanisms, such as a microphone for voice, a touch-sensitive screen for gesture or graphic input, a keyboard, a mouse, motion input, voice, and the like. The output device 635 may also be one or more of a variety of output mechanisms known to those skilled in the art. In some cases, a multimodal system may enable a user to provide multiple types of input to communicate with the computing system 600. The communication interface 640 may generally control and manage user input and system output. There is no restriction on operation on any particular hardware configuration, so the basic features here may be easily replaced by improved hardware or firmware configurations developed.

[0143] The storage device 630 may be a non-volatile memory and may be a hard disk or other type of computer-readable medium that can store computer-accessible data, such as a cassette, a flash memory card, a solid-state storage device, a digital versatile disk, a cassette tape, random access memories (RAMs) 625, read-only memories (ROMs) 620, and a mixture thereof.

[0144] The storage device 630 may include services 632, 634, and 636 for controlling the processor 610. Other hardware or software modules are also contemplated. The storage device 630 may be connected to the system bus 605. In one aspect, a hardware module that performs a particular function may include a software component stored in a computer-readable medium, along with the necessary hardware components, such as the processor 610, the bus 605, the output device 635 (e.g., a display), etc., to perform the function.

[0145] Figure 6B A computer system 650 with a chipset architecture is shown, which can represent at least a portion of a user device 102 and / or a backend computing system 104. The computer system 650 can be an example of computer hardware, software, and firmware that can be used to implement the disclosed technology. The system 650 may include a processor 655, which represents any number of physically and / or logically different resources that can execute software, firmware, and hardware configured to perform the identified calculations. The processor 655 can communicate with a chipset 660, which can control the input and output of the processor 655. In this example, the chipset 660 outputs information to an output 665 such as a display, and can read and write information to a storage device 670, which can include, for example, magnetic media and solid-state media. The chipset 660 can also read data from and write data to a storage device 675 (e.g., RAM). A bridge 680 for interfacing with various user interface components 685 can be provided for interfacing with the chipset 660. Such user interface components 685 may include a keyboard, a microphone, touch detection and processing circuitry, a pointer device such as a mouse, etc. In general, input to the system 650 may come from any of a variety of sources, machine-generated and / or human-generated.

[0146] Chipset 660 may also interface with one or more communication interfaces 690, which may have different physical interfaces. Such communication interfaces may include interfaces for wired and wireless local area networks, broadband wireless networks, and personal area networks. Some applications of the methods disclosed herein for generating, displaying, and using GUIs may include receiving an ordered data set through a physical interface, or generating an ordered data set by the machine itself through processor 655 analyzing data stored in storage device 670 or storage device 675. In addition, the machine may receive input from a user through user interface component 685 and perform appropriate functions, such as performing a browsing function by using processor 655 to interpret these inputs.

[0147] It will be appreciated that example systems 600 and 650 may have more than one processor 610 or be part of a group or cluster of computing devices networked together to provide greater processing power.

[0148] Although the foregoing is directed to the embodiments described herein, other and further embodiments may be devised without departing from the basic scope thereof. For example, aspects of the present disclosure may be implemented in hardware or software or a combination of hardware and software. One embodiment described herein may be implemented as a program product for use with a computer system. The program of the program product defines the functions of the embodiment (including the methods described herein) and may be contained on various computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) a non-writable storage medium on which information is permanently stored (e.g., a read-only memory (ROM) device within a computer, such as a CD-ROM disk that can be read by a CD-ROM drive, a flash memory, a ROM chip, or any type of solid-state non-volatile memory); and (ii) a writable storage medium on which variable information is stored (e.g., a floppy disk in a floppy disk drive or hard drive or any type of solid-state random access memory). Such a computer-readable storage medium, when carrying computer-readable instructions that direct the functions of the disclosed embodiment, is an embodiment of the present disclosure.

[0149] Those skilled in the art will appreciate that the foregoing examples are illustrative and not restrictive. After reading the specification and studying the drawings, all permutations, enhancements, equivalents and improvements will be apparent to those skilled in the art, and these are included in the true spirit and scope of the present disclosure. Therefore, the following appended claims are intended to include all such modifications, permutations and equivalents that fall within the true spirit and scope of these teachings.

Claims

1. A method comprising: receiving, by a computing system, from a user device a request to generate an estimated activity profile for a user of the user device exercising; identifying, by the computing system, route information for the workout, wherein the route information includes at least one data point associated with the route information; generating, by the computing system via a trained prediction system, an initial estimated heart rate of the user for the at least one data point in the route information based on the personalized training process of the user; generating, by the computing system via the trained prediction system, a duration of a portion of the workout based on the at least one data point in the route information and environmental information associated with a time and date of the workout; generating, by the computing system via the trained prediction system, a predicted heart rate for the user during the exercise based on the initial estimated heart rate of the user and a generated duration; and The estimated activity profile corresponding to the exercise is output by the computing system based on the predicted heart rate of the user, wherein the estimated activity profile includes the predicted heart rate of the user.

2. The method according to claim 1, further comprising: determining, by the computing system, that the request includes a target heart rate for the workout, Wherein generating the initial estimated heart rate for the user is further based on the target heart rate for the exercise.

3. The method according to claim 1, further comprising: determining, by the computing system, that the request does not include a target heart rate for the workout; as well as Based on the request, a typical heart rate, a maximum heart rate, and a minimum heart rate are generated by the computing system for the user based on time and / or terrain characteristics associated with the workout.

4. The method according to claim 1, wherein: The route information includes at least a second data point associated with the route information.

5. The method according to claim 4, further comprising: generating, by the computing system via the trained prediction system, a second duration for the second portion of the workout based on the at least a second data point in the route information and second environmental information associated with a second time and the date of the workout; as well as A second predicted heart rate of the user during the exercise is generated by the computing system via the trained prediction system based on the initial estimated heart rate of the user, the generated duration, and a generated second duration.

6. The method according to claim 5, wherein: Outputting, by the computing system, the estimated activity profile corresponding to the exercise based on the predicted heart rate of the user comprises: The estimated activity profile is generated, wherein the estimated activity profile includes the predicted heart rate of the user at the at least one data point and the second predicted heart rate of the user at the at least second data point.

7. The method according to claim 1, further comprising: determining, by the computing system, that the exercise is a multi-point exercise; as well as Based on the determination, the route information associated with the workout is simplified and compressed by the computing system.

8. A non-transitory computer readable medium comprising one or more sequences of instructions that, when executed by a processor, cause a computing system to perform operations comprising: receiving, by the computing system, from a user device, a request to generate an estimated activity profile for a user of the user device exercising; identifying, by the computing system, route information for the workout, wherein the route information includes at least one data point associated with the route information; generating, by the computing system via a trained prediction system, an initial estimated heart rate of the user for the at least one data point in the route information based on the personalized training process of the user; generating, by the computing system via the trained prediction system, a duration of a portion of the workout based on the at least one data point in the route information and environmental information associated with a time and date of the workout; generating, by the computing system via the trained prediction system, a predicted heart rate for the user during the exercise based on the initial estimated heart rate of the user and a generated duration; and The estimated activity profile corresponding to the exercise is output by the computing system based on the predicted heart rate of the user, wherein the estimated activity profile includes the predicted heart rate of the user.

9. The non-transitory computer readable medium of claim 8, further comprising: determining, by the computing system, that the request includes a target heart rate for the workout, Wherein generating the initial estimated heart rate for the user is further based on the target heart rate for the exercise.

10. The non-transitory computer readable medium of claim 8, further comprising: determining, by the computing system, that the request does not include a target heart rate for the workout; as well as Based on the request, a typical heart rate, a maximum heart rate, and a minimum heart rate are generated by the computing system for the user based on time and / or environmental characteristics associated with the workout.

11. The non-transitory computer readable medium of claim 8, wherein: The route information includes at least a second data point associated with the route information.

12. The non-transitory computer readable medium of claim 11, further comprising: generating, by the computing system via the trained prediction system, a second duration for the second portion of the workout based on the at least a second data point in the route information and second environmental information associated with a second time and the date of the workout; as well as A second predicted heart rate of the user during the exercise is generated by the computing system via the trained prediction system based on the initial estimated heart rate of the user, the generated duration, and the generated second duration.

13. The non-transitory computer readable medium of claim 12, wherein: Outputting, by the computing system, the estimated activity profile corresponding to the exercise based on the predicted heart rate of the user comprises: The estimated activity profile is generated, wherein the estimated activity profile includes the predicted heart rate of the user at the at least one data point and the second predicted heart rate of the user at the at least second data point.

14. The non-transitory computer readable medium of claim 8, further comprising: determining, by the computing system, that the exercise is a multi-point exercise; as well as Based on the determination, the route information associated with the workout is simplified and compressed by the computing system.

15. A system comprising: processor; as well as a memory having stored thereon programming instructions which, when executed by the processor, cause the system to perform operations including: receiving, from a user device, a request to generate an estimated activity profile for a user of the user device exercising; identifying route information for the workout, wherein the route information includes at least one data point associated with the route information; generating, via the trained prediction system, an initial estimated heart rate of the user for the at least one data point in the route information based on the personalized training process of the user; generating, via the trained prediction system, a duration of a portion of the workout based on the at least one data point in the route information and environmental information associated with a time and date of the workout; generating, via the trained prediction system, a predicted heart rate for the user during the exercise based on the initial estimated heart rate of the user and the generated duration; and The estimated activity profile corresponding to the exercise is output based on the predicted heart rate of the user, wherein the estimated activity profile includes the predicted heart rate of the user.

16. The system of claim 15, wherein: The operations further include: determining that the request includes a target heart rate for the workout, Wherein generating the initial estimated heart rate for the user is further based on the target heart rate for the exercise.

17. The system of claim 15, wherein: The operations further include: determining that the request does not include a target heart rate for the workout; and Based on the request, a typical heart rate, a maximum heart rate, and a minimum heart rate are generated for the user based on time and / or environmental characteristics associated with the workout.

18. The system of claim 15, wherein: The route information includes at least a second data point associated with the route information.

19. The system of claim 18, wherein: The operations further include: generating, via the trained prediction system, a second duration for a second portion of the workout based on the at least a second data point in the route information and second context information associated with a second time of the workout and the date; and A second predicted heart rate of the user during the exercise is generated, via the trained prediction system, based on the initial estimated heart rate of the user, the generated duration, and the second generated duration.

20. The system of claim 19, wherein: Outputting the estimated activity profile corresponding to the exercise based on the projected heart rate of the user includes: The estimated activity profile is generated, wherein the estimated activity profile includes the predicted heart rate of the user at the at least one data point and the second predicted heart rate of the user at the at least second data point.

Images