Method and corresponding display device for displaying individual home screens on a vehicle display device

Abstract

The present invention relates to a method for displaying an individual home screen (14) on a display device (12), the method comprising the steps of receiving from a first vehicle component (28) at least a first request for consideration to display a first functionality symbol (16) thereof, receiving from a second vehicle component (28) at least a second request for consideration to display a second functionality symbol (16) thereof, determining a context cluster (26) according to current context data of the vehicle (10), determining in the current context cluster (26) a current first rank (30) for the first request component (28) and a current second rank (31) for the second request component (28). 0), comparing the first rank (30) with at least a second rank (30), and if a given first rank (30) is higher than the second rank (30), displaying a respective home screen (14) in which the first functionality symbol (16) has a higher priority than the second functionality symbol (16), or vice versa, wherein the first rank (30) is determined as a function of a type and frequency of interactions performed by the user in relation to the first vehicle component (28) of the context cluster (26) and the second rank (30) is determined as a function of a type and frequency of interactions performed by the user in relation to the second vehicle component (28) of the context cluster (26). Furthermore, the present invention relates to a display device (12).

Description

Technical Field

[0001] The present invention relates to the field of automobiles. More particularly, the present invention relates to a method for displaying an individual home screen on a display device of a vehicle, wherein at least one functional symbol is displayed on the home screen. Further, the present invention relates to a corresponding display device.

Background Art

[0002] In the prior art, it is known to cluster functionality in different applications and show an overview of all applications having functionality hidden in sub-menus to customers. A smartphone is an example of this. However, this is quite cumbersome and not a very safe method in vehicles, especially automobiles. Customers are expected to concentrate on driving while at the same time looking at the touch screen and performing various clicks before reaching the action they want to execute.

[0003] Patent Document 1 relates to an automobile including a display, a display device for displaying selectable graphical objects, an input unit for receiving an input from a user capable of selecting one of the displayed objects, and a control device for controlling the display device according to the received input. The control device is designed to assign a specific priority value to the displayed object according to the received input, and to set the size of each object and / or the arrangement of the displayed objects relative to each other according to the priority value during the operation of the display and the operation device. Patent Document 2 discloses a technique for interacting with a touch screen of a vehicle. According to one or more embodiments, a system is provided that includes a processor that executes computer-executable components stored in at least one memory, and includes a display control component that selects a graphical touch control included in a graphical user interface for rendering on the touch screen based on activation of a haptic feedback mode for interfacing with the touch screen. The graphical touch control corresponds to a control for one or more applications or functions associated with the vehicle. The system further includes a positioning component that determines the location of a finger on or above the touch screen with respect to the graphical touch control displayed on the touch screen, and a haptic feedback component that causes the vibration unit of the vehicle to provide vibration feedback based on the location corresponding to the graphical touch control of the graphical touch control.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] An object of the present invention is to provide a method and a corresponding display device capable of displaying individual home screens on a display device of a vehicle in a more comfortable manner.

Means for Solving the Problems

[0006] This object is solved by the method and the corresponding display device described in the independent claims. Advantageous embodiments are described in the dependent claims.

[0007] One aspect of the present invention relates to a method for displaying individual home screens on a display device of a vehicle, the method comprising displaying at least one functional symbol on the home screen. At least a first request regarding considerations for displaying a first functional symbol of a first vehicle component, generated by a provider associated with the first vehicle component, is received. At least a second request regarding considerations for displaying a second functional symbol of a second vehicle component, generated by a further provider associated with the second vehicle component, is received. Determining a context cluster based on current context data of the vehicle is performed. A current first rank for the first request of the first vehicle component within the current context cluster is determined, and a current second rank for the second request of the second vehicle component within the current context cluster is determined. The first rank determined for the context cluster is compared with at least the second rank determined for the context cluster. The individual home screen assigned to the display device displays the first functional symbol with a higher priority than the second functional symbol if a given first rank is higher than the second rank, and vice versa. The first rank is determined according to the type and frequency of interaction with the first vehicle component, and the second rank is determined according to the type and frequency of interaction with the second vehicle component. A higher priority means, for example, that if the space for depiction is limited to show only one of the first functional symbol or the second functional symbol, the symbol with the higher priority is displayed and the other is not. In another further embodiment, priorities are determined for third, second and further functional symbols.

[0008] Accordingly, the individual home screens within the vehicle are presented in a more comfortable manner. As a result, the necessary interaction with the head unit is reduced, and easy top-level access to all desired personalized functions and use cases is provided to the extent possible. This is done in particular with the support of artificial intelligence, for example neural networks. For example, the navigation map on the home screen is combined with a so-called magic dock. The magic dock is filled with predictions from the artificial intelligence kernel and indicates the most desired functionality at any given time based on learned user behavior within various contexts such as time, location, weather, etc.

[0009] For example, the display device may include a user interface background with a dynamic global positioning system (GPS) map. For example, at the top, a global search function is hierarchically arranged at the bottom together with the so-called magic dock. Entertainment tiles displayed in an expanded form can retract to the size of the smallest tile or across the entire dock length if there are no relevant suggestions. When not in use and / or when there is limited space, i.e., no space to display additional tiles on the display area, the size can be retracted. In the context of this application, a tile is a functional symbol associated with a vehicle component operable by the user. For example, when a phone is connected, a static phone tile follows, followed by any active use case. Examples of active use cases can be an ongoing seat massage program, a call, or a seat heating activity, and options that directly engage with the ongoing activity are provided directly to the user. Finally, there are personalized tile suggestions accelerated by a new artificial intelligence algorithm that includes a subset of proposed use cases that the system has learned the customer is interested in within a given contextual situation.

[0010] The display device is configured to show a subset of context-aware, personalized functionality on the home screen that can also be considered use cases. This enables easy and quick access throughout the customer's driving journey while limiting distraction. As a result, the driving environment becomes much safer, and the customer enjoys a more pleasant and stress-free user experience. Use cases are a predefined set but can be extended with additional use cases from the backend or via over-the-air updates. Additionally, context features considered by artificial intelligence are a predefined set but are also extendable over-the-air updates to the head unit / display device.

[0011] Specifically, a context cluster refers to a particular set of values of context features, each of which refers to data based on time, location, temperature, weather, day of the week, week, and / or other environmental conditions. A default rank is given to each of the use cases to define its importance. The deployment rank associated with each use case changes over time as the artificial intelligence learns. Use cases deploy different ranks for each context cluster that is learned. Higher-ranked use cases maintain a higher priority than lower ranks. Use cases can also be considered functions of the vehicle. These are functions proposed by the artificial intelligence kernel to the customer.

[0012] According to one embodiment, the requirements for the first vehicle component and / or the second vehicle component are generated only by a provider associated with the first vehicle component and / or the second vehicle component when a predetermined rule is satisfied. For example, the rule may be not exceeding a predetermined speed limit. For example, when the context is a parking context, the speed limit must remain below a specific value, and a functional symbol associated with a component that functions as Parktronic, i.e., a park assistant, may be displayed on the display device. In particular, for example, the function of Parktronic can be used only when the vehicle is traveling below a specific speed limit. This means that the use case of Parktronic is meaningful only when this requirement is satisfied. Different from these types of rule-dependent requirements, some vehicle functions generate persistent requirements independent of any rules, such as, for example, a music streaming service, a weather forecast app, a system setting function, etc. Vehicle functions that generate persistent requirements are always available, and rule-based requirements are available only in specific situations.

[0013] The probability of using a vehicle component is used to generate an associated rank. In particular, user interaction is a major consideration that affects learning. A user can interact with a use case via a home screen, for example, by providing positive feedback, for example, by discarding it temporarily (which means negative feedback), or simply not interacting with the use case (which can be regarded as neutral feedback). Further, a user can choose to interact with a specific use case not displayed on the home screen via an application menu, navigate on the home screen via the application menu, and navigate the user interface by perusing a sub-menu. The display device also considers this as positive reinforcement for the use case, which will also directly affect the ranking. Each time a user interacts with a use case supported by the display device, the model is trained with that data and the corresponding kernel is updated.

[0014] In another, more developed embodiment, the first and second ranks are determined by using the development of a beta distribution having an increasing or decreasing mean value, where the mean value is associated with or at least corresponds to the rank. In particular, as the kernel learns, the assumed values of the ranks within each class evolve, i.e., increase or decrease in response to the interaction between the user and the vehicle components via the functional symbols or selection menus shown on the display. These qualities are modeled as a beta distribution that represents whether the customer is involved in the use case, and are then parameterized by a conjugate prior beta distribution. The beta distribution directly represents the kernel's belief about the probability that the use case will be engaged by the user. These prior distributions evolve as the kernel observes the customer engagement or non-engagement of each user case within each cluster. The development of the beta distribution is performed by updating the parameters α, β used in the mean calculation of the beta distribution (mean = α / (α + β)) according to predefined rules depending on the type of interaction. The rules are stored as a lookup table in the memory of the display device or are calculated by an appropriate algorithm. The type of interaction is a click on a symbol, a swipe away of a symbol, no interaction with the provided symbol, and / or activation by a sub-menu, and each interaction is assigned an update parameter that evolves the prior values of α and β.

[0015] In another embodiment, the first rank and the second rank are determined at a predetermined time step, and / or the comparison is performed at a predetermined time step, and / or the determination of the current context cluster based on the vehicle's context data is frequently performed at a predetermined time step. This is sometimes referred to as a timer check. When the use case passes the setting check, the timer check is performed. The timer has two purposes. It ensures that the home screen is not updated too frequently, and also ensures that when new use case donations are not made but the context changes, the artificial intelligence check is performed at specific intervals. If the timer check is passed and the home screen can be considered for an update, a request or prediction call is made to the context clusterer in the ranking algorithm.

[0016] According to another embodiment, the display of the first functional symbol and / or the second functional symbol is suppressed in response to an input by the user of the vehicle. This can also be regarded as a rejection rights list. In particular, a time check is performed on this rejection rights list. The user has the option to reject specific use cases, which means that the user can request that these use cases are not displayed again. This rejection rights list can only be reset when all history and learning are reset. Use cases swiped away on the user interface are rejected, that is, ignored during the trip period. Use cases permanently rejected in the settings are not displayed as long as the setting entry is turned off. In a further embodiment, the display of the first functional symbol and / or the second functional symbol is suppressed as long as the rank of the request of the associated vehicle component is below a predefined threshold. The threshold prevents the display of symbols that are not of interest to the user and avoids unnecessary distraction of the driver.

[0017] In another embodiment, each context cluster that includes one or some types of vehicle component requirements refers to a subset of context features. The vehicle component requirements within a cluster with an assigned rank represent the functions of components that can be automatically requested by a provider or initiated by a user. These context features may be weather, vehicle navigation state, speed, or time. In particular, these contexts can be assigned to environmental conditions. In particular, the display device receives inputs and learns from various sources. The primary inputs are environmental context features, such as time, location, and weather. However, other inputs include behavioral contexts, such as navigation state, use of seat heaters, passengers in the vehicle, etc. When the user interacts with various use cases, the display device learns which context is important for which use case and the appropriate rank values for each context set. These specific individualized context sets are called clusters and form a basis to which a ranking algorithm can be applied. Within each cluster, individual use case rankings are continuously updated and stored, leading to accurate predictions based on a wide variety of context situations.

[0018] According to another embodiment, the context cluster is established by training, preferably by training a neural network or other known machine learning techniques known from the prior art. Thus, in particular, the display device has a neural network or other machine learning technique. Thus, individualized training of the display device can be realized.

[0019] In another embodiment, within each context cluster, the ranking of vehicle component requirements is stored and deployed individually. In particular, the same requirements can be implemented in several context clusters. A context cluster refers to a subset of context features, such as time and location. One context cluster can refer to morning time and home location, while another context cluster can refer to lunch time and office location. In both cases, the same requirement can be, for example, one of the notifications of the call system or the time scheduler.

[0020] In a further embodiment, a plurality of context clusters are arranged within a cluster ensemble, and each cluster ensemble is processed in a separate kernel in parallel with other cluster ensembles. In particular, an ensemble of learning kernels is developed in parallel as a complete model operating within a single vehicle to improve the overall accuracy and thereby the user experience. Each kernel of the controller constituted by the display device operates simultaneously on a subset of different context features, and the results are combined for the final use case proposal list. This ensemble model simultaneously addresses concerns revolving around missing context features, for example, around defects that lead to input signals never being sent or being lost, and enables pre-training of a generic base model suitable for most / all users, leading to immediately desirable intuitive proposals in the life cycle of a new user profile.

[0021] The kernel is composed of cluster ensembles that are trained and constructed in parallel. Each cluster ensemble is composed of clusters based on a subset of the context features assigned to the cluster ensemble. For example, one cluster ensemble constructs its clusters based on context features of time and location, another cluster ensemble constructs based on day of the week and location, and yet another cluster ensemble constructs based on weather, temperature, and location, etc. The clustering constructed for each of these cluster ensembles is independent of each other. The clustering of the context clusters and the ranking of the requirements associated with the vehicle components are performed independently and simultaneously in parallel with other cluster ensembles by training on each data point. Therefore, the context clusters and rankings of the requirements associated with the vehicle components formed on each cluster ensemble can be completely different from each other. For example, in the case of parking, there will be different rankings for vehicle components and associated symbols, such as requirements for Parktronic. For this vehicle component within the clusters of different cluster ensembles, for example, a ranking of 0.7 can be obtained for one cluster ensemble and a ranking of 0.3 for another cluster ensemble.

[0022] When making inferences based on a given context, the appropriate or at least the closest cluster within each cluster ensemble can be found, and based on that, the ranking within that cluster can be found. Next, for k cluster ensembles, k rankings with each ranking from a different cluster ensemble will be obtained.

[0023] In order to calculate the final ranking for each requirement of the vehicle components, it is necessary to average the rankings in different cluster ensembles. In a further embodiment, each cluster ensemble has a weight associated therewith, and thus this is a weighted averaging that gives a higher weight to the ranking by the cluster ensemble with a higher importance. Preferably, these weights are adjusted based on the evaluation of large-scale simulated data (including data sets exceeding 800) generated based on different story scenarios, and based on accuracy metrics, the weights that result in the best average performance for all of these data sets are selected.

[0024] In another embodiment, on the home screen, additionally, at least one static functionality symbol of a further vehicle component is displayed, and the static functionality symbol is always Adjustment displayed in an impossible manner, or at least Adjustment displayed in a possible manner. For example, the static functionality symbol may be a navigation card that is always displayed. In particular, the first functionality symbol and the second functionality symbol may be displayed in an emphasized manner. Thus, functionality such as navigation, or for example a call, is always displayed because they are important functionalities. The size of the static functionality symbol of the further vehicle component is adapted such that symbols associated with further vehicle functions required by a provider having a rank higher than a predefined threshold can be displayed on a display area having limited space. In this case, the static functionality symbol is reduced to create an area available for displaying further functionality symbols, for example the first functionality symbol and / or the second functionality symbol. Functionality symbols other than the static functionality symbol are displayed in order of priority until they completely occupy the display area, and further functionality symbols are rejected.

[0025] Another aspect of the present invention is a vehicle display device for displaying an individual home screen, wherein at least one functional symbol is displayed on the home screen, the display device comprises at least one electronic computing device, and the display device is configured to execute the method according to the above aspect. In particular, the method is executed by the display device.

[0026] A further aspect of the present invention relates to a vehicle, in particular a motor vehicle, comprising a display device. The display device includes electronic means for executing the method, such as a processor, an integrated circuit, and further electronic means.

[0027] Further advantages, features, and details of the present invention can be obtained from the following description of the preferred embodiments and the drawings. The features and combinations of features described above, as well as those described in the following description of the drawings and / or only illustrated in the drawings, can be used not only in the combinations shown, but also in any other combination or alone without departing from the scope of the present invention.

[0028] The novel features and characteristics of the present disclosure are set forth in the appended claims. The accompanying drawings, which are incorporated in and constitute a part of the present disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles. The same numbers are used throughout the drawings to refer to like features and components. Next, some embodiments of the system and / or method according to the subject matter of the present invention will be described below by way of example only, with reference to the accompanying drawings.

[0029] Each figure shows the following:

Brief Description of the Drawings

[0030]

Figure 1

Figure 2

Figure 3

Figure 4

[0031] In the figures, elements having the same element or the same function are denoted by the same reference numerals.

[0032] Here, in this specification, the word "exemplary" is used to mean "serving as an example, instance, or illustration". Any embodiment or implementation of the subject matter of the invention described herein as "exemplary" should not necessarily be construed as being more preferred or advantageous than other embodiments.

[0033] Although the present disclosure has room for various modifications and alternative forms, specific embodiments of those forms are illustrated in each figure by way of example and will be described in detail below. However, it is not intended to limit the present disclosure to the specific forms disclosed, but rather the present disclosure is to be understood as also covering any modifications, equivalent forms, and alternative forms that fall within the scope of the present disclosure.

[0034] The terms "comprises", "comprising", or any other variant of those terms are intended to cover non-exclusive inclusion, such that a setup, device, or method that includes a list of components or steps does not include only those components or steps but may also include other components or steps not expressly listed, or other components or steps inherent to such setup, device, or method. In other words, one or more elements in a system or device preceded by "comprises" or "comprise" do not, without more constraints, preclude the presence of other elements or additional elements in that system or method.

[0035] In the following detailed description of embodiments of the present disclosure, reference is made to the accompanying drawings which form a part hereof and in which are shown, by way of illustration, specific embodiments in which the present disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the present disclosure, and other embodiments may be utilized and changes may be made without departing from the scope of the present disclosure. Accordingly, the following description should not be construed in a limiting sense.

[0036] FIG. 1 shows a schematic side view according to an embodiment of a motor vehicle 10 comprising a display device 12. In particular, the display device 12 is for displaying an individual home screen 14 shown in an enlarged view. At least one functional symbol 16 is displayed on the home screen, and the display device 12 comprises at least one electronic computing device 18. In particular, the electronic computing device 18 may include artificial intelligence, in particular at least one kernel 20 and / or a plurality of kernels 20.

[0037] In particular, the home screen can show, for example, at least one static functional symbol 22, which can be, for example, a tile for a navigation screen and / or a call. In particular, a set of functions is provided to the user 24 of the motor vehicle 10 and / or the display device 12, and the static functional symbol 22 is provided on an active tile that is always displayed, for example, in the form of an entertainment module, when the user 24 is performing functions proposed based on specific actions and artificial intelligence learning. A permanent user interface background displayed as a global positioning system (GPS) map is illustrated in FIG. 1. At the top, for example, a global search function and a so-called magic dock, which is, for example, a first functional symbol 16 or a second functional symbol 16, are hierarchically arranged at the bottom.

[0038] Entertainment tiles that are displayed in an expanded form can retract to the size of the smallest tile, or, if there is no related proposal, across the entire dock length or nearly across the entire dock length. When the phone is connected, static phone tiles follow, followed by any active use cases. Examples of active use cases can be an ongoing seat massage program, a call, or a seat heating activity, and the user is directly provided with options that immediately engage with the ongoing activity. Finally, there are personalized tile proposals accelerated by the electronic computing device 18 that include a subset of the proposed use cases that the system has learned the user 24 is interested in for a given context situation.

[0039] In particular, the context cluster 26 (Figure 2) refers to a specific set of values of context features based on, for example, time, location, and other environmental conditions such as weather, vehicle, and navigation state. The context cluster 26 is arranged within the cluster ensemble 62 of the learning kernel 20, where several cluster ensembles 62 operate in parallel in the learning kernel. A subset of the context features 33 is assigned to each cluster ensemble, and the context clusters 26 within each cluster ensemble 62 are learned based on these subsets of the context features 33. In this context, "donate" means that, for example, a provider that can be an associated electronic module of a vehicle component 28 (Figure 2) or a vehicle component assigned to a display device notifies the electronic computing device 18 that its use case(s) should be considered to be displayed on the home screen 14 upon request. Some examples of vehicle components are an energizing coach, a seat heater, a parking assistance system, a phone, a massage, or a navigation system, etc. The donation can be permanent throughout the entire driving period or restricted by certain rules for a certain specific time. The vehicle component 28 or the associated electronic module, which can also be called a provider, donates to the electronic computing device 18 for consideration of their use cases. They can donate their use cases or retract the donation at any given moment. Each application has one provider for its set of use cases. Each application can have a rank 30. In particular, the default rank 30 is given to each use case to define the importance of the use case. The rank 30 changes over time as the electronic computing device 18 learns. The use cases deploy different ranks 30 for each learned context cluster 26. Higher-ranked use cases maintain a higher priority than lower ranks. The vehicle component 28 has the option to remove donations considered for the home screen 14.This withdrawal usually occurs when the use case depends on specific requirements that should be met, for example, when the vehicle transmission changes from parking to drive, and the trunk release tile may be retracted. The use case can also be regarded as a function of the vehicle 10. These are the functions that the electronic computing device 18 wants to propose to the user 24.

[0040] Figure 2 shows a schematic flowchart according to an embodiment of the present method. In particular, Figure 2 shows that the method for displaying the individual home screen 14 includes receiving at least a first request from the first vehicle component 28 regarding considerations for displaying its first functionality symbol 16. Further, it is executed to receive at least a second request from the second vehicle component 28 regarding considerations for displaying the second functionality symbol 16. The context cluster 26 is determined by the current context data of the vehicle. The current first rank 30 for the first request of the first vehicle component 28 and the current context cluster 26 is determined, and the current second rank 30 for the second request of the second vehicle component 28 within the current context cluster 26 is determined. The first rank 30 and the second rank 30 are compared in the comparison module 34. The individual home screen 14 displays the first functionality symbol 16 with a higher priority when a given first rank 30 is higher than the second rank 30 Together with and vice versa. If only one functionality symbol can be displayed due to limited space, the functionality symbol with a lower priority is ignored.

[0041] The first rank 30 is determined according to the number and type of usage interactions related to the first vehicle component 28 of the context cluster 26, and the second rank 30 is determined according to the number and type of in - interactions of usage related to the second vehicle component 28 of the context cluster 26.

[0042] In particular, the flow of the electronic computing device 18 is shown in FIG. 2. First, the use cases need to be donated via an electronic module associated with the vehicle component 28. Each application, also known as a provider, donates its designated use cases to the electronic computing device 18, specifically the kernel 20, to be considered for the home screen 14. The provider can choose to donate the use cases at startup, leave them as considerations at all times, or donate based on specified rules and can retract the use cases if the rules no longer apply. An example of the latter is the use case of Parktronic Plus (PTS). This function can only be used when the vehicle 10 is traveling below a certain restricted speed, and thus it is meaningful for the provider to donate the use case only when this requirement is met.

[0043] Once the use cases are donated to the electronic computing device 18, the kernel 20 first checks the customer settings 36. The customer settings 36 or user settings enable the profile-specific user 24 to select, if any, which use cases the system should learn about and display on the home screen 14, and which use cases to ignore. The initial settings 36 cover use cases for telephone services, navigation services, comfort services, vehicle services, in-vehicle office services, and online voice services.

[0044] If the use case passes the setup check, the timer 38 is checked. The timer 38 has two purposes. It ensures that the home screen 14 is not updated too frequently, and also ensures that when the context changes but the use case donation is not made, the electronic computing device 18 is checked at specific intervals. If the timer 38 check passes and the home screen 14 can be considered for update, a request or prediction call is made to the context clusterizer and the ranking algorithm. The clusterizer determines which of the learned environmental context categories is most appropriate for the current conditions, combines with the internal ranking algorithm, and provides prioritized feedback on which use cases should be proposed for display. Only the donated use cases are considered. The clusterizer receives inputs from various sources and learns. The primary inputs are environmental context features, such as time, location, and weather. However, other inputs include behavioral context, such as navigation status, phone usage, or passengers in the vehicle. When the user 24 interacts with various use cases, the electronic computing device 18 learns which context is important for which use case and the appropriate rank values for each context set. This set of these specific individualized contexts is called 26 clusters and forms the basis to which the ranking algorithm can be applied. Within each cluster, individual use case rankings are continuously updated and stored, leading to accurate predictions based on a wide variety of context situations.

[0045] After the cluster is executed, a check against the denial list 40 is performed. User 24 has the option to deny specific use cases, which means that the user can request that these use cases not be displayed again. In an exemplary embodiment, this denial list 40 can be reset only if all history and learning are reset. A use case swiped away on the display device 12 is ignored only during the period of the trip, which means that a check against the temporary ignore list 42 is performed. A use case permanently denied in the settings is not displayed as long as the setting entry is off.

[0046] If the use case passes the denial list check, a final comparison 44 is made between the rank 30 of the use case and a default rank as a predefined threshold given, for example, by a static entertainment use case. If a donated additional use case is ranked above the static default rank, it is displayed to user 24 on the home screen 14 along with a functionality symbol. If it is ranked lower than the static default rank, it is not displayed and the entertainment module remains expanded.

[0047] In particular, user interaction is a major consideration that affects the learning process. User 24 can interact with the use case via the home screen 14, for example, by providing positive feedback, by, for example, discarding it temporarily (which means negative feedback), or by simply not interacting with the use case (which can be considered neutral feedback). Further, User 24 can choose to interact with a specific use case not displayed on the home screen 14 via the application menu and can navigate the display device 12 by perusing the sub-menu. The electronic computing device 18 also considers this so-called Long-Way-Access as positive reinforcement for the use case, which directly affects the learned ranking within the associated context cluster well. In other words, every time a requesting vehicle component is activated, for example, by a head unit menu or sub-menu, the request is ranked higher even if the associated symbol is not displayed on the display. As soon as the rank becomes high enough, the associated symbol appears on the display, improving usability. Every time User 24 interacts with a use case supported by the electronic computing device 18, the model is trained with that data and the electronic computing device 18 is updated.

[0048] Rank 30 is a fundamental element in the decision-making process within the electronic computing device 18. Each use case starts with an initial Rank 30, which can be considered cold-start priors. Rank 30 defines the relative importance of one use case compared to another. The learned Rank 30 grows larger when the user 24 engages with the use case more frequently. The rate at which the estimated Rank 30 can change depends on the type of interaction. The electronic computing device 18 learns the assumed values of Rank 30 within each cluster, specifically the prior distribution. These quantities are modeled as the beta distribution 46 illustrated in FIG. 3, which means either the user 24 engages with the use case or does not. The beta distribution directly represents the kernel's belief about the probability that the use case is engaged by the user 24. These prior distributions evolve as the kernel 20 observes user engagement or non-engagement for each use case within each cluster.

[0049] Figure 3 shows two diagrams for determining ranks. The beta distributions shown represent the distribution over the probability that a particular action is taken. The upper panel of Figure 3 shows three examples of beta distributions, highlighting how the mean of the distribution corresponds to rank 30 without normalization. These probability distributions are examples of complete information content stored in a set of beta parameters for a particular use case within a particular cluster. For illustration, the first curve 48 represents the belief that our best guess of the estimated probability that user 24 interacts with the use case is, for example, 70% represented by a mean value of 0.7 shown on the x-axis. The probability corresponds to the rank, and a high probability means a high rank. The mean value is characterized by mean = α / (α + β), where α and β are beta parameters. In the case of curve 48, α = 7 and β = 3. However, the confidence we have in that number is somewhat low, which is represented by a large width and low height, i.e., a high variance of the first curve 48. In other words, confidence is associated with width, width is associated with the height of the graph, and the value corresponding to the height is shown on the y-axis. Alternatively, the peak of the second curve 50 (α = 70 and β = 30) has the same mean of 70% but is represented by a narrow width and higher height, i.e., a small variance, and the confidence at that value is much stronger. Finally, the third curve 52 (α = 800 and β = 800) shows an example of whether the confidence level is very high in the estimate of a 50% probability. User behavior / action history is parameterized by a beta distribution. Each tile / action has its own underlying prior distribution for the beta parameters. Over time, as the user interacts, the beta parameters within the context cluster are updated, thereby evolving the rank.

[0050] To elaborate on how the prior distribution unfolds with more observations of user engagement, the lower panel of FIG. 3 shows the initial prior distribution in a fourth curve 54 that characterizes an initial assumption of approximately a 45% probability that the user engages with the use case, but the wide width of the curve indicates that the kernel 20 is not very confident about this prior assumption. The distribution of the fifth curve 56 is the true probability distribution of user engagement. Over time, as the kernel 20 observes user behavior, the kernel 20 begins to learn to update the probability estimates. This is illustrated in the sixth curve 58 and the seventh curve 60, which are getting closer and closer to the true distribution, and thus to the fifth curve 56. Depending on the type of interaction, α and β are updated. For example, an interaction as a click increases α by +1 and β remains unchanged, and a long - distance access increases α by +5 and β remains unchanged. A neutral interaction increases β by +1, and a swipe - away action increases β by +5, and in both cases, α remains unchanged. To adapt the degree of change of α and β to different uses, these can be parameterized via software.

[0051] An example of the development rank associated with the mean value is shown in FIG. 4. Starting from a prior state 70 with a mean value of 0.5 (mean = 2 / (2 + 2)=0.5), 15 interactions with vehicle components are performed. In this case, the interaction is a click on a tile, for example, a radio tile. Each time the interaction prior value is updated, α increases by +1 and β remains unchanged. In the end state 72, the current value of α is 17 and β is still 2. The mean value starting from 0.5 is here 0.81 (mean=(2 + 15) / (2 + 15+2 + 2)=17 / 21 = 0.81), which gives a much higher priority to the requirements of the vehicle components than before.

[0052] To propose a use case for actually displaying an interface on the home screen 14, the kernel 20 calculates a probability distribution for all available use cases. If the expected probability value is below the value of the media tile, that use case is discarded. In other words, if the rank corresponding to the probability is below the default rank associated with the use case, this rank is discarded. The remaining probabilities are normalized and compared to form a ranked list of proposals. The top proposals are presented to the user interface, particularly on the display device 12. An example of balancing the initial rank 30 can be found by comparing the missed call use case and the Parktronic use case. Assuming user data is aggregated, user 24 is equally likely, for example, with a 70% probability, to be involved in each of these use cases. However, the probability of Parktronic has much greater variation, with the average probability still being 70%, so many people are involved in Parktronic almost every time, and others are involved very rarely. Due to the high spread, the confidence level is low, and an initial beta distribution with a large width is applied to the Parktronic use case. On the other hand, the majority of users 24 check for missed calls, particularly at notification times, for example 70% of the time, and thus have a high confidence level, and the missed call will result in a beta distribution with a narrow width. The confidence level of the belief in the 70% value of the missed call is stronger than that of the 70% value of Parktronic. Incidentally, this example can be the first curve 48 (e.g., Parktronic) and the second curve 50 for missed calls.

[0053] The rank 30 of each use case changes based on the user's interaction with the display device 12 and is stored independently for all clusters. Within a cluster, the rank 30 unfolds individually to create a fully personalized user experience. Updating the ranking of the use case by unfolding α and β can increase or decrease the rank 30 depending on the behavior. Without additional input, the learned rank 30 will eventually decline towards the initial default value.

[0054] The combination of the clusterizer and the ranking algorithm includes a single learning kernel 20. To improve the overall accuracy and thereby the user experience, the ensemble 62 of learning kernels 20 is deployed in parallel as a complete model executed on a single vehicle 10. Each kernel 20 operates simultaneously on a subset of context features having a specific set of parameters, and the results are combined for the final use case proposal list displayed by block 64. The ensemble model simultaneously addresses concerns about the deployment around missing context features, e.g., around bugs that lead to an input signal never being sent or being lost, and enables pre-training of a generic base model suitable for most / all users 24, leading to immediately desirable intuitive proposals in the lifecycle of a new user profile.

[0055] As a use case, for example, a call can be presented. Another use case can be a comfort use case, e.g., massage, heating control, energization of a comfort program, air defense, energization of an activation program, or a power nap. Another use case can be a navigation case where a recent destination, a favorite destination, and / or a predicted destination are presented. Another use case can be related to vehicle use cases, e.g., trunk control, comfort door control, vehicle level adjustment, or the Parktronic use case. Further, the in-vehicle office can be a use case that can be, for example, a call list and a birthday. Further, the online voice service can be a use case such as a food order. These presented use cases are merely examples.

[0056] The contexts considered by the kernel 20 can include local time, time to boot, GPS, internal temperature, external temperature, air quality, passengers in the vehicle, speed, navigation guidance status, estimated time of arrival, driving state, seat heating status, and time since the last application use. These contexts are updated and added to.

Claims

Claim 1 A method for displaying an individual home screen (14) on a display device (12) of a vehicle (10), the method comprising: Receiving at least a first request regarding considerations for displaying a first functional symbol (16) of the first vehicle component, generated by a provider associated with the first vehicle component (28); Receiving at least a second request regarding considerations for displaying a second functional symbol (16) of the second vehicle component, generated by a further provider associated with the second vehicle component (28); Determining a context cluster (26) based on current context data of the vehicle (10); Determining a current first rank (30) for the first request of the first vehicle component (28) within the current context cluster (26), and determining a current second rank (30) for the second request of the second vehicle component (28) within the current context cluster (26); Comparing the first rank (30) with at least the second rank (30) determined for the context cluster (26); When the given first rank (30) is higher than the second rank (30), displaying the individual home screen (14) assigned to the display device (12) together with the first functional symbol (16) having a higher priority than the second functional symbol (16), or the reverse step; comprising, wherein the first rank (30) is determined according to the type and frequency of interaction performed by a user (24) of the vehicle (10) in relation to the first vehicle component (28) of the context cluster (26), and the second rank (30) is determined according to the type and frequency of interaction performed by a user (24) of the vehicle (10) in relation to the second vehicle component (28) of the context cluster (26). Claim 2 The requirement for the first vehicle component (28) and / or the second vehicle component (28) is generated only by the provider associated with the first vehicle component and / or the second vehicle component if a predetermined rule is satisfied. The method according to claim 1, characterized in that.

3. The first rank (30) and the second rank (30) are determined by using the development of a beta distribution (46) having an increasing or decreasing average value, and the average value is associated with the rank. The development of the beta distribution (46) is executed by updating parameters α and β according to a pre-defined rule depending on the type of interaction. The method according to claim 1 or 2, characterized in that.

4. The interaction with the vehicle component includes a click on the functional symbol, a swipe-away of the functional symbol, no interaction with the provided functional symbol, and / or activation by a sub-menu. The method according to claim 1 or 2, characterized in that.

5. The first rank (30) and the second rank (30) are determined at a predetermined time step, and / or the comparison is executed at a predetermined time step, and / or the determination of the current context cluster (26) based on the context data of the vehicle (10) is frequently executed at a predetermined time step. The method according to claim 1 or 2, characterized in that.

6. The display of the first functional symbol (16) and / or the second functional symbol (16) is suppressed according to an input by a user (24) of the vehicle (10). The method according to claim 1 or 2, characterized in that.

7. The display of the first functional symbol (16) and / or the second functional symbol (16) is suppressed as long as the rank for the requirement of the associated vehicle component is below a pre-defined threshold. The method according to claim 1 or 2, characterized in that.

8. Each context cluster (26) including one or several types of vehicle component requirements refers to a subset of context features. The method according to claim 1 or 2, characterized in that.

9. Within each context cluster, the ranks of the requirements associated with the vehicle components are stored and / or deployed individually The method according to claim 8, characterized in that

10. The ranks of the requirements associated with the same vehicle component are implemented simultaneously in several context clusters and deployed individually The method according to claim 8, characterized in that

11. The context cluster (26) is established by training a neural network The method according to claim 1 or 2, characterized in that

12. A plurality of context clusters (26) are arranged within a cluster ensemble (62), and each cluster ensemble (62) is processed in a separate kernel (20) included in the electronic computing device (18) provided in the display device (12) in parallel with other cluster ensembles (62) The method according to claim 1 or 2, characterized in that

13. A subset of context features is assigned to each cluster ensemble, and the context clusters in each of these cluster ensembles refer to this subset of context features The method according to claim 12, characterized in that

14. On the home screen (14), additionally, at least one static functionality symbol (22) of a further vehicle component (28) is displayed, and the static functionality symbol (22) is always displayed in a non-adjustable manner or in an adjustable manner by retracting its size, and when the functionality symbol associated with a further vehicle function required by a provider having a rank higher than the static default rank has to be displayed on a display area having limited space, the size of the static functionality symbol (22) of the further vehicle component (28) is reduced The method according to claim 1 or 2, characterized in that

15. ​ A display device (12) of a vehicle (10) for displaying individual home screens (14), on which a first or second functional symbol (16) is displayed, the display device (12) comprising at least one electronic computing device (18), the display device (12) being configured to execute the method according to claim 1 or 2, said display device (12).

Images