Background upgrade migration determination and implementation

Abstract

Migration of a user of a computing device accepting an updated version of a software feature to exclude a previous version of the software feature is implemented without user friction. Telemetry data corresponding to the use of the updated version and the use of the previous version is stored. The telemetry data is evaluated using a trained machine learning model trained using external telemetry data regarding usage of an updated version and usage of a previous version. A migration acceptance value is calculated that indicates whether the user will accept use of the updated version to exclude the previous version. The migration acceptance value is compared to a threshold determined by the trained model. If the migration acceptance value exceeds a threshold, the previous version is excluded from the user profile.

Description

Background Art

[0001] Computer operating systems and applications are often upgraded, for example, often with the goal of providing users with better functionality and ease of use, increased security, or better computer performance. However, sometimes users are familiar with older interfaces, processes, or workflows, and uncoordinated changes to application or operating system interfaces can be difficult to adjust and can impair productivity. Although options are available to adjust settings to return to a previously familiar environment, some users are unaware of these options or do not understand how to manipulate preference settings to adjust their computer environment to return to a more familiar experience. Summary of the invention

[0002] In an example implementation, a method for migrating a user profile of a computing device to an updated version of a software feature to exclude a previous version of the software feature includes the following operations. Storing telemetry data corresponding to use of the updated version of the software feature and use of the previous version of the software feature. Evaluating the telemetry data using a trained machine learning model, the machine learning model being trained using external telemetry data regarding use of the updated version of the software feature and use of the previous version of the software feature. Calculating a migration acceptance value for the user profile based at least in part on the evaluation of the telemetry data using the trained machine learning model. Comparing the migration acceptance value to a threshold determined by the trained machine learning model. In response to the migration acceptance value exceeding the threshold, excluding use of the previous version of the software feature from the user profile.

[0003] This summary is provided to introduce a series of concepts in a simplified form, which will be further described in the following detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The present disclosure will be easily understood through the following detailed description in conjunction with the accompanying drawings.

[0005] It should be understood that the proportions and sizes (relative or absolute) of the various features and elements (and their collections and groupings) and the boundaries, spacings, and positional relationships presented in the accompanying drawings are merely to facilitate the understanding of the various embodiments described herein and, therefore, may not necessarily be presented or illustrated to scale and are not intended to indicate any preference or requirement for the illustrated embodiments and to exclude the embodiments described with reference thereto.

[0006] Figure 1A A schematic diagram of an example graphical user interface with a presentation of a login option is presented.

[0007] Figure 1BA schematic diagram of an example graphical user interface with presentation of control settings for login options is presented.

[0008] Figure 2A A schematic diagram of an example graphical user interface with presentation of a preferred, simplified login option after background migration is presented.

[0009] Figure 2B A schematic diagram of an example graphical user interface with presentation of control settings for login options after background migration is presented.

[0010] Figure 3 A schematic diagram of an example logical system for implementing a background update migration process on a user computing device is presented.

[0011] Figure 4 A flow chart of an example method for implementing a background update migration process on a user computing device is presented.

[0012] Figure 5 A schematic diagram of an example of a computing device on which a background update migration process may be implemented is provided. DETAILED DESCRIPTION

[0013] The update of computer application and operating system can sometimes cause the panic of users, especially when the well-known feature or workflow is changed.Sometimes, users will not immediately recognize, appreciate or understand the benefit of the feature change brought by the update, and prefer to maintain the appearance and feel of the previous feature or the previous environment.Depending on how the software developer chooses to realize the update or upgrade, sometimes provide the option that allows the user to continue to use or restore the computing environment, to present the previous version of the feature or environment for continued use.However, usually, this option for restoring or selecting the form of feature is usually only accessible by browsing the detailed preference or setting menu to find the feature of interest.Some users do not know that this preference option is available at all.Other users find it difficult to navigate through a large number of settings or preferences to identify and change the feature of interest.For these types of users, it is difficult to adopt the change, and it is very difficult to manage the option associated with this feature change, and it can cause major setbacks.

[0014] In some cases, it may be desirable to promote the migration of users to eventually use updated or upgraded features or interfaces. For example, some upgraded features provide higher security for the user's computing environment. However, the previous features can usually provide sufficient security, so it is not necessary to force migration to use updated features, especially if such changes are imposed on users, which will potentially or may cause negative responses from some users. Similarly, if the adoption of the upgraded features leads to improved performance of the computer, but the operation of the computer is sufficient without the feature, the mandatory implementation of such features can be avoided. On the contrary, the updated features can be presented as options for consideration or trial. If, over time, it is determined that the user has tried and actually used the optional feature upgrade more frequently, or has not used the previous version of the feature for a period of time, it may be useful to completely migrate the user to the new feature implementation by automatically removing the option selected between the old feature implementation and the new feature implementation after a period of time and suitable usage patterns. Alternatively, if the user continues to select the previous implementation of the feature, it may be appropriate to maintain the previous implementation option for user selection.

[0015] The following example is presented to help illustrate the above combination Figure 1A-Figure 2B The concept described. In this example, a software developer wishes to encourage computer users to migrate to a new, more secure login or log-in process for accessing a computing device, e.g., an updated operating system that includes a new, more secure log-in protocol. Traditionally, computer users are challenged to enter a valid alphanumeric-symbol password to access a computing device. Recently, biometric identification options (e.g., facial recognition and fingerprint recognition) have become available for user login identification to access a computing device. These methods are considered more secure because the user must be physically present for a biometric scan to unlock the computing device.

[0016] An additional, more secure login option is to use a personal identification number (PIN) (e.g., 4-6 digits). The PIN only unlocks the computing device on which it is physically configured. In some implementations, the PIN acts as a user gesture (like a facial or fingerprint biometric). The PIN does not sync with any remote service, such as a file storage service accessed over the Internet (e.g., "cloud storage" such as OneDrive TM or Drive) or Software as a Service (SAAS) platforms (e.g. 365 or Workspace). The PIN is encrypted and stored on a secure cryptographic processing chip (e.g., a Trusted Platform Module (TPM)) on the computing device. When the correct PIN is entered, the number or gesture unlocks access to the private key stored in the TPM, and the TPM chip sends the encrypted authentication key to log the user into the remote account. The PIN is never transmitted online; it never leaves the specific computing device. Therefore, the PIN can only be used by the person who physically owns the computing device, which provides significant security advantages. For example, if malware on the computing device monitors keystrokes and sends them to a bad actor in a remote location, the bad actor can learn the PIN but cannot do anything with it because he does not physically own the computing device. By relying on asymmetric key cryptography, traditional shortcomings of passwords, such as phishing, replay, and server vulnerabilities, can be mitigated.

[0017] Continuing with the example of the desired login migration, Figure 1A A generic lock screen graphical user interface 102 for logging into a desktop or laptop computing device 100 is presented. In this example, user Jane Doe has upgraded the operating system software of the computing device 100. Upon booting up the computing device 100, she is presented with a typical password entry field 104 on the graphical user interface 102 with a prompt to enter her password. This may be the login option she is most familiar with based on the options available in previous versions of the operating system and any default user settings in the registry of the computing device prior to the operating system upgrade. Below the password entry field 104 is a password recovery or reset selection 106 that provides a link to further actions to recover or reset the user password using other verification methods (e.g., a question challenge to which the user has provided an answer) if the user password is forgotten.

[0018] In addition to the familiar password entry field 104, several additional login options may also be presented available in the graphical user interface 102. These options may be new or somewhat unfamiliar to Jane Doe. For example, such login options may include a facial recognition option 112 if the computing device is equipped with a suitable camera; a fingerprint recognition option 114 if the computing device 100 is equipped with a fingerprint identification device; a PIN entry option 116; and a password entry option 118 that provides the password entry field 104 as depicted. In this implementation, the password entry option 118 is depicted as an option for logging in (even though it is presented as the default option) to allow the user to switch back and forth between options in a familiar static presentation, rather than removing and replacing login options in the interface 102 when selecting different options.

[0019] Depending on whether the computing device 100 is equipped with a biometric reader device capable of capturing the required biometric information, the biometric option may or may not be presented to the user. Additionally, for a user who is updating the operating system software on the computing device 100 but wishes to choose to use the biometric login option, the user will typically have to initially log in using a legacy password and then provide reference biometric information (e.g., a facial image capture or a fingerprint capture) for secure storage on the computing device 100 (e.g., in a TPM chip). Once the reference biometric information is stored, the facial recognition option 112 and / or the fingerprint recognition option 114 are presented as alternative login options. Similarly, if a PIN was not previously stored in the computing device 100 for use as a login option, then after first verifying Jane Doe's identity, Jane Doe is presented with a prompt to provide the desired PIN to log in using the PIN entry option 116.

[0020] In many computer operating systems, users can set a number of preferences and options that control the computing environment. Figure 1B A general device settings interface 120 is depicted, which has menus for many different system and device settings that can be used for customizable configurations. Many users are usually unaware of these device settings options or how to find the device settings interface 120. As depicted, under the account portion 122, a plurality of possible login options are presented as potentially available to the user, for example, a facial recognition option 132, a fingerprint recognition option 134, a PIN option 136, a password entry option 138, a security key option 140 (e.g., for a highly secure commercial enterprise computing environment), and a picture password option 142. As previously mentioned, some of the options may only be available when the user device includes suitable equipment, for example, a camera or fingerprint scanning device for facial recognition. In other implementations, some login options may be activated or deactivated based on administrator or enterprise settings.

[0021] Within the device settings interface 120, the user can select which login options are presented as available on the login page. For example, the user can choose to disable one or more of the login options presented in the device settings interface 120. Figure 1AAs presented, if the picture password login option 142 is disabled, it will not appear as a login option on the graphical user interface 102. Alternatively, the user can select a non-password option, such as the face recognition option 132, the fingerprint recognition option 134, or the PIN option 136, to be presented as a login option or a default login option. Additionally, the user can change the settings of the options. For example, the user can select the password entry option 138 and update the password of the user device. Similarly, the user can select the picture password option 142 and update the password picture to be selected from the collage of pictures, or update the finger swipe picture to be accepted as a password.

[0022] exist Figure 1B 100, which allows the user to upgrade the security of the computing device 100 by presenting only non-password login options for accessing the computing device 100. If the toggle button 126 is moved to the "on" position, both the password entry option 138 and the picture password option 142 will be disabled in response and will not appear as login options on the graphical user interface 102 of the computing device 100.

[0023] Until the user changes the toggle button 126 of the additional security settings option 124, the password entry option 118 will continue to be presented as the default login option, for example, if this is the login option preferred by the user based on the user's past login actions or selections. However, as previously discussed, the user may not be aware of the device settings interface 120 or the option to improve the security of the computing device 100 by selecting a non-password login option. This may be problematic if a goal of an operating system update is to ensure that it provides the best possible security to avoid more serious downstream security vulnerabilities. However, a competing goal may be to provide the user with a computing experience that minimizes user interruption and "friction", for example, an experience that remains simple and comfortable even in the context of feature changes and upgrades.

[0024] In order to promote user adoption of improved software features (in this example, migrating the user login option to a more secure alternative) while minimizing user disruption and friction to achieve such adoption, it may be desirable to continue to offer users the option to select a known, familiar feature (in this case, password login) while presenting other software feature options for selection. In addition to presenting new or alternative software feature options, user education about the benefits of the new feature may be provided occasionally. For example, in Figure 1AIn the context of the lock screen graphical user interface 102 of the present invention, messages can be presented to encourage the user to use alternative login methods and to note that these other options are more secure. User habits can then be monitored over time, and if it is determined that the user is expected to accept new features based on changing habits, the operating system or application can make the desired features the default and remove the option to use less desired features from the presentation to the user. After the initial installation of the software upgrade, the operating system or application can make such changes to the setting preferences without any direct or obvious action by the user to manually change the setting preferences. This is in contrast to typical upgrades, which force changes to the user's options or preferences without notification; in the user experience, the previous features or functions disappear, and the changes can be confusing and frustrating to the user. The goal of the systems and methods disclosed herein is to make such changes or migrations to new features or functions only when the user is likely to feel comfortable with the change.

[0025] Figure 2A and Figure 2B In the previous Figure 1A and Figure 1B This example of feature migration is expanded upon in the context of the login options discussed. For purposes of this example, assume that a user, Jane Doe, has decided to periodically use the PIN login option to access her computing device 200. Her usage has been tracked locally on her computing device 200 for a period of time that satisfies a threshold of reasonable certainty that Jane Doe will not be frustrated if other login options are no longer available to her. Figure 2A In the example of FIG. 2 , a lock screen graphical user interface 202 for user Jane Doe on computing device 200 provides only a PIN login input field 204. The only additional options presented to Jane Doe are a link 206 to reach an alternative secure login option (e.g., facial recognition if a camera is associated with computing device 200), or an opportunity to recover her PIN if she forgets it. Other login options previously presented to Jane Doe on lock screen graphical user interface 202 (such as password login, facial recognition, or fingerprint recognition) will not be presented after the migration. Alternatively, multiple login options can still be presented, with only the less secure login options (e.g., those involving passwords that are no longer in use) removed.

[0026] In this example, Jane has not taken any affirmative action to change the nature of the lock screen graphical user interface 202 of the available login options, but based on her regular primary use of the login options over a sufficiently long period of time, these options have been automatically changed to her preferred security login options, such as PIN login. If Jane prefers to use one of the alternative security login options (e.g., facial recognition or fingerprint recognition), these options can be presented to Jane as the primary security login options after the background migration process is completed. In some implementations, if Jane successfully logs in using any one or more options in the strong authentication mechanism class (such as facial recognition, fingerprint recognition, or PIN), the weaker password authentication mechanism can be automatically removed as an option, leaving a choice between strong authentication mechanisms to log in. In further implementations, if Jane successfully logs in using any one or more options in the strong authentication mechanism class (such as facial recognition, fingerprint recognition, or PIN), the strong authentication mechanism used is presented as a login option.

[0027] To implement background migration of feature updates, one or more applications running in the background collect necessary usage data and compare such usage data to the behavioral model to determine whether migration to the new secure login feature is appropriate. The result of this determination to migrate Jane Doe's login preferences is reflected in Figure 2B 's device settings interface 220. Under the account section 222, the number of possible login options presented as available is reduced. Additional security settings options 224 are presented with a toggle button 226 moved to the "on" position, which upgrades the security of the computing device 200 by presenting only non-password login options for accessing the computing device 200. The selection of the "on" position of the toggle button is not manually performed by Jane Doe. Instead, one or more applications that implement the feature migration update change the registry value of the setting in the background. It is worth noting that no password option is presented as an available login alternative either on the lock screen graphical user interface 202 or in the device settings interface 220; only the more secure methods of facial recognition option 232, fingerprint recognition option 234, PIN option 236, and security key option 240 can be used to change user preferences.

[0028] The method for implementing such frictionless upgrade migration uses a model developed using a broad range of machine learning heuristics combined with a local application running in the background on a computing device to collect user feature usage data and implement migration adjustments. The method identifies characteristics of an existing user population that can be classified as satisfied users of feature upgrades, and uses this information to identify and automatically migrate other users who may accept feature upgrades. For the purposes of this method, "satisfied" users can be understood as users who have migrated to feature upgrades, for example, by regularly selecting feature upgrades from options (including previous versions of features), permanently switching to feature upgrades, or continuing to use feature upgrade options after being automatically switched to feature upgrades (rather than changing settings to return to previous versions of features). A machine learning algorithm implemented on a remote data processing computer (e.g., a data server computer or a mainframe computer) operates on a data set of usage information from existing users ("external telemetry"), which can be used to determine the profile of good background update migration candidates, and build a model for comparison with a single user action. The completed model can be downloaded and saved to the user's computing device, for example, as part of a software or operating system update.

[0029] An algorithm executed on the user's computing device may consider locally collected user data related to the use of the new feature and compare such data to the model constructed by the machine learning algorithm to determine whether the user is likely to accept the permanent feature migration. For example, in the context of secure password migration considered above, data such as the number of successful logins after enabling the non-password login option; the selection of each type of login option; whether the user used the login after the option became available; and whether the user turned off any non-password login options in the settings preferences after enabling can be compared to the model data to determine whether to remove password login as an option. In an alternative embodiment, the collected user data can be sent to a remote computer (e.g., to a server computer over the Internet) for remote comparison with the model, rather than on the user's computing device.

[0030] In an example implementation, data related to feature usage can be collected (e.g., via the Internet) from a large number of computer users, for example, anonymous data collected by operating system or application developers to identify users of software problems. The collected data is stored in a database managed by the software developer who upgraded the feature. A machine learning model is constructed to process the data to determine one or more profiles of good candidates for background migration of feature updates. In an example implementation, the machine learning algorithm can consider the data using a gradient boosting tree and construct a model for determining good migration candidates. A good migration candidate can be a user whose profile closely matches the model profile of a satisfied user of the upgraded feature, for example, the calculated sum of the value or weighted aspects of the user profile exceeds the threshold of the modeled profile of the satisfied user. The user population providing anonymous data can be dynamic (e.g., users who have migrated to feature updates can continue to be a source of new data, for example, considering the case where the user reverts to the previous feature, and users who choose data collection and are later exposed to feature upgrades can also be a source of new data), so that the model can be trained and updated multiple times.

[0031] A portion of the data set provided to the machine learning algorithm may be collected to identify a user profile associated with feature usage information. For example, the following types of device information may be collected: computing device manufacturer; computing device model; number of processor cores; total RAM; processor clock speed; processor manufacturer name; processor identifier; disk type; available disk space; device family; TPM version; TPM manufacturer; form factor (e.g., laptop, desktop, tablet); operating system (OS) (e.g., or ); OS architecture; OS version; secure boot state of the computing device; and other states or hardware configurations. Such computing device hardware and state information may be used to create a portion of a user profile. For example, computing devices with newer / faster chips, greater memory, and updated OS software may be associated with highly experienced computer users who perform significant processing tasks. Alternatively, older computing devices with slower processors, minimal memory, and non-current versions of OS software may be associated with less sophisticated computer users who are less likely to understand how to configure preferences and settings on their computing devices.

[0032] Another portion of the dataset provided to the machine learning algorithm may be external telemetry data collected from multiple users to identify actual user actions and experiences when presented with feature upgrade alternatives. Profiles of users who are likely to be satisfied when migrating to new features may be developed based on analysis of external telemetry data representing their behavioral actions over time when presented with the option of a feature upgrade. For example, returning to the scenario of migration from a less secure password login paradigm to a more secure non-password login paradigm, telemetry data tracking several user behavioral actions over time may be beneficial in a machine learning model used to determine good candidates for background migration. Example telemetry actions for collection may include the following: number of successful authorizations / logins after enabling non-password login options; credentials used (e.g., PIN, facial recognition, fingerprint recognition, password); tracking clicks on alternative "login options" instead of the primary or legacy options; tracking switches from password methods of logging in; tracking whether users are logged in after the feature is enabled; number of login attempts within a defined time period (e.g., days); number of login attempts, unlocks, logins; number of login attempts using each login method (e.g., password, picture password, facial recognition, fingerprint recognition, PIN, etc.) within a defined time period: provider used; number of login errors within a defined time period (e.g., errors due to incorrect PIN, errors due to account disabled, errors due to network, and errors due to "status login failed"); percentage combinations of such attempts and errors; and other similar user data.

[0033] Some computing devices may be operated by multiple users with separate login credentials that are associated with separately stored user profiles and configuration preferences. When a different user logs in on a computing device, the user's profile is accessed to configure the computing environment according to the user's preferences. Thus, on the same computing device, the computing environment or experience of user A may be different from the computing environment or experience of user B. If separate preferences are stored for different users, the background feature migration method described herein may be implemented separately for each user of the computing device.

[0034] However, some features of a computing device may be global and may not be set based on individual user preferences. As a simple example, in the context of a login screen, user A primarily uses a password to log in, but user B has decided to try the presented PIN login option. In implementations where the login interface is presented to all users in the same manner (e.g., the computing device does not "know" which user is accessing the computing device before presenting the login credentials), it may be desirable to combine the login feature usage data for all users of the computing device and make predictions across all users. In this example, background migration to updated features is not implemented until the corresponding model indicates that all of the users of the computing device may be good candidates for background migration of the feature.

[0035] Once the model is built and trained by the machine learning algorithm using external telemetry data, a copy of the model can be deployed to a separate computing device as part of an application or operating system update with new or updated features. Additional software components can also be deployed to the user computing device, which can work together to complete the migration to the new or updated features while deactivating access to the old version of the feature. In some implementations, the software components can utilize standard operating system resources to collect user telemetry data, and process such collected data through the model to determine whether the user is a good candidate for background migration to the updated feature.

[0036] Figure 3 An example configuration of logic components provided on a computing device 300 for determining whether a user is a good candidate for background migration to an updated feature is schematically depicted in FIG. Logic components may be understood as software modules stored in a memory and executed in cooperation with each other by a processor of the computing device 300. The first logic component in this example implementation is an aggregation platform 310 that aggregates telemetry data 312 corresponding to interactions between a user and the user computing device 300 and device profile information 314, such as the hardware component types and configurations of the computing device 300 and their states. An aggregator service component 316 may be deployed on the user computing device 300 to configure the aggregation platform 310 to ingest telemetry data 312 related to user interactions, particularly user interactions with optional feature updates presented with an option to use a previous version of the feature. As described above, the previous version of the feature may be presented as a default option to avoid immediate friction in the user experience. As described above, the aggregation platform 310 may also ingest device profile information 314 of the computing device 300 for creating a robust profile of the user of the computing device 300.

[0037] In the example context of the desired feature migration from password login to non-password login, the aggregation platform 310 can be configured by the aggregator service component 316 to collect telemetry data 312 related to user login activities, such as described above. In one example, the aggregation platform 310 is operable to collect data related to login (e.g., every day) within a predetermined time period. For example, a time period of 7, 14, 21, and 28 days can be collected for model consideration. The selected time period will be the minimum number of days required to collect data before determining whether to migrate the software feature option for the user. In an example implementation, data aggregation continues every day after exceeding the initial time period, thereby maintaining the current window of data, for example, once the retention time period has passed, old data can be cleared. This construction may be desirable when considering whether to migrate users in the background. Therefore, the data input of the model will represent the user's recent behavior and will not be affected by the old behavior, so that a determination will be made when the user may have comfortably adopted the desired feature update by himself.

[0038] Thus, as old events are continually removed and replaced by new events, the aggregator service component 316 can re-aggregate data received from the aggregation platform 310 multiple times (e.g., daily or weekly). In this way, the telemetry data 312 and device information 314 collected by the aggregation platform 310 will include recent user data. The aggregator service component 316 can communicate telemetry data 312 associated with the user's interaction with the migration feature, as well as device information 314, which can provide profile information about the user ingested by the aggregation platform 310. The aggregator service component 316 can store the telemetry data 312 related to the feature and the device profile information 314 within a feature data structure 332 (e.g., stored in the system registry 330 of the computing device 300) to coordinate and associate the telemetry data with the user. In addition, in the case where the computing device 300 is operated by multiple users with different logins, the feature data structure 332 can be configured to identify which user is using the computing device 300 at a particular time and associate the telemetry data in the feature data structure with each discrete user. For example, each user of computing device 300 may have a unique security identifier (SID), which system registry 330 may use to track usage patterns of multiple concurrent users of computing device 300 .

[0039] The second logical component for making a background migration determination can be a prediction engine 320. The prediction engine 320 is operable to interact with a trained model 322 that provides characteristics of users who may be comfortable migrating to an updated feature without desiring to find or return to a previous implementation of the feature. The prediction engine 320 can also ingest aggregated user telemetry data from the feature data structure 332 and process user telemetry data 312 from the computing device 300 through the trained model 322 to determine the likelihood that the user is a good candidate for background migration to a dedicated updated feature. The prediction engine 320 can, for example, compare device profile information 314 based at least in part on the hardware configuration of the user's computing device 300, and telemetry data 312 of the user's interaction with software feature options (e.g., legacy implementations and updated implementations). Prediction engine 320 may score the likelihood of a positive migration experience for each user of computing device 300 based at least in part on aggregated device information 314 and telemetry data 312 from features data structure 332 processed by prediction engine 320 using trained model 322. The score may be stored in features data structure 332 in system registry 330 associated with the user, or, alternatively, may be immediately passed to migration service 340 for further use as described below.

[0040] A task scheduler component 335 may be provided to periodically launch the migration service 340 to determine whether the user is a good candidate for background migration to the updated features. For example, the task scheduler component 335 may be operable to launch the migration service 340 at the end of an aggregation time period (e.g., a 7, 14, 21, or 28 day period). The migration service 340 may launch the prediction engine 320 to ingest the user telemetry data 312 and device profile data 314 in the feature data structure 332, and process the data using the trained model 322. If the score calculated by the prediction engine 320 exceeds a threshold indicating that the user is a good candidate for migration, the migration service 340 as a background operation will automatically configure the updated service 342 by changing any appropriate system preferences to only provide the user with the updated feature options, and to turn off the previous or legacy feature options.

[0041] As described above, for multiple users, the aggregator service component 316 can create a feature data structure 332 for each user of the computing device 300 for storage in the system registry 330. The prediction engine 320 accesses the system registry 330 to obtain the aggregate feature data structure 332 for each user and feeds the trained model 322 to evaluate each user. In the case of multiple users of the computing device 300, the migration service 340 can be configured to migrate to the updated service 342 and deactivate the previous or legacy feature options only when the scores of all users calculated by the prediction engine 320 exceed a threshold indicating that all users are good candidates for migration.

[0042] Migration service 340 may also monitor system registry 330 to determine whether the user has manually reset the feature once migrated to the updated option by migration service 340. If the value corresponding to the state of the feature option in system registry 330 changes to indicate a manual reset of the background migration to the updated feature option, this would indicate that the user does not want the software feature options to be limited to only new or updated features. In this case, migration service 340 may change internal settings to prevent it from attempting background migration of features in the future, even though the user's actual actions may continue to indicate otherwise.

[0043] Figure 4 An algorithm 400 is depicted for determining whether to automatically migrate a feature to an updated feature option based at least in part on a user's habits regarding the feature over a period of time. In one example implementation, the algorithm 400 is composed of the above-described Figure 3 4. The algorithm may be performed by a combination of the components described above. In monitoring operation 402, an algorithm may monitor and identify a user's use of software feature options (e.g., legacy or updated options) within a feature to be migrated over an extended period of time. In collecting operation 404, the user's use of such feature options may be collected, stored, and aggregated as telemetry data for determining whether to migrate a feature from a legacy option to an updated option. In identifying operation 406, a system registry may be queried to identify a user using the feature so that the telemetry data may be associated with each user of the computing device. As discussed previously, multiple users may use the same computing device, and it may be appropriate to keep track of each user's feature usage to perform a separate migration determination or wait for all users to reach an updated feature option usage point to support migration, rather than influencing the habits of multiple users based on average data across all users.

[0044] Next, in accordance with the pre-scheduled guidance operation 408, the task scheduler can guide the migration determination to be made based on the aggregated telemetry data to determine whether background migration of the feature is appropriate. The task scheduler can be set to perform guidance operations periodically after a set time period (e.g., a few days or weeks) to ensure that sufficient telemetry data is available to inform the migration determination. In accordance with the pre-scheduled guidance operation 408, in an instantiation operation 410, the prediction engine can be instantiated and aggregated telemetry data from the use of the feature can be ingested. In an evaluation operation 412, the prediction engine can utilize a trained model to process the telemetry data (e.g., for software feature options and types of users) to determine the user's likely acceptance of background migration to the updated feature.

[0045] In query operation 414, the algorithm may compare the calculated migration acceptance value of the likelihood of migration acceptance to a threshold value based at least in part on a trained model of satisfied users. If the user is considered a good candidate for migration, the algorithm may proceed to migration operation 416, in which features are automatically migrated in the background to present (e.g., solely or primarily) updated feature options for future use. However, if it is determined in query operation 414 that the user is not a good candidate for migration, the status quo of providing previous or legacy feature options is maintained, and the algorithm returns to monitoring operation 402 to continue aggregating telemetry data for future migration determinations. Previous telemetry data outside the time window (e.g., collected before a time period corresponding to the length of the set time period at which the task scheduler is triggered) can be discarded and can be replaced with currently collected data (e.g., on a first-in, first-out basis), thereby making a determination on the telemetry data that the telemetry data indicates the user's recent actions and habits rather than historical trends through further iterations of algorithm 400.

[0046] Figure 5 An example computing device 500 for implementing the features and operations of the described techniques is shown. Computing device 500 may include any network-connected and / or network-capable device, and may be a client device, such as a laptop computer, a mobile phone device, a desktop computer, a tablet computer; a server / cloud computing device; a television; an electronic accessory, such as a video game device; or another electronic computing device with communication capabilities.

[0047] The computing device 500 includes one or more processors 502, a memory 504, and one or more storage devices 510. The memory 504 typically includes volatile memory (e.g., RAM) and non-volatile memory (e.g., flash memory). An operating system 506 is instantiated in the memory 504 and executed by the processor(s) 502. The computing device 500 includes a power supply 512, which is powered by one or more batteries or other power storage sources and provides power to other components of the computing device 500. The power supply 512 can also be connected to an external power source that covers or charges the battery or other power source.

[0048] The storage device 510 of the computing device 500 may include various tangible processor-readable storage media. Tangible processor-readable storage may be any available medium accessible to the computing device 500, and includes volatile and non-volatile storage media, removable and non-removable storage media. Tangible processor-readable storage media do not include communication signals (e.g., the signal itself), and include volatile and non-volatile, removable and non-removable storage media implemented in any method or technology for storing information such as processor-readable instructions, data structures, program modules, or other data. Tangible processor-readable storage media include random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CDROM), digital versatile disk (DVD) or other optical disk storage, cassettes, magnetic tapes, magnetic disk storage, or other magnetic storage devices, or any other tangible media that can be used to store desired information and can be accessed by the computing device 500.

[0049] In the example computing device 500, as Figure 5 As shown, one or more software components 508 (such as firmware, software applications, instruction modules, communication interface drivers, peripheral drivers, etc.) are stored in memory 504 and / or on storage device 510, which can be instantiated by operating system 506 and executed by (multiple) processors 502. Exemplary software applications can include email programs, schedulers, personal information management programs, word processing programs, spreadsheet programs, Internet browser programs, music file management programs, and photo and video file management programs. Storage device 510 may include one or more tangible storage media devices and may store data used by application software, such as telemetry data and trained models, as well as local and globally unique identifiers, requests, responses, and other data, which may be local to computing device 500, or may be remote and communicatively connected to computing device 500.

[0050] The various software components 508 described herein, such as the aggregation platform, service aggregator, task scheduler, migration service, and prediction engine, can be executed by one or more processors 502, which can include a logic machine configured to execute hardware or firmware instructions. For example, the processor 502 is operable to execute instructions that are part of one or more applications, services, programs, routines, libraries, objects, components, data structures, or other logical constructs. Such instructions can be implemented to perform tasks, implement data types, convert the state of one or more components, implement technical effects, or otherwise achieve desired results.

[0051] Aspects of the processor 502 and memory 504 may be integrated together into one or more hardware logic components. For example, such hardware logic components may include field programmable gate arrays (FPGAs), program and application specific integrated circuits (PASIC / ASIC), program specific and application specific standard products (PSSP / ASSP), systems on chips (SOCs), and complex programmable logic devices (CPLDs).

[0052] The terms "module", "program", and "engine" can be used to describe one or more of a hardware component, a software process, or a combination of the two that is implemented to perform a specific function. It will be understood that different modules, programs, and / or engines can be instantiated from the same application, service, code block, object, library, routine, script, application program interface (API), function, etc. Similarly, the same module, program, and / or engine can be instantiated by different applications, services, code blocks, objects, routines, APIs, functions, etc. When merging software, the terms "module", "program", and "engine" can cover single files or groups in executable files, data files, libraries, drivers, scripts, database records, etc. It is understood that a "service" as used herein is an application that can be executed across one or more user sessions. Services can be used for one or more system components, programs, and / or other services. In some implementations, services run on one or more server computing devices.

[0053] The computing device 500 may include a communication interface 514 (e.g., a network adapter) that manages one or more wireless communication circuitry 516 for establishing a connection over a wide area network (WAN) or a local area network (LAN), such as an Ethernet port, a wireless transmitter, a wireless receiver, or a transceiver (i.e., a combined transmitter and receiver), which may be connected to one or more antennas 518 to provide network connectivity (e.g., to mobile phone networks such as LTE and 5G, GPS, Near field sensing) or connected to one or more other devices on the network (e.g., a mobile device, a desktop computer, a laptop computer, or a server). In some embodiments, multiple wireless communication circuit systems 516 and antennas 518 can be used to communicate input and output radio frequency carrier signals over a variety of different frequency bandwidths and utilize different communication protocols. It should be understood that the network connections shown are examples, and other computing devices and structures and protocols for establishing communication links between computing device 500 and other devices can be used.

[0054] The communication interface 514 can provide for the transmission of intangible processor-readable communication signals. In contrast to tangible processor-readable storage media, intangible processor-readable communication signals can embody processor-readable instructions, data structures, program modules, or other data residing in a modulated data signal, such as a carrier wave or other signal transmission mechanism. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in a manner that encodes information in the signal. As an example, intangible communication signals include signals propagated through wired media (such as a wired network or a direct wired connection) and wireless media (such as acoustic, RF, infrared, and other wireless media).

[0055] The computing device 500 may include one or more input devices 520 so that the user can input commands and information (e.g., touch screen interface, keyboard, mouse, microphone). These and other input devices may be coupled to other internal components or modules via one or more device interfaces 522 (such as a serial port interface, parallel port, or universal serial bus (USB)). The computing device 500 may also include a display device 524 (such as an LCD display or LED display), which may be a separate component or may be an integrated display within the touch screen interface. If the touch screen interface is provided as an integration of an input device 520 and a display device 524, software code may be provided with the computing device 500 to adaptively determine the noise level of the digitizer assembly that affects the touch screen interface caused by the integrated display device 524 and other electronic components, thereby allowing the touch screen interface to improve noise removal and better identify touch signals.

[0056] By leveraging machine learning models, the disclosed systems and methods automate the process of finding "good candidates" (as described below) for upgrading features to new, preferred options without relying on explicit user selection. The technique can be a more efficient alternative to other methods of user involvement, including advertising or relying on users to manually find features themselves. By using precise machine learning models tuned for specific feature migration scenarios, users can more efficiently move toward the use of feature upgrades without causing the interruption, confusion, or friction that can occur with the immediate cessation of familiar legacy feature implementations.

[0057] Additionally, by installing previously trained models on a computing device, maintaining all user telemetry data in the computing device, and computing migration determinations on the user device, even users who choose not to share non-personally identifiable information with software developers can be slowly acclimated to receiving updated feature options without sending any information to third parties. User data security and privacy concerns can be fully accommodated with this migration implementation.

[0058] Although this specification contains many specific implementation details, these details should not be interpreted as limitations on any technology or the scope that can be claimed, but rather as descriptions of features that are peculiar to a specific implementation of the specific technology described. Certain features described in this specification in the context of separate implementations may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations. In addition, although features are sometimes described above as acting in the form of certain combinations, and even initially claimed as such, in some cases, one or more features in the claimed combination may be deleted from the combination, and the claimed combination may point to a variant of a sub-combination or a sub-combination.

[0059] In one example implementation, a method for migrating a user profile of a computing device to an updated version of a software feature to exclude a previous version of the software feature includes the following operations. Storing telemetry data corresponding to use of the updated version of the software feature and use of the previous version of the software feature. Evaluating the telemetry data using a trained machine learning model, the machine learning model trained using external telemetry data regarding use of the updated version of the software feature and use of the previous version of the software feature. Calculating a migration acceptance value for the user profile based at least in part on the evaluation of the telemetry data using the trained machine learning model. Comparing the migration acceptance value to a threshold determined by the trained machine learning model. In response to the migration acceptance value exceeding the threshold, excluding use of the previous version of the software feature from the user profile.

[0060] In a related example implementation, the migration acceptance value indicates whether a user corresponding to the user profile will accept use of an updated version of a software feature on a computing device to the exclusion of a previous version of the software feature.

[0061] In a related example implementation, the method further includes aggregating the telemetry data over a period of time prior to evaluating the telemetry data.

[0062] In a related example implementation, the method further includes, in response to the migration acceptance value failing to exceed the threshold, continuing to store the telemetry data for aggregation for another period of time before evaluating the telemetry data.

[0063] In a related example implementation, the method further includes discarding telemetry data collected and stored outside of the current window of the time period.

[0064] In a related example implementation, the method further includes performing the method with respect to an alternate user profile associated with the computing device, wherein the alternate telemetry data of the alternate user profile is distinguishable from the telemetry data of the user profile. The aggregation operation also aggregates the telemetry data of the user profile and the alternate telemetry data of the alternate user profile in combination.

[0065] In a related example implementation, telemetry data and the trained machine learning model are stored locally in memory on the computing device.

[0066] In a related example implementation, the telemetry data includes device profile information corresponding to the computing device.

[0067] In another example implementation, a system for migrating a user profile of a computing device to an updated version of a software feature to exclude a previous version of the software feature includes an aggregation platform, a prediction engine, and a migration service, each of which is stored in a memory of a computing device and executable by a processor of the computing device. The aggregation platform stores telemetry data corresponding to the use of the updated version of the software feature and the use of the previous version of the software feature. The prediction engine evaluates the telemetry data using a trained machine learning model, which is trained using external telemetry data about the use of the updated version of the software feature and the use of the previous version of the software feature. The prediction engine also calculates a migration acceptance value for the user profile based at least in part on the evaluation of the telemetry data using the trained machine learning model. The prediction engine also compares the migration acceptance value to a threshold determined by the trained machine learning model. The migration service responds to the migration acceptance value exceeding the threshold to exclude the use of the previous version of the software feature from the user profile.

[0068] In a related example implementation, the migration acceptance value indicates whether a user corresponding to the user profile will accept use of an updated version of a software feature on a computing device to the exclusion of a previous version of the software feature.

[0069] In a related example implementation, the aggregation platform aggregates the telemetry data for a period of time before the prediction engine evaluates the telemetry data.

[0070] In a related example implementation, in response to the migration acceptance value failing to exceed the threshold, the aggregation platform continues to store the telemetry data for aggregation for another period of time before the prediction engine evaluates the telemetry data.

[0071] In a related example implementation, the aggregation platform discards telemetry data collected and stored outside of the current window of the time period.

[0072] In a related example implementation, the aggregation platform stores alternative telemetry data about an alternative user profile associated with the computing device, wherein the alternative telemetry data of the alternative user profile is distinguishable from the telemetry data of the user profile. The aggregation platform also aggregates the telemetry data of the user profile and the alternative telemetry data of the alternative user profile in combination.

[0073] In a related example implementation, telemetry data and the trained machine learning model are stored locally in memory on the computing device.

[0074] In a related example implementation, the telemetry data includes device profile information corresponding to the computing device.

[0075] In another example implementation, a tangible processor-readable storage medium is embedded with instructions for executing a process on a computing device to migrate a user profile of the computing device to an updated version of a software feature to exclude a previous version of the software feature. Telemetry data is stored on the computing device, corresponding to usage of the updated version of the software feature and usage of the previous version of the software feature. The telemetry data is evaluated using a trained machine learning model, which is trained using external telemetry data regarding usage of the updated version of the software feature and usage of the previous version of the software feature. Based at least in part on the evaluation of the telemetry data using the trained machine learning model, a migration acceptance value for the user profile is calculated. The migration acceptance value is compared to a threshold determined by the trained machine learning model. In response to the migration acceptance value exceeding the threshold, usage of the previous version of the software feature is excluded from the user profile.

[0076] In a related example implementation, the migration acceptance value indicates whether a user corresponding to the user profile will accept use of an updated version of a software feature on a computing device to the exclusion of a previous version of the software feature.

[0077] In a related example implementation, the process also includes aggregating the telemetry data over a period of time prior to evaluating the telemetry data.

[0078] In a related example implementation, in response to the migration acceptance value failing to exceed the threshold, the process further includes continuing to store the telemetry data for aggregation for another period of time before evaluating the telemetry data.

[0079] In a related example implementation, the process also includes discarding telemetry data stored outside of the current window of the time period.

[0080] In a related example implementation, telemetry data and the trained machine learning model are stored locally in memory on the computing device.

[0081] In a related example implementation, the telemetry data includes device profile information corresponding to the computing device.

[0082] The logical operations constituting the implementation of the technology described herein may be alternatively referred to as operations, steps, objects, or modules in different ways. In addition, it should be understood that the logical operations can be performed in any order, wherein operations are added or omitted according to expectations, and whether the operations are marked or identified as optional, unless otherwise explicitly stated or the claim language inherently requires a specific order. Similarly, although operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring such operations to be performed in the specific order shown or in order, or requiring the execution of all operations shown to achieve the desired result. In some cases, the actions described in the claims can be performed in different orders, and still achieve the desired result. In addition, the separation of the various system components in the implementation described above should not be construed as requiring such separation in all implementations.

[0083] The foregoing description, examples, and data provide a comprehensive description of the structure and use of exemplary embodiments of the invention as defined in the claims. Although various embodiments of the claimed invention have been described above with a certain degree of particularity or with reference to one or more separate embodiments, other embodiments using different combinations of elements and structures disclosed herein are contemplated, as other iterations can be determined by ordinary skill based on the teachings of the present disclosure. All that is contained in the foregoing description and shown in the accompanying drawings should be interpreted as merely illustrative of particular embodiments and not restrictive. Changes may be made to the details or structure without departing from the basic elements of the invention as defined in the following claims.

Claims

1. A method of migrating a user profile of a computing device to an updated version of a software feature to exclude a previous version of the software feature, the method comprising: storing telemetry data corresponding to usage of the updated version of the software feature and usage of the previous version of the software feature; evaluating the telemetry data using a trained machine learning model, the trained machine learning model being trained using external telemetry data regarding usage of the updated version of the software feature and regarding usage of the previous version of the software feature; calculating a migration acceptance value for the user profile based at least in part on the evaluation of the telemetry data using the trained machine learning model; comparing the transfer acceptance value to a threshold determined by the trained machine learning model; as well as In response to the migration acceptance value exceeding the threshold, the previous version of the software feature is excluded from use by the user profile.

2. The method according to claim 1, further comprising aggregating the telemetry data for a period of time prior to evaluating the telemetry data; and further optionally Discard telemetry data collected and stored outside the current window of the stated time period. 3 . The method of claim 2 , further comprising, in response to the migration acceptance value failing to exceed the threshold, continuing to store the telemetry data for aggregation for another time period before evaluating the telemetry data.

4. The method according to claim 2, further comprising: performing the method with respect to an alternate user profile associated with the computing device, wherein alternate telemetry data of the alternate user profile is distinguishable from the telemetry data of the user profile; as well as The aggregating operation aggregates in combination the telemetry data of the user profile and the alternate telemetry data of the alternate user profile.

5. The method according to claim 1, wherein The telemetry data and the trained machine learning model are stored locally in memory on the computing device; or The telemetry data includes device profile information corresponding to the computing device; or Both.

6. A system for migrating a user profile of a computing device to an updated version of a software feature to exclude a previous version of the software feature, the system comprising: an aggregation platform stored in a memory of the computing device and executable by a processor of the computing device to store telemetry data corresponding to usage of the updated version of the software feature and usage of the previous version of the software feature; A prediction engine stored in the memory and executable by the processor to evaluating the telemetry data using a trained machine learning model, the trained machine learning model being trained using external telemetry data regarding usage of the updated version of the software feature and regarding usage of the previous version of the software feature; calculating a migration acceptance value for the user profile based at least in part on an evaluation of the telemetry data using the trained machine learning model; as well as comparing the transfer acceptance value to a threshold determined by the trained machine learning model; as well as A migration service is stored in the memory and executable by the processor to exclude the previous version of the software feature from use by the user profile in response to the migration acceptance value exceeding the threshold.

7. The system according to claim 6, wherein The aggregation platform aggregates the telemetry data during a period of time before the prediction engine evaluates the telemetry data; and further optionally The aggregation platform discards telemetry data collected and stored outside of the current window of the time period.

8. The system of claim 7, wherein in response to the migration acceptance value failing to exceed the threshold, the aggregation platform continues to store the telemetry data for aggregation for another time period before the prediction engine evaluates the telemetry data.

9. The system according to claim 7, wherein The aggregation platform stores alternative telemetry data for an alternative user profile associated with the computing device, wherein the alternative telemetry data for the alternative user profile is distinguishable from the telemetry data for the user profile; and The aggregation platform aggregates in combination the telemetry data of the user profile and the alternative telemetry data of the alternative user profile.

10. The system according to claim 6, wherein The telemetry data and the trained machine learning model are stored locally in memory on the computing device; or The telemetry data includes device profile information corresponding to the computing device; or Both.

11. A tangible processor-readable storage medium having embedded therein instructions for executing a process on a computing device to migrate a user profile of the computing device to an updated version of a software feature to exclude a previous version of the software feature, the process comprising: storing, on the computing device, telemetry data corresponding to usage of the updated version of the software feature and usage of the previous version of the software feature; evaluating the telemetry data using a trained machine learning model, the trained machine learning model being trained using external telemetry data regarding usage of the updated version of the software feature and regarding usage of the previous version of the software feature; calculating a migration acceptance value for the user profile based at least in part on the evaluation of the telemetry data using the trained machine learning model; comparing the transfer acceptance value to a threshold determined by the trained machine learning model; as well as In response to the migration acceptance value exceeding the threshold, the previous version of the software feature is excluded from use by the user profile.

12. The tangible processor-readable storage medium of claim 11, wherein the process further comprises aggregating the telemetry data for a period of time prior to evaluating the telemetry data; and further optionally Discard telemetry data stored outside the current window of the time period.

13. The tangible processor-readable storage medium of claim 12, wherein the process further comprises, in response to the migration acceptance value failing to exceed the threshold, continuing to store the telemetry data for aggregation for another time period before evaluating the telemetry data.

14. The tangible processor-readable storage medium of claim 12, wherein the process further comprises: performing the process with respect to an alternate user profile associated with the computing device, wherein alternate telemetry data of the alternate user profile is distinguishable from the telemetry data of the user profile; as well as The aggregating operation aggregates in combination the telemetry data of the user profile and the alternate telemetry data of the alternate user profile.

15. The tangible processor-readable storage medium of claim 11, wherein The telemetry data and the trained machine learning model are stored locally in memory on the computing device; or The telemetry data includes device profile information corresponding to the computing device; or Both.

Images