A 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 Jun. 24, 2022, the entire content of which is incorporated herein by reference.

[0002] The present disclosure generally relates to systems and methods for predicting individual 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 and 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, methods are disclosed herein. A computing system receives a request from a user device to generate an estimated activity profile for the 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 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, via a trained prediction system. The computing system generates the 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, via the trained prediction system. The computing system generates the expected heart rate of the user during the workout based on the user's initial estimated heart rate and the generated duration, via the trained prediction system. 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, non-temporary computer-readable media are disclosed herein. The non-temporary computer-readable media comprises one or more instruction sequences, which, when executed by a processor, cause a computing system to perform an operation. The operation includes the computing system receiving a request from a user device to generate an estimated activity profile about the user of the user device for a workout. The operation further includes the computing system identifying route information about the workout. The route information includes at least one data point associated with the route information. The operation further includes the computing system generating 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, via a trained prediction system. The operation further includes the computing system generating the 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, via the trained prediction system. The operation further includes the computing system generating an expected heart rate for the user during the workout based on the user's initial estimated heart rate and the generated duration, via the trained prediction system. The operation further includes 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 memory. The memory has programming instructions stored thereon, which, when executed by the processor, cause the system to perform an operation. The operation includes receiving a request from a user device to generate an estimated activity profile about the user of the user device for a workout. The operation further includes identifying route information for the workout. The route information includes at least one data point associated with the route information. The operation further includes generating 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 via a trained predictive system. The operation further includes generating the 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 via the trained predictive system. The operation further includes generating the expected heart rate of the user during the workout based on the user's initial estimated heart rate and the generated duration via the trained predictive system. The operation further includes 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 predicted heart rate. [Brief explanation of the drawing]

[0007] To allow for a more detailed understanding of the features of this disclosure described above, a more specific description of this disclosure, which is briefly summarized above, can be obtained by reference to embodiments, some of which are shown in the accompanying drawings. However, it should be noted that the accompanying drawings only illustrate typical embodiments of this disclosure, and therefore, since this disclosure may allow for other similarly effective embodiments, such drawings should not be considered as limitations on the scope of this disclosure.

[0008] [Figure 1] This is a block diagram showing an exemplary computing environment according to an exemplary embodiment.

[0009] [Figure 2A] This is a block diagram showing a pretreatment system according to an exemplary embodiment.

[0010] [Figure 2B] This block diagram shows the verified data pipeline of the preprocessing system in Figure 2A, according to an exemplary embodiment.

[0011] [Figure 2C] This is a block diagram showing the unverified data pipeline of the preprocessing system in Figure 2A, according to an exemplary embodiment.

[0012] [Figure 3A] This is a block diagram showing a training system according to an exemplary embodiment.

[0013] [Figure 3B] This is a block diagram showing a training system according to an exemplary embodiment.

[0014] [Figure 3C] This is a block diagram showing a training system according to an exemplary embodiment.

[0015] [Figure 3D] This is a block diagram showing a training system according to an exemplary embodiment.

[0016] [Figure 3E] This is a block diagram showing a training system according to an exemplary embodiment.

[0017] [Figure 3F] This is a block diagram showing a training system according to an exemplary embodiment.

[0018] [Figure 4] This block diagram shows a prediction system according to an exemplary embodiment.

[0019] [Figure 5] A flowchart showing a method for generating an estimated activity file for a user according to an exemplary embodiment.

[0020] [Figure 6A] A block diagram showing a computing device according to an exemplary embodiment.

[0021] [Figure 6B] A block diagram showing a computing device according to an exemplary embodiment.

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

Best Mode for Carrying Out 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, and the like.These conventional approaches are limited in that they have not been able to have an overall and personalized perspective when estimating the fitness of each athlete.

[0024] One or more techniques described herein utilize machine learning approaches to analyze relevant metrics from activity tracking devices to predict fitness performance for an activity or workout, while improving upon conventional approaches by controlling for the effects of multivariate factors such as physical environment, weather, training load, and physiological limitations such as age. 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 location coordinates associated with the activity or workout.

[0025] Figure 1 is a block diagram showing an exemplary computing environment 100 according to an exemplary 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 that communicate via a network 105.

[0026] Network 105 may be any suitable type, including individual connections over the Internet, such as cellular or Wi-Fi networks. 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. Because the information transmitted may be personal or confidential, for security reasons, one or more of these connection types may be specified to be protected by encryption or other means. However, in some embodiments, the information transmitted may not be so personal, in which case the network connection may be selected based on convenience rather 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 other suitable connections that enable components in the computing environment 100 to send and receive information between components of the 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 a Bluetooth connection, but is not limited to these.

[0029] In operation, when a user utilizes the fitness tracking device 106, the fitness tracking device 106 may be configured to record the user's movement during activity. In some embodiments, the fitness tracking device 106 may record various data and store that data in a file corresponding to the activity or workout. 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 movement during the activity or workout. In some embodiments, the various data in the file may further include, but are not limited to, one or more metrics associated with the workout, such as altitude, heart rate, gait, and device temperature. In some embodiments, one or more metrics may be associated with each set of coordinate information. For example, assuming that the activity file contains three sets of coordinates (lat1, long1), (lat2, long2), and (lat3, long3), each set of coordinates may include a set of metrics associated with it (e.g., altitude, heart rate, gait, 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 XLM format, a Keyhole Markup Language format, or the like.

[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 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 standalone 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, 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 run 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 can access and view their own estimated fitness performance generated by the backend computing system 104 for their next activity or workout. Through the application 112, the user can further access and view their past fitness performance maintained by the backend computing system 104.

[0033] The content displayed by the user device 102 may be sent from the web client application server 114 to the user device 102 and then processed by the application 112 for display through the graphical user interface (GUI) of 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 the user's fitness performance for the next activity or workout based on the user's past activity data. For example, given details of the 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 consist of one or more software modules. One or more software modules are a set of code or instructions stored in a medium (e.g., the memory of the backend computing system 104) that represent a set of machine instructions (e.g., program code) that perform one or more algorithmic steps. Such machine instructions may be actual computer code that the processor of the backend computing system 104 interprets to perform the instructions, or they may be higher-level coding of instructions that are interpreted to obtain actual computer code. One or more software modules may also include one or more hardware components. One or more aspects of the exemplary algorithm may be executed by the hardware component (e.g., circuit) itself, rather than as a result of instructions.

[0036] The pre-processing 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 pre-processing system 120 may be configured to perform two by-product collections of activity records to be stored in a database. In some embodiments, the activity records may include post-massaging activity records and pre-training activity records.

[0037] The pre-processing system 120 may be configured to generate post-massaging activity records based on raw activity data received from the user device 102 and / or the fitness tracking device 106. The pre-processing system 120 may store the post-massaging activity records for quick retrieval by end users who wish to view the analysis results of their activities via the application 112.

[0038] The preprocessing system 120 may be further configured to generate a train-ready activity record for training the predictive model of the fitness performance system 116. The train-ready activity record may represent an activity record that has been processed by the preprocessing system 120 in a form suitable for direct input into model training, or in a "massaged" state. The train-ready activity record can be directly coupled to newer, first-time activities to update or retrain the model, thus preventing the fitness performance system 116 from performing iterative calculations.

[0039] The training system 122 may be configured to train a predictive model for the fitness performance system 116. In some embodiments, the training system 122 may train the predictive model based on athlete-specific data and athlete-independent data. In this way, the training system 122 can generate a set of robust predictive models based on the collective intelligence of a broader user or athlete community.

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

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

[0042] Figure 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 logs) in a format suitable for training a set of predictive models. For example, the preprocessing system 120 may be configured to annotate the incoming activity data 202 with features relevant to performance modeling.

[0043] The preprocessing system 120 may implement a dual data massage pipeline because missing and / or errors are relatively common in raw activity data. For example, an athlete's chest strap for a heart rate monitor may loosen during training, resulting in invalid heart rate effort data. In another example, inaccurate GPS signals can cause extreme drift in position. Because manufacturers of fitness tracking devices 106 process irregular data points in a black-box manner, resulting in inconsistent data at best and uncorrected data at worst leading to serious consequences, the preprocessing system 120 may clean the raw activity data before model training.

[0044] The preprocessing system 120 may preprocess or massage raw activity data in two pipelines: 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 prediction from unknown sources. In the verified data pipeline 206, verified activities performed by athletes may be considered to originate from the athlete's own authenticated device or from a direct and explicit upload to application 112. As 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. In this way, features of interest available for input to model training can also be viewed by athletes in an isolated context to indicate metrics such as distance, location, weather, and where / when / duration of rests are taken.

[0045] Unlike verified activity data, unverified activity data typically lacks any guarantee of validity regarding timestamps or attribute data (e.g., heart rate) and is intended solely for use in the prediction system 124. Therefore, the preprocessing system 120 may process the unverified activity data using the unverified data pipeline 208.

[0046] In operation, the ingestion module 204 may be configured to determine whether the data is verified or unverified. Activity data may be considered verified data if it is uploaded directly from the athlete's authenticated device or clearly indicated as the athlete's own activity through manual file upload. Unverified data refers to any other activity that has not been verified by the athlete. Verified data may be used to train various predictive models, while unverified data may be used only to massage activity for prediction. Based on the determination, the ingestion module 204 may input a subset of the verified data into the verified data pipeline 206 to generate verified massaged data 210. Similarly, the ingestion module 204 may further input a subset of the unverified data into the unverified data pipeline 208 to generate unverified 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. Core features may include, but are not limited to, timestamps, latitude, longitude, altitude, heart rate, cadence, and device temperature. The raw activity data may also include, but are not limited to, additional attributes such as device information, activity name, activity details, and sport type, and the ingestion module 204 may store such additional attributes as metadata for additional activity contexts, if available. Latitude, longitude, and altitude may be used downstream to construct geolocation polylines representing the traveled path of the activity.

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

[0049] For example, consider an athlete running on a flat road using a barometer-enabled smartwatch to record their activity. Due to the relatively sensitive nature of barometer pressure measurements, slight variations in the centimeter range can be detected as the device's position on the wrist moves up and down, is raised above the head for stretching, or hovers near the ground to tie shoelaces. To account for this, the ingestion module 204 may utilize developer-defined "thresholds." For example, the developer might specify that a 2-meter climb must occur continuously over a distance of 10 meters for it to be added to the total elevation gain.

[0050] For example, suppose the first elevation measurement is taken as the golden reference point, and the upper control limit (UCL) and lower control limit (LCL) can be determined from there by empirically derived fixed distances in meters. As long as the elevation measurement remains within these limits, the ascent and descent of vertical shift are considered zero. However, if one of the two thresholds is exceeded, such as an ascent transition in the case of the UCL or a descent transition in the case of the LCL, the capture module 204 may perform a buffered lookback to find the initial transition point where the ascent or descent began. The capture module 204 may mark the initial transition point as a new reference point. If the capture module 204 cannot find where the change in direction began in the buffered lookback, the capture module 204 may consider the most recent point as the new reference point. Within a given flat, ascent, or descent area, a change relative to a reference point may be considered the vertical movement of an athlete. Furthermore, if the upward or downward zone can transition to a region where the degree of inclination falls below a threshold of approximately horizontal, the intake module 204 may reset that zone to flat.

[0051] Such an approach is not limited to a micro-scale of a few meters (i.e., the variable position of the recording device). Rather, the acquisition module 204 may apply the same methodology on a macro-scale to capture peaks and valleys along the activity course using UCL and LCL set over a larger meter range. Since athletes are more likely to rest at the peaks of peaks than during descents, this is not only useful as an input feature for model training, but it can also quantify the relative prominence between the previous peak / valley and the next peak / valley. In other words, the athlete's patterns regarding effort, rest, etc., can be glimpsed from the prominence of ascents, the relative completion rate along the path, the elevation of the final highest point, and the degree of incline, etc.

[0052] Vertical shifts relative to the horizontal plane can result in variable energy expenditure known as metabolic cost (MC), primarily due to gravity and secondarily due to walking. In this regard, the breakdown of horizontal distance traveled during each ascent and descent is carried over so that the MC can be calculated when the downstream points are tallied.

[0053] In some embodiments, the ingestion module 204 may be further configured to generate derived features. The ingestion module 204 may generate derived features based on core device features and secondary features. Derived features can be broadly categorized into subsets related to heart rate, rest duration, sun altitude and position (daytime, nighttime, sunrise, etc.), speed, and slope gradient. Derived features may also include the sum of three feature sets (e.g., the total horizontal distance traveled so far).

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

[0055] In block 240, the preprocessing system 120 may remove outliers from the activity data. Sensors are generally susceptible to erroneous measurements. The preprocessing system 120 may identify outliers from various data, including, but not limited to, GPS location data, elevation data, speed data, and heart rate data. In some embodiments, if the preprocessing system 120 determines that a feature has been found to be 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 arise if only the HR feature is found to be an outlier. In such embodiments, the preprocessing system 120 may mask the HR feature with a null value instead of purging the entire set of data associated with that point.

[0056] The purpose of purging outliers as a whole is to mitigate their impact on the rest of the activity data, since there is no meaningful way to calculate effective replacement values. The bars used for outlier identification may be kept somewhat conservative to avoid over-removal, and downstream filtering in later stages is expected to smooth out any remaining wrinkles.

[0057] With respect to positional outliers, the preprocessing system 120 may be configured to remove outliers in both the horizontal and vertical planes. The preprocessing system 120 may identify clusters of outlier locations where the location deviates significantly in position and / or distance from the points before and after the cluster, and removing them reduces the total activity distance. In some embodiments, the preprocessing system 120 may use the DBSCAN clustering algorithm to identify clusters.

[0058] With respect to velocity outliers, the preprocessing system 120 may calculate velocity outliers by normalizing the elapsed velocity Poisson distribution through a Yeo-Johnson power transformation. The preprocessing system 120 may then generate alternative velocities 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 velocities greater than the outliers for removal. Since points captured at low intervals are inherently variable and would result in excessive removal, the preprocessing system 120 may use slower alternative velocities as the selection criterion.

[0059] Regarding outliers in heart rate, heart rate monitoring devices are typically susceptible to wireless connectivity and electrode contact loss, resulting in missing data points, sudden drops in measurements, and HR lock-up at the last measurement before the end of activity. In some embodiments, optical heart rate devices are sensitive to light contamination and may enter a lock-up phase relative to the athlete's running pace, potentially resulting in abnormally high values ​​or values ​​that are incorrectly locked for extended periods. The preprocessing system 120 may identify clusters of locked values ​​where the measurements may remain unchanged across a minimum number of consecutive samples. In some embodiments, the preprocessing system 120 may identify clusters using a hierarchical DBSCAN (HDBSCAN) clustering algorithm.

[0060] In block 242, the preprocessing system 120 may smooth the activity data following outlier removal. For example, outlier removal is typically expected to prune most instances of questionable points from the activity record, but the preprocessing system 120 may perform a filtering process to smooth out minor defects related to measurement variability (i.e., noise). However, unlike outlier removal, during the smoothing process, the preprocessing system 120 may replace existing values ​​of features with new values ​​rather than removing 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 resting positions and resting durations 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 resting (i.e., not moving). Such clustering may be used to distinguish the elapsed (i.e., measured) time of activity from potentially shorter-duration travel time, which can be used as an indicator of effort. In some embodiments, the preprocessing system 120 may identify clusters using the DBSCAN clustering algorithm or an inertial measurement unit (IMU).

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

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

[0064] With regard to road and trail network annotation, road and trail networks can be a useful source of activity metadata. The preprocessing system 120 may be configured to store the road and trail network in a graph represented by a set of nodes (vertices / junctions) and edges (node ​​pairs). The graph can not only hold attributes about surface conditions (e.g., paved / unpaved) indicating how fast an athlete can move, but can also describe the complexity of the surrounding environment, and even the places and durations in which an athlete may rest voluntarily or involuntarily. However, unlike vehicle travel, which is mostly linear, human-powered activities can appear relatively unstable in comparison, requiring a series of inferences about the road network to assign correct usage. The inferred set of features provides information about surface types (e.g., road vs. trail), road junctions (e.g., traffic signals), trail junctions, and transition nodes between surfaces (e.g., change from paved street to trail). In some embodiments, the preprocessing system 120 may capture the type of each junction and a globally unique identifier for each junction.

[0065] Exemplary paved annotations may include, but are not limited to, paved surfaces, asphalt, chip seals, concrete, concrete lanes, concrete plates, paving stones, cobblestones, uncut cobblestones, cobblestones, metal, wood, etc. Exemplary unpaved annotations may include, but are not limited to, unpaved surfaces, compacted surfaces, fine gravel, gravel, rocks, pebbles, ground, loose soil, soil, grass, grass paving, mud, sand, wood chips, salt, etc.

[0066] Points of interest (POI) annotation can identify locations where activity records approach artificial landmarks or natural features. The presence of these POIs may hold attributes related to the athlete's speed or rest periods, and is particularly likely to indicate the location of unusually long rest periods.

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

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

[0069] Figure 2C is a block diagram showing in more detail an unidentified data pipeline 208 according to an exemplary embodiment. As shown, the unidentified data pipeline 208 may include a number of operations performed by the preprocessing system 120.

[0070] In block 260, the preprocessing system 120 may remove athlete-specific metrics from unverified 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 might contaminate the prediction seed conditions or confuse the user. Such a process is performed because such metrics may not be practical in guaranteeing the source of the activity. For example, the activity data may be generated by different individuals.

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

[0072] In block 264, the preprocessing system 120 may remove outliers from the activity data. Sensors are generally susceptible to erroneous measurements. The preprocessing system 120 may, but is not limited to, identify outliers from various data such as GPS location data and altitude data. Unlike the verified data pipeline 206, the preprocessing system 120 does not have to remove speed outliers or heart rate outliers from the activity data.

[0073] In some embodiments, if the preprocessing system 120 determines that a feature 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 log.

[0074] The purpose of purging the entire set of outliers is to mitigate their impact on the rest of the activity data, as there is no meaningful way to calculate effective replacement values. The bars used for outlier identification may be kept somewhat conservative to avoid over-removal, with the expectation that any remaining wrinkles will be smoothed out in later downstream filtering.

[0075] With respect to 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 excessive distances 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 downstream inputs to activity prediction do not exceed the distance characterization range during model training, as this could reduce the reliability of the prediction. Thus, any single measurement exceeding a predetermined maximum distance may be divided into n equidistant linear segments. This scenario is not uncommon in activity courses drawn on maps, as providers of these services often simplify the course shape as much as possible to reduce the number of points and, consequently, their memory footprint.

[0077] When a single point is divided into multiple points, the preprocessing system 120 may linearly divide the latitude, longitude, and elevation features along the segments. Other features such as HR may be left unmodified because it is unknown what their actual values ​​will be in relation to the division locations, and therefore the assumption becomes invalid.

[0078] Excessive point-to-point distances in athletic activities are usually due to some form of measurement error, long sections where position is not measured (e.g., tunnels), or the athlete pausing the activity and forgetting to resume until they have traveled a certain distance; therefore, such processes do not need to be part of the massage-verified pipeline 206. Such data may not be useful for training predictive models because of the low resolution of the data per meter traveled. Leaving point-to-point distances uncorrected in the massage-verified pipeline 206 allows for statistical analysis to annotate them as outliers 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 typically expected to prune most instances of questionable points from the activity record, but the preprocessing system 120 may perform a filtering process to smooth out minor defects related to measurement variability (i.e., noise). However, unlike outlier removal, during the smoothing process, the preprocessing system 120 may replace existing values ​​of features with new values ​​rather than removing 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 resting location and duration of the rest for a given athlete. For example, the preprocessing system 120 may use a clustering technique to aggregate groups of consecutive timestamp points when the athlete is resting (i.e., not moving). Such clustering may be used to distinguish the elapsed (i.e., measured) time of activity from the time of movement, which can be used as an indicator of effort.

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

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

[0083] With regard to road and trail network annotation, road and trail networks can be a useful source of activity metadata. The preprocessing system 120 may be configured to store the road and trail network in a graph represented by a set of nodes (vertices / junctions) and edges (node ​​pairs). The graph can not only hold attributes about surface conditions (e.g., paved / unpaved) indicating how fast an athlete can move, but can also describe the complexity of the surrounding environment, and even the places and durations in which an athlete may rest voluntarily or involuntarily. However, unlike vehicle travel, which is mostly linear, human-powered activities can appear relatively unstable in comparison, requiring a series of inferences about the road network to assign correct usage. The inferred set of features conveys information about surface types (e.g., road vs. trail), road junctions (e.g., traffic signals), trail junctions, and transition nodes between surfaces (e.g., change from paved street to trail). In some embodiments, the preprocessing system 120 may capture the type of each junction and a globally unique identifier for each junction.

[0084] Exemplary paved annotations may include, but are not limited to, paved surfaces, asphalt, chip seals, concrete, concrete lanes, concrete plates, paving stones, cobblestones, uncut cobblestones, cobblestones, metal, wood, etc. Exemplary unpaved annotations may include, but are not limited to, unpaved surfaces, compacted surfaces, fine gravel, gravel, rocks, pebbles, ground, loose soil, soil, grass, grass paving, mud, sand, wood chips, salt, etc.

[0085] Points of Interest (POI) annotation can identify locations where activity records approach artificial landmarks or natural features. The presence of these POIs may hold attributes related to the athlete's speed or rest periods, and is particularly likely to indicate the location of unusually long rest periods.

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

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

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

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

[0090] In some embodiments, the preprocessing module 302 may be configured to simplify data from the verified data pipeline. For example, the preprocessing module 302 may remove common “oscillations” in the verified massaged data 210 so that the verified massaged data 210 appears reasonably similar to the activities depicted on the map that feature more linear lines. This type of coarse simplification is a delicate task, as the more the activities are simplified, the more difficult it can be to train the model to distinguish between conditions that athletes can perceive.

[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 individual points, the compression may not mean obtaining an exact target distance, but rather aiming for the closest possible target distance without violating the minimum / maximum criteria.

[0092] The most important reason for using randomized distance compression during the model training phase is to reduce the likelihood of the model overfitting. In extreme cases of overfitting, the model provides near-perfect predictions for the trained data, but underperforms even for small deviations, even for feature values ​​within the training range. The next important reason is to allow for dataset scaling, which is the practice of enhancing the diversity of feature inputs (i.e., increasing the size of the sample population) by modifying the same data in various ways. This practice is common in convoluted network networks (CNNs) used in image processing applications to increase the number of unique training samples. Preprocessing module 302 may achieve a similar effect to increasing the number of unique training samples by compressing the activity records into multiple permutations, each following its own grouping distance goal. Preprocessing module 302 may discard duplicate points if they exist.

[0093] A beneficial side effect of compression is that it substantially reduces the number of points, which in turn reduces the memory footprint and eases the computational requirements for model training and model serving (i.e., prediction). Furthermore, compression increases the likelihood that points sent for training will have non-zero rest durations, providing a more generalizable context for when and why this occurs.

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

[0095] In some embodiments, the preprocessing module 302 may further annotate outliers in the dataset. As those skilled in the art will know, there are always points hidden within the data to be fed into model training that do not represent the actual performance and should be removed from consideration. To identify outliers, the preprocessing module 302 may be configured to identify statistical outliers using various methods.

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

[0097] Referring to Figure 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 those skilled in the art will see, the machine learning model 306 can 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 variation of long short-term memory (LSTM) in a recurrent neural network. This is because feedback states can be embedded in the deep neural network, allowing it 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 divide the dataset into three randomized groups consisting of training, validation, and test.

[0100] In some embodiments, the training module 304 may use training groups to iteratively fit batches of features to their respective outputs. In some embodiments, the training module 304 may use validation groups to independently test the fit between each of these iterations (epochs). In some embodiments, the training module 304 and the test groups 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 splitting to prevent the machine learning model 306 from learning similarities sequentially.

[0101] The training-validation-test process allows for the stratification of one or more explicitly requested features, dividing these features equally into three groups based on their proportion to the entire sample population. For example, stratifying each activity (i.e., a unique start timestamp) ensures that an equal portion of its points are allocated to the three groups, reducing the likelihood that activities with many points will overshadow activities with fewer points. For instance, multiple data records associated with an ultramarathon, along with a single short run in the neighborhood, would present a scenario like searching for a needle in a haystack. The training module 304 may perform a similar process to ensure an even distribution of heart rate or moving / non-moving ratios. These stratifications can effectively achieve training diversity.

[0102] In some embodiments, in addition to or as an alternative to stratification, a more narrowly segmented partitioning method known as oversampling may be available. Oversampling isolates the values ​​of features within a specific range into their own partitioning processes, and then randomly combines these training-validation-test groups.

[0103] The training module 304 may be configured to train the machine learning model 306 to generate activity time (e.g., travel time + recovery time) and travel time based, for example, on heart rate data. In some embodiments, other input data may include, but are not limited to, information about the route corresponding to the activity, weather conditions when the activity was performed, athlete information, etc. In some embodiments, the machine learning model 306 may implement a two-dense node layer architecture 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 solves a fundamental problem in multi-output regression modeling that can arise when the output distributions are significantly different. Because one output may have a higher loss than the other, more time will be spent optimizing for the higher loss at the expense of the lower loss. While travel time may be limited to the reciprocal of the minimum human speed, activity time can be at near-zero speed, taking several hours to cover a distance of 100 meters. Therefore, if a standard loss function such as mean squared error, or more appropriately in this case, Poisson, is used, training optimization will inevitably be biased towards activity time.

[0105] A customized loss function may first apply a Yo-Johnson power transformation to both the true and predicted values ​​of each output, bringing their respective distributions closer together. The Yo-Johnson parameters may be defined in advance when the training dataset is created. The normalized distribution may then be fed into two of two standard loss functions, e.g., Hoover, mean absolute error, mean squared error, and / or Poisson. The training module 304 may return the mean of the two loss functions as a representative loss metric, which provides a cleaner balance between typical scenarios and tail optimization.

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

[0107] Referring to Figure 3B, the training module 314 may be configured to train the machine learning model 316 to produce the 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 relation to Figure 3A. In some embodiments, the machine learning model 316 may include a two-dense node layer architecture 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 a machine learning model 316 to generate the athlete's heart rate and moving heart rate at various points in the activity based on one or more of the following: activity time, travel time, cumulative rest time, heart rate at the previous point, etc. In some embodiments, other input data may include, but are not limited to, information about the route corresponding to the activity, weather conditions when the activity was performed, athlete information, etc.

[0109] Following the 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 in the activity.

[0110] Referring to Figure 3C, the training module 324 may be configured to train the machine learning model 326 to produce the 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 relation to Figure 3A. For example, the machine learning model 306 may include a single dense node layer architecture to achieve a nonlinear 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 athlete's maximum heart rate at various points in the activity based on the activity's temporal and environmental features. In some embodiments, other input data may include, but are not limited to, information about the route corresponding to the activity, weather conditions when the activity was performed, athlete information, etc.

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

[0113] Referring to Figure 3D, the training module 334 may be configured to train the machine learning model 336 to produce a typical 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 relation to Figure 3A. For example, the machine learning model 336 may implement a single dense node layer architecture to achieve a nonlinear continuous function. The training module 334 may use a custom loss function that returns the Hoover loss after transforming the predicted and actual values ​​through the Yoh Johnson.

[0114] The training module 334 may be configured to train a machine learning model 336 to generate the athlete's heart rate and moving heart rate at various points in the activity based on the activity's temporal and environmental features. In some embodiments, other input data may include, but are not limited to, information about the route corresponding to the activity, weather conditions when the activity was performed, athlete information, etc.

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

[0116] Referring to Figure 3E, the training module 344 may be configured to train the machine learning model 346 to produce the 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 relation to Figure 3A. For example, the machine learning model 346 may implement a single dense node layer architecture to achieve a nonlinear continuous function. During training, the training module 344 may utilize a special type of quantile-based loss function called pinball loss.

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

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

[0119] Referring to Figure 3F, the training module 354 may be configured to train the 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 relation to Figure 3A. For example, the machine learning model 356 may implement a two-dense node layer architecture 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 the Hoover loss after transforming the predicted and actual values ​​through Yo Johnson.

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

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

[0122] Figure 4 is a block diagram showing a more detailed prediction system 124 according to an exemplary embodiment. As shown, the six models created by the training system 122 may be incorporated into or combined 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 models 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 the range of potential heart rate effort.

[0124] In some embodiments, when a request comes in from the user device 102 to generate activity predictions about the user, the preprocessing module 402 may receive the request. In some embodiments, the request may include details of an activity or workout. For example, the user device 102 may provide the preprocessing module 402 with route information for the next activity or workout. In some embodiments, the preprocessing module 402 may receive the route information details directly from the user device 102. In some embodiments, the preprocessing module 402 may retrieve the route information details from one or more third-party systems 108, such as OpenStreetMap or Google Maps.

[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 retrieve 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 predictive 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 predictive model. In some embodiments, the simplification process and / or compression process may be similar to the simplification and compression processes discussed above in relation to Figure 3A.

[0127] If 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. This process can yield a set of predicted activities, including the user's normal effort, which is fixed at minimum and maximum effort and falls somewhere between the minimum and maximum effort. Based on the generated maximum, minimum, 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 requiring 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 multipoint and singlepoint predictions using a prediction model. The difference between multipoint and singlepoint predictions is that chained multipoint activities can have their timestamps and derived features updated before returning the activity, as these features are used to guide the next iteration of the prediction. Singlepoint predictions, on the other hand, may not be able to update these features because they lack the accumulated interpoint context.

[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 cadence. In this way, the user may be provided with an estimated activity profile based on the next workout.

[0130] Figure 5 is a flowchart illustrating a method 500 for generating an estimated activity file about a user, according to an exemplary embodiment. Method 500 may begin from 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 about the next activity or workout. In some embodiments, the request may include a description 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 retrieve information from one or more third-party systems 108 on request. In some embodiments, the forecasting system 124 may interact with one or more mapping systems on request to retrieve route information about a workout or activity. In some embodiments, the forecasting system 124 may interact with one or more weather systems on request to retrieve weather-related information about a workout or activity.

[0133] In step 506, the backend computing system 104 may determine whether the request includes a target heart rate for an activity or workout. If, in step 506, 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 backend computing system 104 may predict the user's normal heart rate, maximum heart rate, and minimum heart rate based on the activity's temporal and environmental features. For example, the prediction system 124 may use the max HR model 328 to generate the user's maximum heart rate based on temporal 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 temporal 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 temporal and terrain information. The generated minimum, maximum, and normal heart rates may be used in place of the target heart rate to generate a predicted activity file for the workout or activity.

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

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

[0137] In step 514, the backend computing system 104 may generate estimated heart rate and moving heart rate at each point of the activity based on initial heart rate, weather information, and / or duration information. For example, the HR model 318 may be configured to generate estimated heart rate and 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. If the prediction system 124 determines in step 516 that there is no convergence, 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, if the backend computing system 104 determines in step 516 that convergence has occurred, method 500 may proceed to step 518. In step 518, the backend computing system 104 may output an estimated activity file about 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. These metrics may include heart rate, duration, pace, etc.

[0140] Figure 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 a user device 102 and / or a 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 processing unit (CPU or processor) 610 and a system bus 605 that connects various system components to the processor 610, including system memory 615 such as read-only memory (ROM) 620 and random access memory (RAM) 625. System 600 may include a cache of high-speed memory that is directly connected to, adjacent to, or incorporated as part of the processor 610. System 600 may copy data from memory 615 and / or storage device 630 to the cache 612 for rapid access by the processor 610. In this way, the cache 612 can achieve a performance boost that avoids delays in the processor 610 while waiting for data. These and other modules may control or be configured to control the processor 610 to perform various actions. Similarly, other system memories 615 may be available for use. Memory 615 may include multiple different types of memory having various performance characteristics. Processor 610 may include a dedicated processor in which any general-purpose processor and hardware or software modules such as services 1 632, 2 634, and 3 636 stored in a memory device 630, as well as software instructions, are incorporated into the actual processor design and configured to control processor 610. Processor 610 may primarily be a fully self-contained computing system including multiple cores or processors, buses, memory controllers, caches, etc. Multicore processors 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, or voice. Similarly, the output device 635 may be one or more of the many output mechanisms known to those skilled in the art. In some cases, a multimodal system may be made possible to provide multiple types of inputs for the user to communicate with the computing system 600. The communication interface 640 can generally consolidate and manage user inputs and system outputs. Since operation is not restricted to any particular hardware configuration, the basic features described herein can be easily replaced with improved hardware or firmware configurations as they are developed.

[0142] The storage device 630 may be non-volatile memory, or it may be other types of computer-readable media capable of storing computer-accessible data, such as a hard disk, magnetic cassette, flash memory card, solid-state memory device, digital versatile disk, cartridge, random access memory (RAM) 625, read-only memory (ROM) 620, and hybrids thereof.

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

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

[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 GUI disclosed herein may involve receiving ordered datasets via physical interfaces, or may be generated by the machine itself by the processor 655 analyzing data stored in storage device 670 or storage device 675. Furthermore, the machine may perform appropriate functions, such as browsing functions, by accepting input from a user through a user interface component 685 and interpreting these inputs using the processor 655.

[0146] It will be understood that the illustrative systems 600 and 650 may have two or more processors 610 to achieve greater processing power, or may be part of a group or cluster of computing devices networked together.

[0147] While the above applies to embodiments described herein, other further embodiments may be devised without departing from their basic scope. For example, embodiments of the present disclosure may be implemented in hardware, 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 on which information is permanently stored (e.g., read-only memory (ROM) devices in a computer, such as CD-ROM disks readable by a CD-ROM drive, flash memory, ROM chips, or any type of solid-state non-volatile memory), and (ii) writable storage media on which modifiable information is stored (e.g., floppy disks in a diskette drive, hard disk drives, or any type of solid-state random-access memory). Such computer-readable storage media become embodiments of the present disclosure when they carry computer-readable instructions that direct the functions of the disclosed embodiments.

[0148] Those skilled in the art will understand that the examples set forth herein are illustrative and not limiting. Any substitutions, enhancements, equivalents, and improvements thereto will become apparent to those skilled in the art from reading this specification and examining the drawings, and it is intended that they fall within the true spirit and scope of this disclosure. Accordingly, the following appended claims are intended to include any such modifications, substitutions, and equivalents that fall within the true spirit and scope of these teachings.

Claims

1. The computing system receives a request from the user device to generate an estimated activity profile for the user of the user device for workout purposes. The computing system identifies route information for the workout, wherein the route information includes at least one data point associated with the route information. The computing system generates the user's initial estimated heart rate for at least one data point in the route information via a first machine learning model of a trained prediction system by inputting the workout's route information into the first machine learning model and generating the initial estimated heart rate as output from the first machine learning model, wherein the first machine learning model is trained on the user's past activity data to generate the initial estimated heart rate. The computing system generates a predicted duration for a portion of the workout via a second machine learning model of the trained prediction system by inputting one or more of the initial estimated heart rate, the route information, and environmental information associated with the time and date of the workout into the second machine learning model, and generating the predicted duration as the output from the second machine learning model. The computing system generates the predicted heart rate of the user during the workout via a third machine learning model of the trained prediction system by inputting the initial estimated heart rate and the predicted duration into the third machine learning model and generating the predicted heart rate as the output from the third machine learning model. The computing system outputs the estimated activity profile corresponding to the workout, wherein the estimated activity profile includes a predictive metric for the workout generated by the trained predictive system, and the predictive metric includes one or more of the predicted heart rate and predicted duration corresponding to at least one data point. Methods that include...

2. The computing system further includes determining that the request includes a target heart rate for the workout, The method according to claim 1, further comprising generating the user's initial estimated heart rate by inputting the target heart rate into the first machine learning model and generating the initial estimated heart rate as an output from the first machine learning model.

3. The computing system determines that the request does not include the target heart rate for the workout, Based on the above requirements, the computing system generates the user's normal heart rate, maximum heart rate, and minimum heart rate based on the time features and / or terrain features associated with the workout. The method according to claim 1, further comprising:

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 computing system generates a second predicted duration for the second portion of the workout for at least the second data point in the route information via the trained prediction system by inputting the at least second data point in the route information, and second environmental information associated with the second time and date of the workout, into the second machine learning model, and outputting the second predicted duration as a further output from the second machine learning model. The computing system generates a second predicted heart rate for the user during the workout via the trained prediction system by inputting the user's initial estimated heart rate, the predicted duration, and the second predicted duration into the third machine learning model, and generating the second predicted heart rate as a further output from the third machine learning model. The method according to claim 4, further comprising:

6. The computing system outputs the estimated activity profile corresponding to the workout. The method according to claim 5, comprising generating the estimated activity profile, wherein the estimated activity profile further includes the second predicted heart rate of the user at at least the second data point.

7. The computing system determines that the workout is a multi-point workout, Based on the above determination, the computing system simplifies and compresses the route information associated with the workout. The method according to claim 1, further comprising:

8. A non-temporary computer-readable medium containing one or more instruction sequences, wherein, when the one or more instruction sequences are executed by a processor, the computing system... The computing system receives a request from the user device to generate an estimated activity profile for the user of the user device for workout purposes. The computing system identifies route information for the workout, wherein the route information includes at least one data point associated with the route information. The computing system generates the user's initial estimated heart rate for at least one data point in the route information via a first machine learning model of a trained prediction system by inputting the workout's route information into the first machine learning model and generating the initial estimated heart rate as output from the first machine learning model, wherein the first machine learning model is trained on the user's past activity data to generate the initial estimated heart rate. The computing system generates a predicted duration for a portion of the workout via a second machine learning model of the trained prediction system by inputting one or more of the initial estimated heart rate, the route information, and environmental information associated with the time and date of the workout into the second machine learning model, and generating the predicted duration as the output from the second machine learning model. The computing system generates the predicted heart rate of the user during the workout via a third machine learning model of the trained prediction system by inputting the initial estimated heart rate and the predicted duration into the third machine learning model and generating the predicted heart rate as the output from the third machine learning model. The computing system outputs the estimated activity profile corresponding to the workout, wherein the estimated activity profile includes a predictive metric for the workout generated by the trained predictive system, and the predictive metric includes one or more of the predicted heart rate and the predicted duration corresponding to at least one data point. A non-temporary computer-readable medium that enables the execution of actions including [specific actions].

9. The computing system further includes determining that the request includes a target heart rate for the workout, The non-temporary computer-readable medium according to claim 8, further comprising inputting the target heart rate into the first machine learning model and generating the initial estimated heart rate as an output from the first machine learning model, wherein generating the initial estimated heart rate of the user further comprises inputting the target heart rate into the first machine learning model.

10. The computing system determines that the request does not include the target heart rate for the workout, Based on the above requirements, the computing system generates the user's normal heart rate, maximum heart rate, and minimum heart rate based on the temporal and / or environmental features associated with the workout. A non-temporary computer-readable medium according to claim 8, further comprising:

11. The non-temporary 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 predicted duration for the second portion of the workout for at least the second data point in the route information via the trained prediction system by inputting the at least second data point in the route information, and second environmental information associated with the second time and date of the workout, into the second machine learning model, and outputting the second predicted duration as a further output from the second machine learning model. The computing system generates a second predicted heart rate for the user during the workout via the trained prediction system by inputting the user's initial estimated heart rate, the predicted duration, and the second predicted duration into the third machine learning model, and generating the second predicted heart rate as a further output from the third machine learning model. A non-temporary computer-readable medium according to claim 11, further comprising:

13. The computing system outputs the estimated activity profile corresponding to the workout. The non-temporary computer-readable medium according to claim 12, comprising generating the estimated activity profile, wherein the estimated activity profile further comprises the second estimated heart rate of the user at at least the second data point.

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

15. It is a system, Processor and A memory having programming instructions stored thereon, wherein when the programming instructions are executed by the processor, the system Receiving a request from a user device to generate an estimated activity profile for the user of the user device for workout purposes, Identifying route information for the workout, wherein the route information includes at least one data point associated with the route information. The process of generating an initial estimated heart rate for the user for at least one data point in the route information via a first machine learning model of a trained prediction system is performed by inputting the route information of the workout into the first machine learning model and generating the initial estimated heart rate as an output from the first machine learning model, wherein the first machine learning model is trained on the user's past activity data and generates the initial estimated heart rate. The predicted duration of a portion of the workout is generated via a second machine learning model of the trained prediction system by inputting one or more of the initial estimated heart rate, the route information, and environmental information associated with the time and date of the workout into the second machine learning model, and generating the predicted duration as the output from the second machine learning model. The process of generating the user's predicted heart rate during the workout via a third machine learning model of the trained prediction system is performed by inputting the initial estimated heart rate and the predicted duration into the third machine learning model and generating the predicted heart rate as the output from the third machine learning model. Outputting the estimated activity profile corresponding to the workout, wherein the estimated activity profile includes a predictive metric for the workout generated by the trained predictive system, and the predictive metric includes one or more of the predicted heart rate and predicted duration corresponding to at least one data point. To perform an operation that includes memory and A system that includes these features.

16. The aforementioned operation, The request further includes determining that the request includes a target heart rate for the workout, The system according to claim 15, wherein generating the user's initial estimated heart rate further includes inputting the target heart rate into the first machine learning model and generating the initial estimated heart rate as an output from the first machine learning model.

17. The aforementioned operation, Determining that the aforementioned request does not include the target heart rate for the workout, Based on the above requirements, generate the user's normal heart rate, maximum heart rate, and minimum heart rate based on the temporal and / or environmental features associated with the workout. The system according to claim 15, further comprising the above.

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

19. The aforementioned operation, The process of generating a second predicted duration for the second portion of the workout for at least the second data point in the route information via the trained prediction system is performed by inputting the at least second data point in the route information, and second environmental information associated with the second time and date of the workout, into the second machine learning model, and outputting the second predicted duration as a further output from the second machine learning model. The process of generating a second predicted heart rate for the user during the workout via the trained prediction system is performed by inputting the user's initial estimated heart rate, the predicted duration, and the second predicted duration into the third machine learning model, and generating the second predicted heart rate as a further output from the third machine learning model. The system according to claim 18, further comprising:

20. Outputting the estimated activity profile corresponding to the workout, The system according to claim 19, comprising generating the estimated activity profile, wherein the estimated activity profile further comprises the second predicted heart rate of the user at at least the second data point.

Images