System and method for predicting individual performance in sports activities

Abstract

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

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims priority to U.S. Application No. 17 / 808,806, filed on June 24, 2022, the entire disclosure of which is incorporated herein by reference.

[0002] The present disclosure generally relates to systems and methods for predicting an individual's performance in sports activities, according to exemplary embodiments.

Background Art

[0003] With the rapid increase in wearable devices and fitness trackers, it has become commonplace for athletes and fitness enthusiasts to track their workouts to identify trends and improvements in their fitness capabilities. Such devices provide users with real - time or near - real - time feedback regarding biometric data such as heart rate, as well as other metrics such as gait.

Summary of the Invention

Means for Solving the Problems

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

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

[0006] 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 the programming instructions are executed by the processor, they cause the system to perform operations. The operations include receiving, from a user device, a request to generate an estimated activity profile for a user of the user device for a workout. The operations further include identifying route information for the workout. The route information includes at least one data point associated with the route information. The operations further include generating, via a trained prediction system, an initial estimated heart rate for the user for at least one data point in the route information based on a personalized training process for the user. The operations further include generating, via the trained prediction system, a duration for a portion of the workout based on at least one data point in the route information and environmental information associated with the time and date of the workout. The operations further include generating, via the trained prediction system, an expected heart rate for the user during the workout based on the user's initial estimated heart rate and the generated duration. The operations further include outputting an estimated activity profile corresponding to the workout based on the user's expected heart rate. The estimated activity profile includes the user's expected heart rate.

Brief Description of the Drawings

[0007] To better understand the above-described features of the present disclosure, a more specific description of the present disclosure, briefly summarized above, can be obtained with reference to the embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only typical embodiments of the present disclosure and, therefore, should not be considered as limiting the scope of the present disclosure, as the present disclosure may admit of other equally effective embodiments.

[0008]

Figure 1

[0009]

Figure 2A

[0010]

Figure 2B

[0011]

Figure 2C

[0012]

Figure 3A

[0013]

Figure 3B

[0014]

Figure 3C

[0015]

Figure 3D

[0016]

Figure 3E

[0017]

Figure 3F

[0018]

Figure 4

[0019]

Figure 5

[0020]

Figure 6A

[0021]

Figure 6B

[0022] For ease of understanding, the same reference numerals are used wherever possible to indicate identical elements common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially utilized in other embodiments without specific recitation. DETAILED DESCRIPTION OF THE INVENTION

[0023] The estimation of fitness performance is a topic of high interest for athletes and coaches of all ability levels. Conventional approaches to estimating fitness performance tend to focus on single elements of performance. For example, conventional approaches may focus on predicting race results from known short distances, estimating maximum heart rate versus age, understanding the effect of treadmill incline on speed, etc. These conventional approaches are limited in that they have not been able to take a holistic and personalized perspective when estimating the fitness of each athlete.

[0024] One or more techniques described herein utilize a machine learning approach to analyze relevant metrics from an activity tracking device to predict fitness performance for an activity or workout, and improve upon conventional approaches by controlling for multivariate effects such as physical environment, weather, training load, physiological limitations such as age, etc. For example, one or more techniques described herein may generate a predicted or estimated activity file for an activity or workout. In some embodiments, the predicted or estimated activity file may be based, for example, on position coordinates associated with the activity or workout.

[0025] FIG. 1 is a block diagram illustrating an exemplary computing environment 100 according to an exemplary embodiment. The computing environment 100 can include at least one or more user devices 102, a backend computing system 104, and a fitness tracking device 106 that communicate via a network 105.

[0026] Network 105 may be of any suitable type, including an individual connection via the Internet, such as a cellular or Wi-Fi network. In some embodiments, network 105 may connect terminals, services, and mobile devices using direct communication such as radio frequency identification (RFID), near-field communication (NFC), Bluetooth™, low energy Bluetooth™ (BLE), Wi-Fi™, ZigBee™, ambient backscatter communication (ABC) protocol, USB, WAN, or LAN. Since the information transmitted may be personal or confidential information, for security reasons, one or more of these connection types may be specified to be protected by methods such as encryption. However, in some embodiments, the information transmitted may not be very personal, and in that case, the network connection may be selected with more emphasis on convenience than security.

[0027] Network 105 may include any type of computer networking configuration used to exchange data. For example, network 105 may be the Internet, a private data network, a virtual private network using a public network, and / or any other suitable connection that enables components in computing environment 100 to send and receive information between components of computing environment 100.

[0028] The user device 102 can be operated by a user. The user device 102 may represent a mobile device, a tablet, 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.

[0029] In operation, when a user utilizes the fitness tracking device 106, the fitness tracking device 106 may be configured to record the movement of the user during activity. In some embodiments, the fitness tracking device 106 may record various data and store those data in a file corresponding to the activity or workout. In some embodiments, the various data within the file may include coordinate information (e.g., timestamp, latitude coordinate, longitude coordinate) based on the movement of the user during the activity or workout. In some embodiments, the various data within the file may further include one or more metrics associated with the workout, such as, but not limited to, elevation, 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 an activity file includes three sets of coordinates (lat1, long1), (lat2, long2), (lat3, long3), each set of coordinates may include a set of associated metrics (e.g., elevation, heart rate, pace, device temperature, etc.).

[0030] In some embodiments, the activity file may take the form of a GPS Exchange Format (GPX) file type, an Interoperable Data Transfer (FIT) file format, a Training Center XML format, a Keyhole Markup Language format, etc.

[0031] The fitness tracking device 106 may generate an activity file in one of these file formats upon completion of an activity or workout.

[0032] The user device 102 may include at least the 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 via the network 105, for example, to request a web page from the 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, via the application 112, the user can access and view his or her estimated fitness performance generated by the backend computing system 104 for the next activity or workout. Via the application 112, the user can further access and view his or her past fitness performance maintained by the backend computing system 104.

[0033] The content displayed by the user device 102 may be processed by the application 112 for display through the graphical user interface (GUI) of the user device 102 after being transmitted from the web client application server 114 to the user device 102.

[0034] 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 predict or estimate a user's fitness performance for a next activity or workout based on the user's past activity data. For example, given details of a next workout or activity, the fitness performance system 116 may be configured to generate a predicted activity file for that workout or activity based on learned information about the user.

[0035] The fitness performance system 116 may include a preprocessing system 120, a training system 122, and a prediction system 124. Each of the preprocessing system 120, the training system 122, and the prediction system 124 may be composed of one or more software modules. The one or more software modules represent a set of code or instructions stored in a medium (e.g., the memory of the backend computing system 104) that implements a series of machine instructions (e.g., program code) for performing one or more algorithm steps. Such machine instructions may be actual computer code that is interpreted by a processor of the backend computing system 104 to execute the instructions, or may be a higher-level coding of instructions that is interpreted to obtain the actual computer code. The one or more software modules may also include one or more hardware components. One or more aspects of an exemplary algorithm may be performed by the hardware components (e.g., circuits) themselves rather than as a result of instructions.

[0036] The preprocessing system 120 may be configured to process activity records received from the user device 102 and / or the fitness tracking device 106. For example, the preprocessing system 120 may be configured to perform two by-products collection of the activity records stored in the database. In some embodiments, the activity records may include the massaged activity records and the training-ready activity records.

[0037] The preprocessing system 120 may be configured to generate massaged activity records based on the raw activity data received from the user device 102 and / or the fitness tracking device 106. The preprocessing system 120 may store the massaged activity records for quick search by an end user who wishes to view the analysis results of its own activities via the application 112.

[0038] The preprocessing system 120 may be further configured to generate training-ready activity records for training the prediction model of the fitness performance system 116. The training-ready activity records may represent activity records that have been processed by the preprocessing system 120 in a form suitable for direct input into model training or in a state "after being massaged". Since the training-ready activity records can be directly combined with newer, first-time activities to update or retrain the model, the training-ready activity records can prevent the fitness performance system 116 from performing iterative calculations.

[0039] The training system 122 may be configured to train the prediction model of the fitness performance system 116. In some embodiments, the training system 122 may train the prediction model based on athlete-specific data and athlete-independent data. In this way, the training system 122 can generate a set of robust prediction models based on the collective knowledge of a wider range of users or athlete communities.

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

[0041] In some embodiments, the computing environment 100 may further include one or more third-party systems 108. In some embodiments, the 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, the one or more third-party systems 108 may represent various weather services for obtaining weather or meteorological information at a given location.

[0042] FIG. 2A is a block diagram showing a preprocessing system 120 according to an exemplary embodiment. The preprocessing system 120 may be configured to filter incoming activity data 202 (e.g., device activity records) in a form suitable for training a set of prediction models. For example, the preprocessing system 120 may be configured to annotate incoming activity data 202 with features relevant to performance modeling.

[0043] Since missing and / or errors in raw activity data are not uncommon, the preprocessing system 120 may implement a dual data massage pipeline. For example, a chest strap for an athlete's heart rate monitor may become loose during training, and as a result, the effort data of the heart rate may become invalid. In another example, due to inaccurate GPS signals, extreme drift of the position may occur. Since the manufacturing manufacturer of the fitness tracking device 106 processes irregular data points in a black box manner, which is at best inconsistent and at worst causes serious results without correction, the preprocessing system 120 may clean the raw activity data before model training.

[0044] The preprocessing system 120 may preprocess or massage the raw activity data in two pipelines, namely, a first pipeline (verified data pipeline 206) (massage-verified) to support past activity records, and a second pipeline (unverified data pipeline 208) (massage-unverified) to support general activities coming into the prediction from unknown sources. In the verified data pipeline 206, the verified activities performed by the athlete may be considered to be from the athlete's own authenticated device or from a direct and clear upload to the application 112. As an output from the verified data pipeline 206, the preprocessing system 120 may generate verified massaged data 210, which may be a preprocessed or massaged version of the raw verified data. The verified massaged data 210 may be stored in an annotated database. By doing so, the relevant features available for input to model training can also be viewed by the athlete in an isolated context to show metrics such as distance, location, weather, places / timings / durations for taking breaks, etc.

[0045] Unlike the confirmed activity data, unconfirmed activities usually do not have guarantees regarding the validity of timestamps or attribute data (e.g., heart rate), and are only intended to be used in the prediction system 124. Therefore, the preprocessing system 120 may utilize the unconfirmed data pipeline 208 to process the unconfirmed activity data.

[0046] In operation, the capture module 204 may be configured to determine whether the data is confirmed or unconfirmed. If the activity data is directly uploaded from the athlete's own authenticated device or is clearly indicated as the athlete's activity through a manual file upload, the activity data may be considered confirmed data. Unconfirmed data refers to any other activity that has not been confirmed by the athlete. Confirmed data can be used to train various prediction models, while unconfirmed data can only be used for massaging activities for prediction purposes. Based on the determination, the capture module 204 may input a subset of the confirmed data into the confirmed data pipeline 206 to generate the confirmed massaged data 210. Similarly, the capture module 204 may further input a subset of the unconfirmed data into the unconfirmed data pipeline 208 to generate the unconfirmed massaged data 212.

[0047] The ingestion module 204 may be configured to receive or import raw activity data from the fitness tracking device 106 and / or the user device 102. From the raw activity data, the ingestion module 204 may be configured to identify core features. The core features may include, but are not limited to, timestamp, latitude, longitude, altitude, heart rate, pace, and device temperature. The raw activity data may include additional attributes such as, but not limited to, device information, activity name, activity details, and type of sport, and the ingestion module 204 may store such additional attributes as metadata for additional activity context if available. Latitude, longitude, and altitude may be used downstream to construct a geographic location polyline representing the traveled route of the activity.

[0048] In some embodiments, the ingestion module 204 may be configured to generate secondary features from the core device features. Exemplary secondary features may include, but are not limited to, athlete altitude gain and loss, i.e., vertical shift, orbit relative to true north, relative orbit change between position points, and gait transitions such as shift from walking to running (or from running to walking).

[0049] For example, consider an athlete running on a flat road using a barometer-equipped smartwatch that records the activity. Due to the relatively sensitive nature of the barometer's air pressure measurements, minor fluctuations in the centimeter range may be distinguishable because the device position on the wrist sways up and down, is lifted above the head for stretching, or hovers near the ground to tie shoelaces. To account for this, the ingestion module 204 may utilize a developer-defined "threshold". For example, the developer may stipulate that a 2-meter climb needs to occur continuously over a distance of 10 meters to be added to the total altitude gain.

[0050] For example, assume that the first elevation measurement value is taken as the golden reference point, and from there, the upper control limit (UCL) and the lower control limit (LCL) can be determined by the separation of a fixed number of meters derived empirically. As long as the elevation measurement values stay within these limits, the rise and fall of the vertical shift will be considered zero. However, when one of the two thresholds, such as the upward transition in the case of UCL and the downward transition in the case of LCL, is exceeded, the capture module 204 may perform a buffered lookback to find the starting transition point where the rise or fall began. The capture module 204 may mark the starting transition point as a new reference point. If the capture module 204 cannot find the location where the change in direction started in the buffered lookback, the capture module 204 may consider the latest point as the new reference. Within a given flat, rising, or falling area, the relative change with respect to the reference point may be considered as the movement of a vertical athlete. Also, if the rising or falling area can transition to an area where the degree of slope is below a threshold that is almost horizontal, the capture module 204 may reset that area to flat.

[0051] Such an approach is not limited to the micro scale of a few meters (i.e., the variable position of the recording device). Instead, the capture module 204 may apply the same methodology on a macro scale and use the UCL and LCL set in a larger meter range to grasp the mountains and valleys along the activity course. Since an athlete is more likely to rest at the peak of a mountain than during a descent, this is not only useful as an input feature for model training but also enables quantification of the relative prominence between the previous and the next mountain / valley. In other words, patterns of the athlete regarding effort, rest, etc. can be glimpsed from the prominence of the climb, the relative completion rate along the path, the elevation of the final highest point, and the degree of slope, etc.

[0052] The vertical shift relative to the horizontal plane can result in a variable energy consumption called the metabolic cost (MC), which is mainly affected by gravity and secondarily by walking. In this regard, the breakdown of the horizontal distance traveled during each ascent and descent is carried over so that the MC can be calculated during downstream point aggregation.

[0053] In some embodiments, the capture module 204 may be further configured to generate derived feature quantities. The capture module 204 may generate derived feature quantities based on the core device feature quantities and secondary feature quantities. The derived feature quantities may be roughly categorized into subsets related to heart rate, rest duration, altitude and position of the sun (daytime, night, sunrise, etc.), speed, and slope gradient. Also, the derived feature quantities may include a cumulative total between the three feature quantity sets (e.g., the total horizontal distance traveled so far).

[0054] FIG. 2B is a block diagram showing in more detail the verified data pipeline 206 according to an exemplary embodiment. As shown, the verified data pipeline 206 may include a plurality of operations executed by the preprocessing system 120.

[0055] In block 240, the preprocessing system 120 may remove outliers from the activity data. Generally, sensors are susceptible to the influence of incorrect measurements. The preprocessing system 120 may identify outliers from various data such as, but not limited to, GPS position data, elevation data, speed data, and heart rate data. In some embodiments, if the preprocessing system 120 determines that a feature quantity is an outlier at a particular timestamp point, the preprocessing system 120 may purge the entire set of data associated with that point from the activity record. In some embodiments, an exception to this rule may occur if only the HR feature quantity is determined to be an outlier. In such embodiments, the preprocessing system 120 may mask the HR feature quantity with a null value instead of purging the entire set of data associated with that point.

[0056] The purpose of purging the entire outlier values is to reduce the impact on the remaining part of the activity data because there is no meaningful way to calculate valid replacement values. The bar for outlier identification may be kept somewhat conservative to avoid over-removal, and downstream filtering in a later stage is expected to smooth out the remaining wrinkles.

[0057] Regarding position outliers, the preprocessing system 120 may be configured to remove outliers in both the horizontal and vertical planes. The preprocessing system 120 may identify a cluster of outlier positions where the position deviates significantly in terms of position and / or distance from points before and after the cluster, and removing it reduces the total activity distance. In some embodiments, the preprocessing system 120 may use the DBSCAN (Density-Based Spatial Clustering of Applications with Noise) clustering algorithm to identify the cluster.

[0058] Regarding speed outliers, the preprocessing system 120 may calculate the speed outliers by normalizing the elapsed speed Poisson distribution through the Yeo-Johnson power transformation. The preprocessing system 120 may then generate an alternative speed by dividing the horizontal distance by the sum of the elapsed time and a given epsilon value. The preprocessing system 120 may then mark any alternative speed greater than the outlier value for removal. Since points captured at low time intervals are inherently variable and result in over-removal, the preprocessing system 120 may use a slower alternative speed as a selection criterion.

[0059] Regarding outliers in heart rate, heart rate monitoring devices are typically susceptible to the effects of wireless connection or electrode contact loss, resulting in data point loss, sudden drops in measured values, HR lock at the last measured value until the end of activity, etc. In some embodiments, optical heart rate devices are sensitive to light pollution and may enter a locked state with respect to an athlete's running pace, resulting in abnormally high values or values that are incorrectly locked over a long period. The preprocessing system 120 may identify clusters of locked values where the measured value can remain unchanged over a minimum number of consecutive samples. In some embodiments, the preprocessing system 120 may use the hierarchical DBSCAN (HDBSCAN) clustering algorithm to identify the clusters.

[0060] In block 242, the preprocessing system 120 may smooth the activity data following outlier removal. For example, while outlier removal is typically expected to prune most instances of suspect points from the activity record, the preprocessing system 120 may perform a filtering process to smooth minor defects related to the variability of the measurements (i.e., noise). However, unlike outlier removal, during the smoothing process, the preprocessing system 120 may replace the existing values of the features with new values rather than removing the entire data points. For example, the preprocessing system 120 may use a Kalman filter to smooth the activity data.

[0061] In block 244, the preprocessing system 120 may identify a rest position and the duration of a rest for a given athlete. For example, the preprocessing system 120 may use a clustering technique that aggregates a group of consecutive timestamp points when the athlete is at rest (i.e., not moving). Such clustering may be used to distinguish the elapsed (i.e., measured) time of the activity from movement time, which may be of shorter duration and can be used as an indicator of effort. In some embodiments, the preprocessing system 120 may use a DBSCAN (Density-Based Spatial Clustering of Applications with Noise) clustering algorithm or an Inertial Measurement Unit (IMU) to identify clusters.

[0062] In block 246, the preprocessing system 120 may create a geographic location representation of the activity data, for example, by creating a buffered polygon that includes all position points within a 100-meter range of the activity. This representation may function as the area range of the annotation. For example, if the activity is completely contained within Central Park in New York, the fitness performance system 116 may only download the road network graph from the immediate area and an additional buffer around the immediate area to account for errors in GPS data or map accuracy.

[0063] In block 248, the preprocessing system 120 may annotate the geographic location representation of the activity data. The annotation process may include road / trail network annotation, point of interest annotation, and weather annotation.

[0064] Regarding road and path network annotations, the road and path network can be a useful source of activity metadata. The preprocessing system 120 may be configured to store the road and path network in a graph represented by a set of nodes (vertices / junctions) and edges (node pairs). The graph may hold attributes regarding the surface condition (e.g., paved / unpaved) indicating how fast an athlete can move, as well as describe the complexity of the surrounding environment and even the locations where an athlete can rest spontaneously or non-spontaneously and the duration of that time. However, unlike vehicle movement which is mostly in a straight direction, human-powered activity may appear relatively unstable when compared, so a series of inferences regarding the road network are required to assign correct usage. The set of inferred features provides information about surface types (e.g., road vs. path), road junctions (e.g., traffic signals), path junctions, and transition nodes between surfaces (e.g., the change from a paved street to a path). In some embodiments, the preprocessing system 120 may capture the type of each junction and the global unique identifier of each junction.

[0065] Exemplary paved annotations may include, but are not limited to, paved, asphalt, chip seal, concrete, concrete lane, concrete plate, paving stones, stone paving, uncut cobblestones, cobblestones, metal, wood, etc. Exemplary unpaved annotations may include, but are not limited to, unpaved, compacted, fine gravel, gravel, rock, pebbles, ground, loose soil, soil, grass, grass paving, mud, sand, wood chips, salt, etc.

[0066] Points of interest (POI) annotations can identify locations where activity records approach artificial landmarks or natural features. The presence of these POIs can hold attributes related to an athlete's speed or rest, especially likely to be the location of unusually long rest places.

[0067] Weather annotations can be used to transfer to activity records corresponding to environmental conditions related to the weather. In some embodiments, the preprocessing system 120 may adjust the weather annotations for elevation. In some embodiments, to generate weather annotations, the preprocessing system 120 may utilize one or more third-party systems 108 for weather metadata. In some embodiments, the preprocessing system 120 may utilize device records (e.g., fitness tracking device 106) for temperature data. Exemplary weather annotations may take into account one or more of temperature, humidity, elevation, wind speed, air quality, snow accumulation, etc.

[0068] As output, the preprocessing system 120 may generate verified and massaged data 210 that can be processed and annotated with information used to train a prediction model.

[0069] FIG. 2C is a block diagram showing more details of the unconfirmed data pipeline 208 according to an exemplary embodiment. As shown, the unconfirmed data pipeline 208 may include a plurality of operations performed by the preprocessing system 120.

[0070] In block 260, the preprocessing system 120 may remove athlete-specific metrics from the unconfirmed activity data. For example, the preprocessing system may force athlete-specific features (e.g., HR, pace, etc.) to null values to avoid the possibility that such attributes contaminate the prediction seed conditions or confuse the user. Such a process is performed because such metrics may not be practical for guaranteeing the source of the activity. For example, the activity data may be generated by different individuals.

[0071] In block 262, the pre - processing system 120 may set the athlete's speed for the activity data. For example, as described above, the pre - processing system 120 may override the activity speed of the massage - unconfirmed pipeline 208 to provide a consistent set of time - dependent features for prediction. Courses drawn on mapping services such as GaiaGPS or AllTrails often have inconsistent timestamps or lack any timestamps at all. Since other features such as time and weather conditions may depend on the athlete's speed, the pre - processing system 120 may initialize the speed to a reasonable value. In some embodiments, the pre - processing system 120 may set the average walking speed of an adult (e.g., 1.4 m / s) as an initial condition. Such speed setting may enable faster convergence in activity prediction. Since most activities are completed within a short time frame of less than a day, it is possible that the prediction will not deviate significantly from the actual behavior due to the initial conditions.

[0072] In block 264, the pre - processing system 120 may remove outliers from the activity data. Generally, sensors are susceptible to the influence of incorrect measurements. The pre - processing system 120 may identify outliers from various data such as, but not limited to, GPS location data, elevation data, etc. Unlike the confirmed data pipeline 206, the pre - processing system 120 may not have to remove speed outliers or heart rate outliers from the activity data.

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

[0074] The purpose of purging the entire set of outliers is to reduce the impact on the remaining part of the activity data because there is no meaningful way to calculate valid replacement values. The bars for outlier identification may be kept somewhat conservative to avoid over-removal, and it is expected that the remaining wrinkles will be smoothed out by downstream filtering at a later stage.

[0075] Regarding positional outliers, the preprocessing system 120 may be configured to remove outliers in both the horizontal and vertical planes.

[0076] In step 266, the preprocessing system 120 may divide an excessive distance in the activity data into smaller segments. For example, the distance between points may be limited to the maximum distance in the massage unconfirmed pipeline 208. The purpose of doing this is to ensure that the downstream input to the activity prediction does not exceed the distance characterization range during model training because it may reduce the reliability of the prediction. Thus, any single measurement that exceeds a predetermined maximum distance may be divided into n equidistant straight-line segments. This scenario is not uncommon in the activity course depicted on the map because providers of these services often simplify the course shape as much as possible to reduce the number of points and thus their memory footprint.

[0077] When a single point is divided into multiple points, the preprocessing system 120 may linearly segment the feature quantities of latitude, longitude, and altitude along the segment. Other feature quantities such as HR are unknown as to how their actual values will be in relation to the division position, and thus may remain unmodified because the assumptions become invalid.

[0078] In athletic activities, excessive inter-point distances are usually due to some form of measurement error, long sections where the position is not measured (e.g., tunnels), or the athlete forgetting to resume activity after a temporary stop and moving a certain distance. Therefore, such a process may not be part of the massaged and verified pipeline 206. Such data may not be useful for training the prediction model because the resolution of the data per meter of movement is low. By leaving the inter-point distances uncorrected in the massaged and verified pipeline 206, it may be possible to annotate them as outliers through statistical analysis in block 248 of the verified data pipeline 206.

[0079] In block 268, the preprocessing system 120 may smooth the activity data following outlier removal. For example, outlier removal is usually expected to prune most instances of suspicious points from the activity record, but the preprocessing system 120 may perform a filtering process to smooth minor defects related to the variability of the measurements (i.e., noise). However, unlike outlier removal, during the smoothing process, the preprocessing system 120 may replace the existing values of the features with new values instead of removing the entire data points. For example, the preprocessing system 120 may use a Kalman filter to smooth the activity data.

[0080] In block 270, the preprocessing system 120 may identify the rest positions and the duration of rest for a given athlete. For example, the preprocessing system 120 may use a clustering technique that aggregates groups of consecutive timestamp points when the athlete is at rest (i.e., not moving). Such clustering may be used to distinguish the elapsed (i.e., actual measured) time of the activity from the movement time that can be used as an indicator of effort.

[0081] In block 272, the preprocessing system 120 may create a geographical location representation of the activity data.

[0082] In block 274, the preprocessing system 120 may annotate the geographical location representation of the activity data. The annotation process may include road / trail network annotation, point of interest annotation, and weather annotation.

[0083] Regarding road / trail network annotation, the road / trail network can be a useful source of activity metadata. The preprocessing system 120 may be configured to store the road / trail network in a graph represented by a set of nodes (vertices / junctions) and edges (node pairs). The graph may hold attributes regarding the surface condition (e.g., paved / unpaved) indicating how fast an athlete can move, as well as describe the complexity of the surrounding environment and even the locations where an athlete may take spontaneous or involuntary breaks and the duration of such breaks. However, unlike vehicle movement which is mostly in a straight direction, human-powered activities may appear relatively unstable when compared, and thus a series of inferences regarding the road network are required to assign correct usage. The inferred feature set conveys information about surface type (e.g., road vs. trail), road junctions (e.g., traffic signals), trail junctions, and transition nodes between surfaces (e.g., change from a paved street to a trail). In some embodiments, the preprocessing system 120 may capture the type of each junction and the global unique identifier of each junction.

[0084] Exemplary paved annotations may include, but are not limited to, paved, asphalt, chip seal, concrete, concrete lane, concrete plate, paving stone, stone slab paving, uncut cobblestone, cobblestone, metal, wood, etc. Exemplary unpaved annotations may include, but are not limited to, unpaved, compacted, fine gravel, gravel, rock, pebble, ground, loose soil, soil, turf, turf paving, mud, sand, wood chip, salt, etc.

[0085] Point of Interest (POI) annotations can identify where activity records approach artificial landmarks or natural features. The presence of these POIs can hold attributes related to an athlete's speed or rest, and are particularly likely to be located at unusually long rest locations.

[0086] Weather annotations can be used to transfer environmental conditions related to the weather to activity records. In some embodiments, the preprocessing system 120 may adjust the weather annotation for elevation. In some embodiments, to generate the weather annotation, the preprocessing system 120 may utilize one or more third - party systems 108 for weather metadata. In some embodiments, the preprocessing system 120 may utilize device records (e.g., fitness tracking device 106) for temperature data. Exemplary weather annotations may take into account one or more of temperature, humidity, elevation, wind speed, air quality, snow accumulation, etc.

[0087] As output, the preprocessing system 120 may generate unconfirmed massaged data 212 that can be processed and annotated with information used as input to the prediction model.

[0088] Figures 3A - 3F are block diagrams showing the training system 122 in more detail according to an exemplary embodiment. As shown over Figures 3A - 3F, six separate performance models may 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 normal 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 may be used by the prediction system 124 to perform activity predictions when the desired effort level is known. The max HR model 328, the normal HR model 338, and the min HR model 348 may be used when profiling the range of potential effort.

[0089] The training system 122 may generally include a preprocessing module 302. The preprocessing module 302 may be configured to perform one or more preprocessing operations on the output data from the verified message pipeline 206.

[0090] In some embodiments, the preprocessing module 302 may be configured to simplify the data from the verified data pipeline. For example, the preprocessing module 302 may remove the common "shaking movement" in the verified massaged data 210 so that the verified massaged data 210 appears moderately similar to those characterized by more straight lines among the activities depicted on the map. Since it may become more difficult to train the model for the athlete to distinguish perceptible conditions as the activity is simplified, this kind of rough simplification is a task that requires a sense of balance.

[0091] In some embodiments, the preprocessing module 302 may be configured to compress the data. The preprocessing module 302 may utilize one or more compression methods for compressing the data. In some embodiments, the preprocessing module 302 may assign points to groups of variable distances based on a Gaussian distribution having a given target mean and standard deviation. In some embodiments, the preprocessing module 302 may assign points to groups of variable distances based on a random distribution between a minimum distance and a maximum distance. Due to the non-uniform nature of the individual points, compression does not mean that an exact target distance is obtained, and it may aim for the closest possible target distance without violating the minimum-maximum criteria.

[0092] The most important reason for using the randomized distance compression method in the model training stage is to reduce the possibility of the model overfitting. In an extreme example of overfitting, the model provides almost perfect predictions for the trained data, but provides poor predictions for even a slight deviation in the values of the features within the training range. The next important reason is to enable the expansion of the dataset, which is a practice of modifying the same data in various ways to enhance the diversity of feature inputs (i.e., increasing the size of the sample population). This practice is common in convolutional neural networks (CNNs) used in image processing applications to increase the number of unique training samples. The preprocessing module 302 may achieve an effect similar to increasing the number of unique training samples by compressing the activity records into multiple permutations, each following its own clustering distance target. The preprocessing module 302 may discard overlapping points if they exist.

[0093] A beneficial side effect of compression is that it substantially reduces the number of points, and thus results in a reduction in the memory footprint and a relaxation of the computational requirements for model training and model serving (i.e., prediction). Further, compression increases the likelihood that the points sent to training will have non-zero rest durations, thereby obtaining a more generalizable context for the timing and reasons of its occurrence.

[0094] In some embodiments, the preprocessing module 302 may be configured to complement the athlete's activity record if the collection of the athlete's activity record is insufficient in terms of the points available for training (e.g., the smallness of the sample size) or the narrowness of the characterization range (e.g., the lack of diversity of the sample population). In some embodiments, to complement the athlete's activity record, the preprocessing module 302 may use pre-compressed training activity records from other athletes. In some embodiments, to complement the athlete's activity record, the preprocessing module 302 may aggregate the training activity records of other athletes. For example, the preprocessing module 302 may identify one or more athletes similar to the target athlete based on the combination of gender, age, and fitness level. In some embodiments, the preprocessing module 302 may obfuscate the data points belonging to one or more other athletes.

[0095] In some embodiments, the preprocessing module 302 may further perform annotating outliers in the dataset. As will be appreciated by those skilled in the art, within the range of data to be input into model training, there are always points that do not represent actual performance hidden, and thus they should be removed from consideration. To identify outliers, the preprocessing module 302 may be configured to utilize various methods to identify statistical outliers.

[0096] Subsequent to the preprocessing of the data, the training modules 304 - 354 may be configured to train their respective machine learning models 306 - 356 to generate optimized prediction models for deployment.

[0097] Referring to FIG. 3A, the training module 304 may be configured to train a machine learning model 306 to generate a duration model 308. In some embodiments, the machine learning model 306 may represent a deep neural network regression architecture. As would be understood by those skilled in the art, the machine learning model 306 may represent a deep neural network regression architecture, but other more complex architecture types may be used. For example, in some embodiments, the machine learning model 306 may represent a variant form of long short-term memory (LSTM) of a recurrent neural network. This is because the feedback state can be embedded in the deep neural network, making it possible to learn from past long-term dependencies when making future predictions.

[0098] 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.

[0099] To train the machine learning model 306, the training module 304 may split the dataset into three randomly grouped sets for training, validation, and testing.

[0100] In some embodiments, the training module 304 may repeatedly fit batches of features to their respective outputs using the training set. In some embodiments, the training module 304 may independently test the fitness between each of these repetitions (epochs) using the validation set. In some embodiments, the training module 304 and the test set are completely unknown to the fitting process and are used to test the generality of the completed model. In some embodiments, the dataset may be randomized before being split to prevent the machine learning model 306 from continuously learning similarities.

[0101] The training-validation-test process enables the stratification of one or more explicitly requested features and evenly divides these features into three groups according to their ratios with respect to the entire sample population. For example, by stratifying each activity (i.e., unique start timestamp), an equal portion of that point is assigned to the three groups, and activities with a large number of points can reduce the possibility of overshadowing activities with fewer points. For example, multiple data records in which an ultramarathon is associated with a short run in the neighborhood once will present a scenario like looking for a needle in a haystack. The training module 304 may perform a similar process to ensure an even distribution of heart rate and movement / non-movement ratios. These stratifications can effectively achieve training diversity.

[0102] In some embodiments, in addition to or as an alternative to stratification, a more narrowly targeted splitting method known as oversampling is available. Oversampling isolates the values of a specific range of features in their own splitting process and then randomly combines their training-validation-test groups.

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

[0104] The training module 304 may utilize a customized loss function that addresses fundamental problems related to multi-output regression modeling that can occur when the distributions of the outputs are significantly different. Since one of the outputs may have a higher loss than the other, more time will be spent optimizing the higher loss at the expense of the lower loss. The travel time can be limited by the reciprocal of the minimum human speed, while the activity time can potentially reach near-zero speed and take several hours for a distance of a hundred meters. Therefore, when using the mean squared error or a standard loss function such as Poisson that may be appropriate in this case, the optimization of the training will inevitably be biased towards the activity time.

[0105] The customized loss function can function by first applying the Yeo-Johnson power transformation to both the true and predicted values of each output, bringing each to a separate distribution. The Yeo-Johnson parameters may be defined beforehand when creating the training dataset. The normalized distributions may then be fed into two standard loss functions, for example, two of Huber, mean absolute error, mean squared error, and / or Poisson. The training module 304 may return the average of the two loss functions as a representative loss metric, thereby providing a cleaner balance between typical scenarios and tail optimization.

[0106] Following training, the training module 304 may output a fully trained duration model 308 that is optimized to generate the activity time and travel time.

[0107] Referring to FIG. 3B, the training module 314 may be configured to train a machine learning model 316 to generate an HR model 318. In some embodiments, the machine learning model 316 may have an architecture similar to the machine learning model 306 discussed above in connection with FIG. 3A. 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 overfitting. The training module 314 may utilize a standard mean squared error (MSE) loss during training.

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

[0109] Following training, the training module 314 may output a fully trained HR model 318 optimized to generate the athlete's heart rate and moving heart rate at various points of the activity.

[0110] Referring to FIG. 3C, the training module 324 may be configured to train a machine learning model 326 to generate a max HR model 328. In some embodiments, the machine learning model 316 may have an architecture similar to the machine learning model 306 discussed above in connection with FIG. 3A. For example, the machine learning model 306 may include an architecture of a single dense node layer to achieve a non-linear continuous function. The training module 324 may utilize a special type of quantile-based loss function called pinball loss during training.

[0111] The training module 324 may be configured to train a machine learning model 326 to generate the maximum heart rate of an athlete at various points of an activity based on the time characteristics and environmental characteristics of the activity. In some embodiments, other input data may include, but is not limited to, information regarding the route corresponding to the activity, weather conditions when the activity is performed, athlete information, and the like.

[0112] Following the training, the training module 324 may output a fully trained and optimized max HR model 328 configured to generate the maximum heart rate of an athlete at various points of an activity.

[0113] Referring to FIG. 3D, the training module 334 may be configured to train a machine learning model 336 to generate a normal HR model 338. In some embodiments, the machine learning model 336 may have an architecture similar to the machine learning model 306 discussed above in connection with FIG. 3A. For example, the machine learning model 336 may implement an architecture of a single dense node layer to achieve a non-linear continuous function. The training module 334 may use a custom loss function that returns a Huber loss after transforming the predicted values and actual values through Yo Johnson.

[0114] The training module 334 may be configured to train a machine learning model 336 to generate the heart rate and moving heart rate of an athlete at various points of an activity based on the time characteristics and environmental characteristics of the activity. In some embodiments, other input data may include, but is not limited to, information regarding the route corresponding to the activity, weather conditions when the activity is performed, athlete information, and the like.

[0115] Following the training, the training module 334 may output a fully trained and optimized normal HR model 338 configured to generate the heart rate and moving heart rate of an athlete at various points of an activity.

[0116] Referring to FIG. 3E, the training module 344 may be configured to train a machine learning model 346 to generate a min HR model 348. In some embodiments, the machine learning model 346 may have an architecture similar to the machine learning model 306 discussed above in connection with FIG. 3A. For example, the machine learning model 346 may implement an architecture of a single dense node layer to achieve a non-linear continuous function. The training module 344 may utilize a special type of quantile-based loss function called pinball loss during training.

[0117] The training module 344 may be configured to train a machine learning model 346 to generate an athlete's minimum heart rate at various points of an activity based on time features and environmental features. In some embodiments, other input data may include, but is not limited to, information regarding the route corresponding to the activity, weather conditions when the activity is performed, athlete information, and the like.

[0118] Following training, the training module 344 may output a fully trained min HR model 348 optimized to generate an athlete's minimum heart rate at various points of an activity.

[0119] Referring to FIG. 3F, the training module 354 may be configured to train a machine learning model 356 to generate a seed HR model 358. In some embodiments, the machine learning model 356 may have an architecture similar to the machine learning model 306 discussed above in connection with FIG. 3A. For example, the machine learning model 356 may implement an architecture of two dense node layers with a dropout layer between the two dense node layers to reduce the risk of overfitting. The training module 354 may use a customized loss function that returns a Huber loss after transforming the predicted values and the actual values through a Yeo-Johnson transformation.

[0120] The training module 354 may be configured to train a machine learning model 356 to generate an athlete's heart rate and moving heart rate at various points of an activity based at least on a target average HR of the activity (i.e., effort level). In some embodiments, other input data may include, but is not limited to, information regarding a route corresponding to the activity, weather conditions when the activity is performed, athlete information, and the like.

[0121] Subsequent to training, the training module 354 may output a fully trained seed HR model 358 optimized to generate an athlete's heart rate and moving heart rate. The seed HR model 358 may be the first model used in activity prediction to set an initial HR value at each point of the activity. The seed HR model 358 may be optimized to explore nuances of point-specific shifts in effort throughout the activity (e.g., an increase in effort when transitioning from a flat gradient to an uphill slope, or when shifting from a cool morning weather to a blistering midday heat).

[0122] FIG. 4 is a block diagram showing the prediction system 124 in more detail according to an exemplary embodiment. As shown, the six models created by the training system 122 may be incorporated into or grouped into a prediction model 412 to generate activity predictions. For example, as shown, the prediction system 124 may include a duration model 308, an HR model 318, a max HR model 328, a normal HR model 338, a min HR model 348, and a seed HR model 358.

[0123] In some embodiments, only a subset of the prediction model 412 may be used to generate activity predictions. For example, the prediction system 124 may generate activity predictions using at a minimum, 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 max HR model 328, the normal HR model 338, and the min HR model 348 to determine a range of potential heart rate effort.

[0124] In some embodiments, when a request to generate an activity prediction for a user comes in from the user device 102, the preprocessing 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 route information for the next activity or workout to the preprocessing module 402. In some embodiments, the preprocessing module 402 may receive the details of the route information directly from the user device 102. In some embodiments, the preprocessing module 402 may search for the details of the route information from one or more third-party systems 108 such as Open Street Map, Google maps, etc.

[0125] In some embodiments, the request may further include the time and date of the next workout. The preprocessing module 402 may communicate with one or more third-party systems 108 to receive or search for weather information about the proposed time and date of the next workout.

[0126] 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 process and / or a compression process to prepare the data for input to the prediction model. In some embodiments, the simplification process and / or the compression process may be similar to the simplification process and compression process discussed above in relation to FIG. 3A.

[0127] When the user's effort level is unknown, the activity may be profiled using the max HR model 328, the normal HR model 338, and the min HR model 348. Such a process can obtain a set of predicted activities that are fixed by the minimum and maximum efforts and include the user's normal effort that falls somewhere between the minimum and maximum efforts. Based on the generated maximum effort, minimum effort, and normal effort, the prediction system 124 may generate a stratified set of activity predictions for the user using the duration model 308, the HR model 318, and the seed HR model 358. However, if the user's effort level is known or provided to the prediction system 124, the prediction system 124 may use the duration model 308, the HR model 318, and the seed HR model 358 without the need for the max HR model 328, the normal HR model 338, and the min HR model 348.

[0128] The prediction system 124 may be configured to generate multi-point predictions and single-point predictions using prediction models. The difference between multi-point predictions and single-point predictions is that for chained multi-point activities, since their timestamps and derived feature quantities are used to guide the next iteration of the prediction, these feature quantities can be updated before returning the activity. In contrast, single-point predictions lack the accumulated inter-point context and thus may not be able to update these feature quantities.

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

[0130] Figure 5 is a flowchart showing a method 500 for generating an estimated activity file for a user according to an exemplary embodiment. Method 500 may begin at step 502.

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

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

[0133] In step 506, the backend computing system 104 may determine whether the request includes a target heart rate for the activity or workout. In step 506, if the prediction system 124 determines that the request does not include a target heart rate, method 500 may proceed to step 508.

[0134] In step 508, the back-end computing system 104 may predict the user's normal heart rate, maximum heart rate, and minimum heart rate based on the time characteristics and environmental characteristics of the activity. For example, the prediction system 124 may use the max HR model 328 to generate the user's maximum heart rate based on time information and terrain information. The prediction system 124 may further use the min HR model 348 to generate the user's minimum heart rate based on time information and terrain information. The prediction system 124 may further use the normal HR model 338 to generate the user's normal heart rate based on time information and terrain information. The generated minimum heart rate, maximum heart rate, and normal heart rate may be used instead of the target heart rate to generate a predicted activity file for the workout or activity.

[0135] In step 510, the back-end computing system 104 may generate the athlete's initial or seed heart rate and initial or seed movement heart rate at each point of the activity. For example, based at least on the target average HR (i.e., effort level) of the activity, or the minimum heart rate, maximum heart rate, and normal heart rate (if the target average heart rate is not provided), the seed HR model 358 may generate the initial estimated heart rate and initial movement heart rate at each point of the activity or workout.

[0136] In step 512, the back-end computing system 104 may generate the estimated duration of each point of the workout or activity. For example, based on the initial heart rate data generated by the seed HR model 358, the duration model 308 may generate the activity time (e.g., movement time + recovery time) and movement time for the workout or activity at each point of the workout or activity.

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

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

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

[0140] FIG. 6A shows the system bus architecture of a computing system 600 according to an exemplary embodiment. System 600 may represent at least a portion of user device 102 and / or backend computing system 104. One or more components of system 600 may communicate electrically with each other using bus 605. System 600 may include a system bus 605 that couples various system components, including a processing unit (CPU or processor) 610, and a system memory 615 including read-only memory (ROM) 620 and random access memory (RAM) 625, to processor 610. System 600 may include a cache of high-speed memory that is directly connected to, in proximity to, or incorporated as part of processor 610. System 600 may copy data from memory 615 and / or storage device 630 to cache 612 for quick access by processor 610. In this way, cache 612 can achieve a performance boost that avoids latency in processor 610 while waiting for data. These and other modules may be configured to control or be controlled by processor 610 to perform various actions. Similarly, other system memory 615 may be available for use. Memory 615 may include multiple different types of memory with various 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 and configured to control processor 610, as well as dedicated processors in which software instructions are incorporated into the actual processor design. Processor 610 may primarily be a fully self-contained computing system including multiple cores or processors, buses, memory controllers, caches, etc. The multi-core processor may be symmetric or asymmetric.

[0141] To enable user interaction with the computing system 600, the input device 645 may represent any number of input mechanisms such as a microphone for voice, a touch screen for gesture or graphical input, a keyboard, a mouse, motion input, voice, etc. Similarly, the output device 635 may be one or more of a number of output mechanisms known to those skilled in the art. In some cases, a multimodal system may be enabled to provide multiple types of input for a user to communicate with the computing system 600. The communication interface 640 can generally orchestrate and manage user input and system output. Since it is not restricted to operating on any particular hardware configuration, the basic features here can be easily exchanged for those when an improved hardware or firmware configuration is developed.

[0142] The memory device 630 may be non-volatile memory, a hard disk, or other types of computer-readable media such as magnetic cassettes, flash memory cards, solid-state memory devices, digital versatile disks, cartridges, random access memory (RAM) 625, read-only memory (ROM) 620, and their hybrids that can store data accessible by a computer.

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

[0144] FIG. 6B shows a computer system 650 having a chipset architecture that can represent at least a portion of the user device 102 and / or the backend computing system 104. The computer system 650 may be an example of computer hardware, software, and firmware that can be used to implement the disclosed techniques. The system 650 may include a processor 655 that represents any number of physical and / or logically distinct resources capable of executing software, firmware, and hardware configured to perform the specified calculations. The processor 655 may communicate with a chipset 660 that can control inputs and outputs to and from the processor 655. In this example, the chipset 660 may output information to an output 665 such as a display and may read and write information to a storage device 670 that may include, for example, a magnetic medium or a solid state medium. The chipset 660 may also read and write data to a storage device 675 (e.g., RAM). A bridge 680 may be provided to interface with the chipset 660 to interface with various user interface components 685. Such user interface components 685 may include, for example, a keyboard, a microphone, touch detection and processing circuitry, a pointing device such as a mouse, and the like. In general, inputs to the system 650 may come from any of a variety of sources, machine-generated and / or human-generated.

[0145] The chipset 660 may also interact with one or more communication interfaces 690, which may have various 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 for generating, displaying, and using the GUIs disclosed herein may involve receiving an ordered data set via a physical interface or may be generated by the machine itself by the processor 655 analyzing data stored in the storage device 670 or the storage device 675. Further, the machine may receive input from a user through the user interface component 685 and perform appropriate functions such as a browsing function by using the processor 655 to interpret these inputs.

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

[0147] The above is directed to embodiments described in this specification, but other additional 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 stored on various computer-readable storage media. Exemplary computer-readable storage media include, but are not limited to, (i) non-writable storage media in which information is permanently stored (e.g., read-only memory (ROM) devices in a computer such as a CD-ROM disk readable by a CD-ROM drive, flash memory, ROM chips, or any type of solid-state non-volatile memory), and (ii) writable storage media in which modifiable information is stored (e.g., a floppy disk in a disk drive, a hard disk drive, or any type of solid-state random access memory). Such a computer-readable storage medium becomes an embodiment of the present disclosure when carrying computer-readable instructions that direct the functions of the disclosed embodiment.

[0148] Those skilled in the art will appreciate that the foregoing examples are illustrative and not limiting. All substitutions, enhancements, equivalents, and improvements thereto will be apparent to those skilled in the art from a reading of this specification and a study of the drawings, and it is intended that they be included within the true spirit and scope of the present disclosure. Accordingly, the following appended claims are intended to cover all such modifications, substitutions, and equivalents that fall within the true spirit and scope of these teachings.

Claims

Claim 1 Receiving, by a computing system, a request from a user device to generate an estimated activity profile for a user of the user device for a workout; Identifying, by the computing system, route information for the workout, the route information including at least one data point associated with the route information; Generating, by the computing system, an initial estimated heart rate for the user for the at least one data point in the route information based on a personalized training process for the user via a trained prediction system; Generating, by the computing 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 via the trained prediction system; Generating, by the computing system, an expected heart rate for the user during the workout based on the initial estimated heart rate of the user and the generated duration via the trained prediction system; Outputting, by the computing system, the estimated activity profile corresponding to the workout based on the expected heart rate of the user, the estimated activity profile including the expected heart rate of the user A method comprising. Claim 2 Further comprising, by the computing system, determining that the request includes a target heart rate for the workout, The method according to claim 1, wherein generating the initial estimated heart rate of the user is further based on the target heart rate for the workout. Claim 3 Determining, by the computing system, that the request does not include a target heart rate for the workout; Generating, by the computing system based on the request, a normal heart rate, a maximum heart rate, and a minimum heart rate of the user based on a time feature amount and / or a terrain feature amount associated with the workout; The method according to claim 1, further comprising. Claim 4 The method according to claim 1, wherein the route information includes at least a second data point associated with the route information.

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

6. outputting, by the computing system, the estimated activity profile corresponding to the workout based on the predicted heart rate of the user; The method according to claim 5, wherein generating the estimated activity profile includes the estimated activity profile including 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. determining, by the computing system, that the workout is a multi-point workout; simplifying and compressing, by the computing system based on the determination, the route information associated with the workout; The method according to claim 1, further comprising:

8. A non-transitory computer-readable medium including one or more instruction sequences, which when executed by a processor, cause a computing system to: receive, by the computing system, a request from a user device to generate an estimated activity profile for a user of the user device for a workout; identify, by the computing system, route information for the workout, the route information including at least one data point associated with the route information; The computing system generates an initial estimated heart rate of the user for the at least one data point in the route information based on a personalized training process for the user via the trained prediction system. The computing system generates 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 the time and date of the workout via the trained prediction system. The computing system generates an expected heart rate of the user during the workout based on the initial estimated heart rate of the user and the generated duration via the trained prediction system. The computing system outputs the estimated activity profile corresponding to the workout based on the expected heart rate of the user, the estimated activity profile including the expected heart rate of the user. A non-transitory computer-readable medium that causes an operation including the above to be executed.

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

10. The computing system determines that the request does not include a target heart rate for the workout. Based on the request, the computing system generates a normal heart rate, a maximum heart rate, and a minimum heart rate of the user based on a time feature amount and / or an environmental feature amount associated with the workout. The non-transitory computer-readable medium according to claim 8, further including the above.

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

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

13. The computing system outputs the estimated activity profile corresponding to the workout based on the predicted heart rate of the user. The non-transitory computer-readable medium according to claim 12, wherein generating the estimated activity profile includes the predicted heart rate of the user at at least one data point and the second predicted heart rate of the user at at least a second data point.

14. The computing system determines that the workout is a multi-point workout. Based on the determination, the computing system simplifies and compresses the route information associated with the workout. The non-transitory computer-readable medium according to claim 8, further comprising:

15. A system, comprising: a processor; a memory having programming instructions stored thereon, wherein when the programming instructions are executed by the processor, the system: receives a request from a user device to generate an estimated activity profile for a user of the user device for a workout; identifies route information for the workout, the route information including at least one data point associated with the route information; generates an initial estimated heart rate of the user for the at least one data point in the route information based on a personalized training process for the user via a trained prediction system; Generating 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 the time and date of the workout via the trained prediction system; Generating an expected heart rate of the user during the workout based on the initial estimated heart rate of the user and the generated duration via the trained prediction system; Outputting the estimated activity profile corresponding to the workout based on the expected heart rate of the user, wherein the estimated activity profile includes the expected heart rate of the user; A memory for executing operations including; A system comprising. **Claim 16** The operations further include: Determining that the request includes a target heart rate for the workout; The system according to claim 15, wherein generating the initial estimated heart rate of the user is further based on the target heart rate for the workout. **Claim 17** The operations include: Determining that the request does not include a target heart rate for the workout; Generating the normal heart rate, maximum heart rate, and minimum heart rate of the user based on time features and / or environmental features associated with the workout based on the request. The system according to claim 15, further comprising. **Claim 18** The system according to claim 15, wherein the route information includes at least a second data point associated with the route information. **Claim 19** The operations include: Generating a second duration of a second portion of the workout based on the at least second data point in the route information and second environmental information associated with a second time and the date of the workout via the trained prediction system; Generating a second expected heart rate of the user during the workout based on the initial estimated heart rate of the user, the generated duration, and the generated second duration via the trained prediction system. The system according to claim 18, further comprising. **Claim 20** Outputting the estimated activity profile corresponding to the workout based on the expected heart rate of the user is The system according to claim 19, comprising generating the estimated activity profile, the estimated activity profile including 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