Patent Description:
<CIT> and <CIT> disclose monitoring a user interaction with an application and adapting the user interface based on the monitored interactions using a neural network.

<CIT> and <CIT> disclose monitoring a user interaction with an application and predict and suggest actions to the user based on the monitored interactions using a neural network.

Disclosed implementations include systems, methods, and logic that support adaptive user interfaces (Uls) for CAx applications.

In one example, a method may be performed, executed, or otherwise carried out by a computing system. The method may include tracking command usage of a CAx application to obtain command usage data for the CAx application; training a machine learning model with the command usage data; obtaining real-time command usage by a user of the CAx application; applying the machine learning model to adaptively transform a UI of the CAx application, including by inputting the real-time command usage of the CAx application to the machine learning model to determine a predicted command based on the real-time command usage; and dynamically updating a selected sub-section of the UI of the CAx application to present the predicted command to the user.

According to the invention, a system may include a CAx tracking engine, a CAx training engine, and a CAx adaptive UI engine. The CAx tracking engine is configured to track command usage of a CAx application to obtain command usage data for the CAx application and the CAx training engine is configured to train a machine learning model with the command usage data. The CAx adaptive UI engine is configured to obtain real-time command usage by a user of the CAx application and apply the machine learning model to adaptively transform a UI of the CAx application. Adaptive transformation of the UI includes inputting the real-time command usage of the CAx application to the machine learning model to determine a predicted command based on the real-time command usage and dynamically updating a selected sub-section of the UI of the CAx application to present the predicted command to the user.

According to the invention, a non-transitory machine-readable medium stores instructions executable by a processor. Upon execution, the instructions causes the processor or a computing system to track command usage of a CAx application to obtain command usage data for the CAx application; train a machine learning model with the command usage data; obtain real-time command usage by a user of the CAx application; apply the machine learning model to adaptively transform a UI of the CAx application, including by inputting the real-time command usage of the CAx application to the machine learning model to determine a predicted command based on the real-time command usage; and dynamically updating a selected sub-section of the UI of the CAx application to present the predicted command to the user.

Certain examples are described in the following detailed description and in reference to the drawings.

Computer-aided technology systems are used across nearly every facet of society to aid in the design, analysis, and manufacture of products. CAx applications are used for design and analysis across a wide array of products, from microscopic biomedical devices, to massive gas turbine blades, to everyday shoe wear, to integrated circuits, to automobile parts, and near countless other product types. To support such diversity in product types, CAx systems are continually increasing in capability and complexity. Modern CAx systems may include thousands to tens-of-thousands of unique commands, many of which are specific to particular industries, product structures, manufacturing processes, or other product-specific parameters.

The complexity of CAx applications can often result in inefficiencies both from a user-standpoint and from a resource-performance standpoint. CAx application user interfaces are traditionally static, requiring specific user configurations to personalize the CAx UI with relevant commands used by a particular user or organization. Moreover, with such an immense library of commands, many users lack the training or knowledge to efficiently identify relevant commands for design and analysis of particular product types. CAx application documentations may describe "best practices" for certain product structures or product domains, but are often times tedious to read, overly complex, and are static in nature. Some solutions like "recently used" command lists, while at times helpful, are incapable of understanding the present context of CAx application use and many times irrelevant to the particular product design or product file that a user is designing.

From a performance standpoint, the complexity of CAx applications may result in inefficient usage of computing resources. As users delve through an immense library of commands for different product designs and analysis, extra computing cycles, power supply, and memory resources are consumed without any actual progress towards product design. Moreover, many CAx commands perform overlapping functions, and inefficient command usage may result in unproductive processor cycles and inefficient memory consumption as compared to other CAx command sequences (e.g., enhanced CAx features released in newer CAx application versions). In some instances, older CAx commands are replaced with updated CAx commands, and such command replacements may result in user error and lost/ineffective user-time due to confusion and misuse. Accordingly, the increasing complexity of CAx applications may result in inefficiencies from both a user standpoint and a computing performance standpoint.

The disclosure herein may provide systems, methods, devices, and logic for adaptive Uls for CAx applications. In particular, the CAx adaptive UI features described herein may dynamically transform selected sub-portions of CAx application Uls to present selected CAx commands predicted to be relevant to a particular context in which a user is using the CAx application. In some implementations, machine learning models are trained using command usage data to allow for UI adaptations on a per-user or per-product basis. Such UI adaptions may take into account the differences in knowledge, style, and preferences of different users, doing so in the context of a product development cycle workflow. As such, the CAx adaptive UI features described herein may be user-centric and intelligently adapt CAx Uls to increase usability, productivity, and the computing performance of CAx computing systems.

These and other benefits and CAx adaptive UI features are described in greater detail herein.

<FIG> shows an example of a computing system <NUM> that supports adaptive Uls for CAx applications. The computing system <NUM> may include a single or multiple computing devices such as application servers, compute nodes, desktop or laptop computers, smart phones or other mobile devices, tablet devices, embedded controllers, and more. In some implementations, the computing system <NUM> implements a CAx tool, application, or program to aid users in the design, analysis, and manufacture of products.

As described in greater detail herein, the computing system <NUM> may support adaptive Uls for CAx applications. By tracking command usage data of different users (both historically and in real-time), the computing system <NUM> may dynamically predict specific commands that a particular user will use at a present state of product design or analysis. The predicted commands may be specific to particular users, specific to CAx product domains (e.g., product types), or specific to specific points in a product design or analysis workflow. In some implementations, the computing system <NUM> may utilize machine learning and trained models to determined predicted commands, adapting a CAx UI in real-time based on tracked user commands to present predicted command sets relevant to the context in which the user uses the CAx application.

As an example implementation, the computing system <NUM> shown in <FIG> includes a CAx tracking engine <NUM>, CAx training engine <NUM>, and CAx adaptive UI engine <NUM>. The system <NUM> may implement the engines <NUM>, <NUM>, and <NUM> (and components thereof) in various ways, for example as hardware and programming. The programming for the engines <NUM>, <NUM>, and <NUM> may take the form of processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the engines <NUM>, <NUM>, and <NUM> may include a processor to execute those instructions. A processor may take the form of single or multi-processor systems, and in some examples, the system <NUM> implements multiple engines using the same computing system features or hardware components (e.g., a common processor or a common storage medium).

In operation, the CAx tracking engine <NUM> tracks command usage of a CAx application to obtain command usage data for the CAx application and the CAx training engine <NUM> may train a machine learning model with the command usage data. In operation, the CAx adaptive UI engine <NUM> obtain real-time command usage by a user of the CAx application and apply the machine learning model to adaptively transform a UI of the CAx application. Adaptive transformation of the UI by the CAx adaptive UI engine <NUM> may include inputting the real-time command usage of the CAx application to the machine learning model to determine a predicted command based on the real-time command usage and dynamically updating a selected sub-section of the UI of the CAx application to present the predicted command to the user.

These and other example CAx adaptive UI features according to the present disclosure are described in greater detail next.

<FIG> shows an example of adaptations to a CAx application UI based on tracked command usage of a user. To aid in describing various CAx adaptive UI features, <FIG> and other figures show an example CAx application UI <NUM> at different points in time.

To support CAx UI adaptations, the CAx tracking engine <NUM> may track command usage of a CAx application. Command usage may refer to any action by a user related to CAx application commands (also referred to herein as CAx commands). A CAx command may include any express operation or function that the CAx application implements. As such, the CAx tracking engine <NUM> may monitor user actions in the CAx application (e.g., mouse clicks or keyboard strikes) to track command usage. Such tracked command usage may include actions with regard to opening CAx files (e.g., an existing file of a specific CAx product type, opening a product template, creating a new product, etc.), which specific CAx commands are performed (e.g., specific product design operations, parameter or configuration setting, etc.), specific UI locations in clicked by a user (e.g., a CAD model face, edge, vertex, command ribbon, etc.), and more. For instance, the CAx application UI <NUM> (snapshot at time t<NUM>) shown in <FIG> depicts a user execution of a sketch command (e.g., setting a dimension value), which the CAx tracking engine <NUM> may track as command usage for the CAx application.

In some implementations, the CAx tracking engine <NUM> tracks command sequences in the CAx application. Given the complex nature of CAx applications, tracked sequences of CAx commands may provide insight into specific workflows, dependencies, and context for various uses of the CAx application. Specific CAx application commands may not be relevant at certain points in a product design or simulation workflow, and command sequences tracked by the CAx tracking engine <NUM> may provide insight into such workflow dependencies.

As an illustrative example, the CAx tracking engine <NUM> may track command sequences that comprise or adhere to workflow dependencies for product reference point/coordinate system setting, geometry sketching, body material fills, manufacturing analysis, fiber simulations, or various other product design or analysis workflows. By tracking command sequences (as opposed to individual commands solely), the CAx tracking engine <NUM> may monitor user and CAx application behavior with greater detail to more precisely predict or suggest CAx commands in dynamic UI adaptations.

The CAx tracking engine <NUM> may provide tracked command usage of the CAx application to the CAx training engine <NUM> as command usage data <NUM>. In some examples, the CAx tracking engine <NUM> processes the raw data of the tracked command usage, e.g., by transforming, normalizing, cleaning, filtering, or encoding the collected command usage prior to provision to the CAx training engine <NUM>. Such processing may be performed by the CAx tracking engine <NUM> according to any number of predetermined parameters specific to learning models that the command usage data <NUM> will be used to train. In that regard, the CAx tracking engine <NUM> may process tracked command usage for the CAx application into training data sets, e.g., according to specifically selected machine learning features.

The CAx training engine <NUM> may use the command usage data <NUM> to train machine learning (ML) models for CAx command prediction. In <FIG>, the CAx training engine <NUM> trains or feeds the ML model <NUM> with the command usage data <NUM>. The ML model <NUM> may implement or provide any number of machine learning techniques to analyze, interpret, and utilize the command usage data <NUM> for command prediction. For instance, the ML model <NUM> may implement any number of supervised, semi-supervised, unsupervised, or reinforced learning models to interpret the command usage data <NUM>. The ML model <NUM> may include Markov chains, context trees, support vector machines, neural networks, Bayesian networks, or various other machine learning components. Any number of machine-learning techniques and capabilities are contemplated herein to analyze and process the command usage data <NUM>. In the example shown in <FIG>, the CAx training engine <NUM> itself implements the ML model <NUM> (e.g., using local resources or as part of the CAx training engine <NUM>). In other examples, the CAx training engine <NUM> may remotely access or interface with an external ML model <NUM>.

Through use of the ML model <NUM>, the CAx training engine <NUM> may, in effect, interpret usage data of CAx commands and CAx command sequences to predict or suggest relevant CAx commands specific to a particular user, particular product, particular workflow (e.g., design, simulation, etc.), or combinations thereof. The CAx tracking engine <NUM> and CAx training engine <NUM> may together operate during a "training mode" to collect command usage data <NUM> to train the ML model <NUM> (e.g., prior to any CAx UI adaptations). During such a training mode, the CAx tracking engine <NUM> may collect and provide command usage data <NUM> for a single or multiple users, for example during a collection time period set by a system administrator or organization. Collected training data (e.g., tracked command usage data) may be used to train and fine-tune the ML model <NUM> for CAx command prediction.

After the ML model <NUM> has been trained during the "training mode", the CAx adaptive UI engine <NUM> may utilize the ML model <NUM> in an "execution mode". During the "execution mode", the ML model <NUM> may be used to determine predicted commands based on real-time command usage by a user of the CAx application. In some implementations, the CAx training engine <NUM> may train the ML model <NUM> in such a manner that the "training" and "execution" modes overlap. The ML model <NUM> may be continually trained in connection with command prediction. Put another way, command prediction by the ML model <NUM> and training of the ML model <NUM> with user command monitoring (including predicted commands) may occur concurrently, and without any prior training of the ML model <NUM>.

CAx commands predicted by the ML model <NUM> may represent particular commands or command sets that a CAx application user can use at the specific use context of the CAx application (e.g., the specific point the user is at in a product development, design, or analysis workflow using the CAx application). In that regard, predicted commands may represent a "solution" generated by the ML model <NUM> to identify relevant CAx commands based on monitored user activity, both in the real-time and from the training sets used to train the ML model <NUM>. In some implementations, predicted commands determined by the ML model <NUM> may include suggested commands for use by the CAx application user as well, some of which may not have been previously tracked by the CAx tracking engine <NUM> or provided as training data to the CAx training engine <NUM>. Thus, instead of a user manually searching via static command libraries for particular CAx commands relevant to a present CAx application context, the CAx adaptive UI engine <NUM> may instead adapt the CAx application UI <NUM> to present any number of predicted commands.

To provide an illustration of dynamic UI adaptation through <FIG>, the CAx adaptive UI engine <NUM> may track real-time command usage of a CAx application, such as in a consistent manner as the CAx tracking engine <NUM>. Then, the CAx adaptive UI engine <NUM> may process tracked real-time command usage of the CAx application into data interpretable by the ML model <NUM> (e.g., in consistent format as the command usage data <NUM>). In <FIG>, the CAx adaptive UI engine <NUM> provides the real-time command usage <NUM> to the CAx training engine <NUM> and the ML model <NUM>, from which the ML model <NUM> may determine a predicted command set (e.g., including the predicted commands <NUM>) based on the monitored user actions.

In some implementations, the predicted commands <NUM> may include a suggested command that deviates from prior user behavior (e.g., as tracked through the command usage data <NUM> during a "training" mode). In particular, the CAx training engine <NUM> may provide specific learning parameters to the ML model <NUM> biased towards improved CAx application efficiency in predicted command determinations.

As an example, the CAx training engine <NUM> may store a command mapping between older UI commands and newer (e.g., enhanced) UI commands. Such enhanced commands may serve as substitutes to mapped older commands, e.g., as released in newer CAx application versions as command enhancements or to effectuate command process changes. An illustrative mapping may specify that the combination of older commandA and older commands can be replaced with newer commandC. Thus, when real-time command usage <NUM> tracked and provided by the CAx adaptive UI engine <NUM> indicates the user is selecting a command sequence that, based on historical data for the user, includes commandA and commands, the CAx training engine <NUM> may instead provide commandC as part of the predicted commands <NUM>. As such, the predicted command <NUM> may take the form of an updated or enhanced command of the CAx application to replace an outdated command identified in the real-time command usage <NUM> by the user. Such command replaces may improve the efficiency and effectiveness of CAx application executions.

The CAx adaptive UI engine <NUM> may dynamically update a selected sub-section of the CAx application UI <NUM> to present the predicted commands <NUM> (e.g., as part of a predicted command set). The selected sub-section may be a marked location in the CAx application UI <NUM>, such as a "predicted" or "suggested" commands ribbon or some other delineated UI space reserved for such dynamic adaptations. In the example shown in <FIG>, the CAx adaptive UI engine <NUM> dynamically transforms the selected sub-section <NUM> of the CAx application UI <NUM> (at a time t<NUM>) to the predicted commands <NUM> (e.g., including the command icon with three connected cubes). Based on continuously monitored real-time command usage of the CAx application, the CAx adaptive UI engine <NUM> may continually adapt and transform the selected sub-section <NUM> of the CAx application UI <NUM> to present sets of predicted command set relevant to a present CAx application context.

In some implementations, the CAx training engine <NUM> continually trains the ML model <NUM> during the "execution" mode based on tracked user feedback with respect to predicted commands presented in the selected sub-section <NUM>. For instance, the CAx adaptive UI engine <NUM> may track user responses to presentation of the predicted commands <NUM> (e.g., whether the user actually uses one or more of the predicted commands <NUM> or selects a non-predicted command). In either case, the CAx adaptive UI engine <NUM> may track a real-time response to the dynamic UI adaptation to present the predicted commands <NUM>, and such monitoring may be provided as additional real-time command usage <NUM> to the CAx training engine <NUM> to further reinforce the ML model <NUM> as well as determine a subsequent predicted command. Put another way, the CAx adaptive UI engine <NUM> and CAx training engine <NUM> may monitor real-time command usage in response to a predicted commands <NUM> to determine a next set of predicted commands. In such a manner, the CAx adaptive UI engine <NUM> (in connection with the ML model <NUM>) may continually adapt the CAx application UI <NUM> according to user behavior and CAx application context (e.g., command usage).

By dynamically updating the CAx application UI <NUM>, the CAx adaptive UI engine <NUM> may transform static UI representations into a dynamic interface (at least at the selected sub-section <NUM>) via continuous monitoring, learning, and feedback. As such, the CAx tracking engine <NUM>, CAx training engine <NUM>, and CAx adaptive UI engine <NUM> may provide a dynamic and adaptive CAx application UI <NUM> that accounts for user knowledge, preferences, and skills. That is, the CAx adaptive UI features may provide user-specific adaptations to improve the experience, usability, and efficiency of CAx applications.

In the example shown in <FIG>, the CAx tracking engine <NUM>, CAx training engine <NUM>, and CAx adaptive UI engine <NUM> may provide CAx UI adaptations on a user-specific basis. For instance, the command usage data <NUM> tracked and used to train the ML model <NUM> may be specific to a particular user of the CAx application. By doing so, the CAx adaptive UI engine <NUM> may obtain predicted commands determined and reinforced specifically for the particular user, and thus adapt the CAx application UI <NUM> specifically to user-preferences, experience, CAx application usage history, and feedback.

While single user UI adaptations are illustrated in <FIG>, a CAx computing system may support user-specific CAx adaptations for multiple users. In some implementations, the CAx training engine <NUM> implements a different machine learning model for each distinct user for which command usage data <NUM> and/or real-time command usage <NUM> is provided. In some implementations, the ML model <NUM> itself may differentiate between different CAx application users by encoding received command usage data <NUM> and/or real-time command usage <NUM> based on the specific user it originated from (e.g., via user IDs or other delineators). As another form of delineation, the CAx tracking engine <NUM>, CAx training engine <NUM>, and CAx adaptive UI engine <NUM> may provide adaptive UI features based on a domain-specific basis, described next with regards to <FIG>.

<FIG> shows, according to the invention, domain-specific adaptations to a CAx application UI based on tracked command usage. A CAx domain refers to any category or type by which a CAx application can differentiate products. CAx domains include product differentiations according to different part templates, part manufacturing processes, industrial application, or other differentiations.

For CAx domains differentiated according to part templates, the CAx application supports creation of product files according to any number of preconfigured or user-customized product templates. The templates may correspond to specific types of products, and configure new products created with template files with specific parameters, configurations, constraints, or other part-specific characteristics. Example part templates include templates for CAD models, assemblies, sheet metal parts, routing (logical, mechanical, or electrical), etc. By differentiating according to template, CAx domain-specific UI adaptations may account for the specific part types that are being designed or analyzed by a CAx application user.

Additionally or alternatively, CAx domains (including part templates) are categorized according to the manufacturing processes used to construct a product. As specific manufacturing processes may ascribe certain limits, characteristics, or requirements for products, CAx domains differentiated according to manufacturing processes may leverage or utilize distinguished sets of CAx commands. Example manufacturing processes which may serve as CAx domains include additive manufacturing (e.g., 3D printing and multi-axis deposition), integrated circuit fabrication, casting (e.g., metal casting), forming, moldings, machining, joining, packaging, mechanical and electrical routing, and more.

Furthermore, in CAx domains, products are differentiated according to industrial application. Examples of such CAx domains may specify the particular industry a product is associated with, such as aerospace, textile industries (e.g., shoe wear or clothing), high-performance computing, energy systems, and many more. While some examples of CAx domains are presented herein, any form of differentiation between products for CAx adaptive Uls is contemplated herein as a possible CAx domain.

The CAx tracking engine <NUM>, CAx training engine <NUM>, and CAx adaptive UI engine <NUM> supports UI adaptations on a CAx domain-specific basis. For instance, the CAx tracking engine <NUM> tracks command usage of the CAx application on a CAx domain-specific basis. To do so, the CAx tracking engine <NUM> classifies tracked command usage to particular CAx domains applicable to tracked command usage.

CAx domain classification may be performed in multiple ways. In some implementations, the CAx tracking engine <NUM> classifies a CAx domain for tracked command usage based on a determined file template applicable to the tracked command usage, e.g., by identifying a "file->open template" command or by parsing metadata of a product file to determine the file template used to create the product file. As another example, the CAx tracking engine <NUM> may classify a CAx domain based on identified product metadata specified with respect to the command usage, such as a product file metadata for which the command usage is tracked. In yet another example, the CAx tracking engine <NUM> may analyze the product itself to determine an applicable CAx domain. For instance, the CAx tracking engine <NUM> may analyze product shape characteristics/features with respect to the command usage to identify a particular industry, template, or other categorization applicable to the product and tracked command usage.

As predicted commands may be provided on CAx-domain specific basis, the CAx tracking engine <NUM> may obtain tracked command usage from multiple different users for the same CAx domain. For instance, multiple users of a CAx application (e.g., within an organization) may use the CAx application to design and analyze products of a specific CAx domain (e.g., automobile engine components) and may do so from physically different locations. The CAx tracking engine <NUM> may obtain the tracked command usage for any number of the multiple users of this specific CAx domain to centrally process, e.g., by providing to the CAx training engine <NUM> to train CAx domain-specific machine learning models.

In <FIG>, the CAx tracking engine <NUM> provides domain-specific command usage data <NUM> to the CAx training engine <NUM>. In such examples, the CAx tracking engine <NUM> may encode or annotate the command usage data <NUM> with any particular CAx domain(s) applicable to the command usage data <NUM>. Example annotations may include CAx domain codes (e.g., '<NUM>' for a additive manufacturing domain, '<NUM>' for a casting domain, etc.) or any other CAx domain indicator.

The CAx training engine <NUM> may support domain-specific machine learning for the command usage data <NUM>. To do so, the CAx training engine <NUM> may implement machine-learning models that differentiate command prediction by CAx domain. In some instances, the CAx training engine <NUM> implements multiple different machine learning models, each of which may be associated with a specific CAx domain. <FIG> illustrates ML models <NUM> and <NUM> (and potentially more) that the CAx training engine <NUM> may implement for different CAx domains. The CAx training engine <NUM> may train the different machine learning models <NUM> and <NUM> for different CAx domains of the CAx application. For example, the CAx training engine <NUM> may provide different, CAx domain-specific training sets respectively to the ML models <NUM> and <NUM>.

The ML models <NUM> and <NUM> may be part of a single machine learning model, such as the ML model <NUM> shown in <FIG> (and also in <FIG> and <FIG>). Such incorporation may be explicit (e.g., as distinctly separate models in a larger model) or via logical differentiation (e.g., by the ML model <NUM> treating/differentiating between command usage data and predicted commands by CAx domain).

The CAx adaptive UI engine <NUM> may adaptively transform the CAx application UI <NUM> on a domain-specific basis. <FIG> shows an example UI adaptation by the CAx adaptive UI engine <NUM> (at a time t<NUM>) that is domain-specific. In doing so, the CAx adaptive UI engine <NUM> may track real-time command usage of the CAx application and provide real-time command usage <NUM> to the CAx training engine (and the ML models <NUM> and <NUM>) that is domain-specific. In that regard, the CAx adaptive UI engine <NUM> may identify a particular CAx domain applicable to the tracked real-time command usage.

In some implementations, the CAx adaptive UI engine <NUM> may classify and encode the real-time command usage <NUM> on a per-CAx domain basis, for example in a consistent manner as the CAx tracking engine <NUM> with respect to the command usage data <NUM>. Accordingly, the CAx training engine <NUM> may select and apply a specific machine learning model trained for particular CAx domain of the real-time command usage <NUM> (the ML model <NUM> in the example shown in <FIG>). As also seen in <FIG>, the CAx adaptive UI engine <NUM> obtains the predicted commands <NUM>, which are CAx domain-specific to the real-time command usage <NUM>, and adapts the selected sub-section <NUM> of the CAx application UI <NUM> accordingly.

By supporting CAx adaptive Uls on a domain-specific basis, the features described herein may increase the accuracy or relevance in which predicted commands and UI adaptations are provided. For instance, the CAx tracking engine <NUM> and CAx training engine <NUM> may utilize tracked command usage from multiple different users on a CAx domain-specific basis to train multiple machine learning models. In that regard, domain-specific CAx UI adaptations may leverage the collected knowledge, use, and expertise of different users for each particular CAx domain. Predicted commands adapted unto the CAx application UI <NUM> for a single (e.g., new) user in a particular CAx domain may encapsulate the expertise of multiple other (e.g., experienced) users for the CAx domain, which may improve the efficiency and usability of the CAx applications.

As described above, the CAx tracking engine <NUM>, CAx training engine <NUM>, and CAx adaptive UI engine <NUM> may support CAx UI adaptations based on tracked command usages, whether acquired during a "training" mode or in real-time during an "execution" mode. Additional or alternative sources of training data for machine learning models may also be leveraged, some of which are described next in <FIG> and <FIG>.

<FIG> shows an example of adaptations to a CAx application UI based on command usage data extracted from a product file. Training data for machine learning models may be acquired specifically for completed products that were previous designed or analyzed with the CAx application.

To illustrate through <FIG>, the CAx tracking engine <NUM> may access the CAx application file <NUM>. The CAx application file <NUM> may include product data for a completed product, which may refer to any product that was previously designed, analyzed, or manufactured. Completed products may thus include, as examples, commercially released product versions, prototype designs, discontinued products, etc..

The CAx application file <NUM> may include data for the completed product <NUM>, such as a CAD model, geometry data, parameters, configurations, and the like. The CAx application file <NUM> may also include history data <NUM> for the completed product <NUM>. The history data <NUM> may specify a log of commands (e.g., geometry operations, parameter setting, etc.) used to create, design, revise, or analyze the completed product <NUM>. Such history data <NUM> may be "incomplete" in the sense that not every single command on the completed product <NUM> is tracked, but may include the command sequence that directly resulted in the version of the completed product <NUM> in the CAx application file <NUM>.

The CAx tracking engine <NUM> may extract the history data <NUM> from the CAx application file <NUM> and parse the history data <NUM> to obtain command usage data for the completed product <NUM>. In particular, the CAx tracking engine <NUM> may determine a command history (e.g., sequence of CAx commands) used for generation of the completed product <NUM>. Such a command history may provide, at least in part, command usage data specific to the completed product <NUM>. The CAx tracking engine <NUM> may process extracted command histories and provide the resulting command usage data <NUM> to the CAx training engine <NUM> as training data for the ML model <NUM>. The command usage data <NUM> may be user-specific or CAx domain-specific, e.g., in a consistent manner as described herein.

By using the command usage data <NUM> as training data, the CAx training engine <NUM> may account for (e.g., "learn" from) command sequences indicative of the expertise, knowledge, and workflow requirements or best practices used to generate the completed product <NUM>. In that regard, the ML model <NUM> may be more fully trained with additional training data based on use of the CAx application prior to a "training" mode. Doing so may increase the accuracy and relevance of predicted commands and CAx UI adaptations based on real-time use of the CAx application.

In <FIG>, the CAx adaptive UI engine <NUM> dynamically updates the selection sub-section of the CAx application UI <NUM> at a time t<NUM>. In doing so, the CAx adaptive UI engine <NUM> may track the real-time command usage for the CAx application, provide the real-time command usage <NUM> to the ML model <NUM>, and obtain the predicted commands <NUM> for UI adaptation. In <FIG>, the ML model <NUM> (and thus the predicted commands <NUM> generated by the ML model <NUM>) accounts for the history data <NUM> and command history for the completed product <NUM>. Predicted command sets from the ML model <NUM> may thus incorporate and account for the knowledge, expertise, preferences, and workflows of completed products.

<FIG> shows an example of CAx application UI based on command usage data extracted from a product file of a different CAx application. In the example of <FIG>, the CAx tracking engine <NUM> may parse and extract product data for products of other, different CAx applications. Such a scenario may occur when an organization transitions to a different CAx application platform, e.g., from use of a prior (source) CAx application to a new (destination) CAx application.

The CAx tracking engine <NUM> may obtain an application file of a source CAx application that is different from the CAx application for which CAx adaptive UI features are implemented for. In <FIG>, the CAx tracking engine <NUM> obtains (e.g., accesses) the source CAx application file <NUM>, which may include product data for a completed product <NUM> and corresponding history data <NUM>. The history data <NUM> may include command history for the completed product <NUM>, but in commands specific to the source CAx application (and thus potentially different, incompatible, or irrelevant to the CAx application and the CAx application UI <NUM>).

The CAx tracking engine <NUM> may extract history data <NUM> from the source CAx application file <NUM>, and the history data <NUM> may include a source CAx command history for generation of the completed product <NUM> included in the source CAx application file <NUM>. To address potential inconsistencies between the source CAx application and the (destination) CAx application, the CAx tracking engine <NUM> may translate source CAx command sequences in the history data <NUM> into a translated command usage data <NUM> for the CAx application.

In some implementations, the CAx tracking engine <NUM> does so by referencing a command mapping between the source CAx application and the (destination) CAx application. The command mapping may be predetermined based on command analyses between the different CAx applications, mapping specific commands from one CAx application to the other. The mappings may expand or condense command sequences based on specific implementation decisions for the different CAx applications. For instance, the source CAx application may include multiple commands to perform a particular action (e.g., create a surface mesh of a CAD model) that the destination CAx application may perform a single or lesser number of CAx commands, or vice versa. The translated command usage data <NUM> may reflect such differences in command implementation, and be in a form of CAx command sequences specific to the (destination) CAx application.

The CAx training engine <NUM> may train the ML model <NUM> using the translated command usage data <NUM>, thus accounting for user knowledge, expertise, and preferences used to generate the completed product <NUM> using the source CAx application. Using such varied forms of training data for the ML model <NUM> may create a more robust, accurate, and effective model to determined predicted command sets, e.g., in a consistent manner as noted above. As such, the CAx adaptive UI engine <NUM> may track and provide real-time usage <NUM> of the CAx application, obtain the predicted commands <NUM> (that account for the history data <NUM> of the source CAx application file <NUM>), and dynamically update the selected sub-section of the CAx application UI <NUM> (at a time t<NUM>) to include the predicted commands <NUM>.

In <FIG>, various examples of machine learning models are presented, including via the ML models <NUM>, <NUM>, and <NUM>. The CAx training engine <NUM> may implement machine-learning model in support of the various CAx adaptive UI features described herein in multiple ways. In some implementations, the CAx training engine <NUM> implements multiple machine-learning models and uses a composite result of the multiple ML models to determine a predicted command. Different ML models may be weighted according to various factors to determine a composite predicted command, such as time-based, user-based, or CAx domain-based weights. As such, the multiple ML models may be trained based on any of the differentiations described herein.

As an example differentiation, the CAx training engine <NUM> may train multiple ML models based on timeframe, and gradually de-emphasize older ML models. To illustrate, the CAx training engine <NUM> may determine to train a new ML model after a timing criteria is satisfied, e.g., threshold amount of time has elapsed or training a current ML model with a threshold number of commands (e.g., after <NUM>,<NUM>+ CAx commands have been learned by the ML model, whether in a "training" or "execution" mode). In some instances, the CAx training engine <NUM> may merge different ML models, such as the 'X' number of trained ML models (e.g., per a specific user or specific CAx domain) with the oldest timeframes. Such merging may prevent unintended biasing of older ML models (and, perhaps in effect, biasing towards more recent tracked command usage of the CAx application), and may be accomplished by merging of context trees or Markov chains used by trained ML models.

In any of the ways described herein, various CAx adaptive UI features may be implemented. While different CAx adaptive UI features are described in separately <FIG>, any of the various described CAx adaptive UI features may be implemented in combination. As such, the CAx tracking engine <NUM>, CAx training engine <NUM>, and CAx adaptive UI engine <NUM> may implement any combination of the features described herein, including on CAx UI adaptations on a per-user basis, per-CAx domain basis, based on tracked command usage of the CAx application, based on CAx application files of one or more CAx applications, and various combinations thereof.

<FIG> shows an example of logic <NUM> that a system may implement to support adaptive Uls for CAx applications. For example, the computing system <NUM> may implement the logic <NUM> as hardware, executable instructions stored on a machine-readable medium, or as a combination of both. The computing system <NUM> may implement the logic <NUM> via the CAx tracking engine <NUM>, the CAx training engine <NUM>, and the CAx adaptive UI engine <NUM>, through which the computing system <NUM> may perform or execute the logic <NUM> as a method to provide adaptive Uls for CAx applications. The following description of the logic <NUM> is provided using the CAx tracking engine <NUM>, CAx training engine <NUM>, and CAx adaptive UI engine <NUM> as examples. However, various other implementation options by the computing system <NUM> are possible.

In implementing the logic <NUM>, the CAx tracking engine <NUM> may track command usage of a CAx application to obtain command usage data for the CAx application (<NUM>) and the CAx training engine <NUM> may train a machine learning model with the command usage data (<NUM>). In implementing the logic <NUM>, the CAx adaptive UI engine <NUM> may obtain real-time command usage by a user of the CAx application (<NUM>) and apply the machine learning model to adaptively transform a UI of the CAx application (<NUM>). The adaptive transformation step by the CAx adaptive UI engine <NUM> may include inputting the real-time command usage of the CAx application to the machine learning model to determine a predicted command based on the real-time command usage (<NUM>) and dynamically updating a selected sub-section of the UI of the CAx application to present the predicted command to the user (<NUM>).

The logic <NUM> shown in <FIG> provides but one example by which a computing system <NUM> may support adaptive Uls for CAx applications. Additional or alternative steps in the logic <NUM> are contemplated herein, including according to any features described for the CAx tracking engine <NUM>, the CAx training engine <NUM>, the CAx adaptive UI engine <NUM>, or any combinations thereof.

<FIG> shows an example of a system <NUM> that supports adaptive Uls for CAx applications. The system <NUM> may include a processor <NUM>, which may take the form of a single or multiple processors. The processor(s) <NUM> may include a central processing unit (CPU), microprocessor, or any hardware device suitable for executing instructions stored on a machine-readable medium. The system <NUM> may include a machine-readable medium <NUM>. The machine-readable medium <NUM> may take the form of any non-transitory electronic, magnetic, optical, or other physical storage device that stores executable instructions, such as the CAx tracking instructions <NUM>, the CAx training instructions <NUM>, and the CAx adaptive UI instructions <NUM> shown in <FIG>. As such, the machine-readable medium <NUM> may be, for example, Random Access Memory (RAM) such as a dynamic RAM (DRAM), flash memory, spin-transfer torque memory, an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disk, and the like.

The system <NUM> may execute instructions stored on the machine-readable medium <NUM> through the processor <NUM>. Executing the instructions may cause the system <NUM> (or any other computing or CAx system) to perform any of the CAx adaptive UI features described herein, including according to any of the features with respect to the CAx tracking engine <NUM>, CAx training engine <NUM>, CAx adaptive UI engine <NUM>, or combinations thereof.

For example, execution of the CAx tracking instructions <NUM> by the processor <NUM> may cause the system <NUM> to track command usage of a CAx application to obtain command usage data for the CAx application. Execution of the CAx training instructions <NUM> by the processor <NUM> may cause the system <NUM> to train a machine learning model with the command usage data. Execution of the CAx adaptive UI instructions <NUM> by the processor <NUM> may cause the system <NUM> to obtain real-time command usage by a user of the CAx application and apply the machine learning model to adaptively transform a user interface (UI) of the CAx application, including by inputting the real-time command usage of the CAx application to the machine learning model to determine a predicted command based on the real-time command usage and dynamically updating a selected sub-section of the UI of the CAx application to present the predicted command to the user.

The systems, methods, devices, and logic described above, including the CAx tracking engine <NUM>, CAx training engine <NUM>, and CAx adaptive UI engine <NUM>, may be implemented in many different ways in many different combinations of hardware, logic, circuitry, and executable instructions stored on a machine-readable medium. For example, the CAx tracking engine <NUM>, CAx training engine <NUM>, CAx adaptive UI engine <NUM>, or combinations thereof, may include circuitry in a controller, a microprocessor, or an application specific integrated circuit (ASIC), or may be implemented with discrete logic or components, or a combination of other types of analog or digital circuitry, combined on a single integrated circuit or distributed among multiple integrated circuits. A product, such as a computer program product, may include a storage medium and machine readable instructions stored on the medium, which when executed in an endpoint, computer system, or other device, cause the device to perform operations according to any of the description above, including according to any features of the CAx tracking engine <NUM>, CAx training engine <NUM>, CAx adaptive UI engine <NUM>, or combinations thereof.

The processing capability of the systems, devices, and engines described herein, including the CAx tracking engine <NUM>, CAx training engine <NUM>, and CAx adaptive UI engine <NUM>, may be distributed among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems or cloud/network elements. Parameters, databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may implemented in many ways, including data structures such as linked lists, hash tables, or implicit storage mechanisms. Programs may be parts (e.g., subroutines) of a single program, separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library (e.g., a shared library).

Claim 1:
A method comprising:
by a computing system (<NUM>, <NUM>):
tracking (<NUM>) command usage of a computer-aided technology (CAx) application to obtain command usage data (<NUM>, <NUM>, <NUM>, <NUM>) for the CAx application;
training (<NUM>) a machine learning model (<NUM>) with the command usage data (<NUM>, <NUM>, <NUM>, <NUM>);
obtaining (<NUM>) real-time command usage (<NUM>, <NUM>, <NUM>, <NUM>) by a user of the CAx application; and
applying (<NUM>) the machine learning model (<NUM>) to adaptively transform a user interface (UI) of the CAx application (<NUM>), including by:
inputting (<NUM>) the real-time command usage (<NUM>, <NUM>, <NUM>, <NUM>) of the CAx application to the machine learning model (<NUM>) to determine a predicted command (<NUM>, <NUM>, <NUM>, <NUM>) based on the real-time command usage (<NUM>, <NUM>, <NUM>, <NUM>); and
dynamically updating (<NUM>) a selected sub-section of the UI of the CAx application (<NUM>) to present the predicted command (<NUM>, <NUM>, <NUM>, <NUM>) to the user,
wherein:
tracking comprises tracking the command usage on a CAx domain-specific basis, wherein CAx domains for the CAx application are differentiated according to different part templates, part manufacturing processes, or industrial application;
training the machine learning model (<NUM>) comprises training different machine learning models (<NUM>, <NUM>) for different CAx domains of the CAx application; and
applying the machine learning model (<NUM>) comprises:
identifying a particular CAx domain applicable to the real-time command usage (<NUM>); and
applying a specific machine learning model (<NUM>, <NUM>) trained for the particular CAx domain.