Vehicle user interface

The function proposal system addresses biased function suggestions by user intent-based inquiries, preventing repetitive proposals and enabling users to customize their preferences, thus improving user experience and learning opportunities.

JP2025005917APending Publication Date: 2025-01-17TOYOTA JIDOSHA KK

Patent Information

Application Number
JP2023106354
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-06-28
Publication Date
2025-01-17

AI Technical Summary

Technical Problem

Existing vehicle user interface systems suggest frequently used functions without considering user intent, leading to biased recommendations and potential user annoyance, missed opportunities for learning new functions, and unnecessary repetition of suggestions.

Method used

A function proposal system that inquires users about continuing function suggestions based on the number of proposals and usage history, allowing customization to reflect individual user intentions and preferences.

Benefits of technology

Prevents repetitive suggestions, ensures appropriate function proposals, and allows users to opt out of known functions, thereby enhancing user experience and learning opportunities.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025005917000001_ABST
    Figure 2025005917000001_ABST
Patent Text Reader

Abstract

To provide a vehicle user interface for a vehicle mounted with a plurality of functions.SOLUTION: A vehicle user interface comprises: presentation means that selects a function for proposing usage to a user from a plurality of functions and presents the same to the user; storage means that records the number of times each function is presented by the presentation means; and inquiry means that asks the user whether to continue the proposal, after the presentation means performs the presentation, based on the number of times the storage means has recorded the presented function and user's usage history. The presentation means excludes the most recent function that was presented to the user from the candidate functions for subsequent presentations when the user rejects the continuation of the proposal.SELECTED DRAWING: Figure 2
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] The technology disclosed in this specification relates to a user interface for a vehicle. [Background technology]

[0002] For example, as shown in Patent Document 1, a mobile terminal equipped with multiple functions is known. In this mobile terminal, the multiple functions are ranked according to the frequency of use by the user, and the frequently used functions are preferentially displayed on the screen. This makes it possible to suggest to the user that they use the frequently used functions. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Special Publication No. 2016-512623 Summary of the Invention [Problem to be solved by the invention]

[0004] In the technology of Patent Document 1, when a user repeatedly uses a specific function, the use of the repeatedly used specific function is always suggested. As a result, the suggested functions are biased unintentionally by the user, which may make it difficult to suggest appropriate functions to the user. [Means for solving the problem]

[0005] According to the configuration of claim 1, it is possible to ask the user whether or not to continue the proposal depending on the number of times the function is proposed to the user. Since it is possible to confirm the user's intention regarding the function to be continued, it is possible to customize the proposed function to reflect the intention of each individual user. This makes it possible to propose appropriate functions to the user. [Brief description of the drawings]

[0006] [Figure 1] Schematic diagram of function proposal system 1. [Diagram 2] 4 is a flowchart illustrating a function proposal process performed in the function proposal system 1. [Diagram 3] 4 is a flowchart illustrating a function proposal process performed in the function proposal system 1. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] (Configuration of Function Proposal System 1) A function proposal system 1 according to an embodiment will be described with reference to Fig. 1. The function proposal system 1 includes a server 100 and a vehicle 10. The vehicle 10 is a so-called automobile, and is a vehicle that runs on a road. The vehicle 10 is, for example, an engine vehicle, a hybrid vehicle, a fuel cell vehicle, an electric vehicle, a solar car, or the like.

[0008] The vehicle 10 is connected to a communication network CN including wireless communication, such as a mobile communication network. The server 100 is also connected to the communication network CN via a server communication unit 120. Therefore, the vehicle 10 and the server 100 can communicate with each other via the communication network CN.

[0009] (Server 100 Configuration) The server 100 mainly includes a control unit 110 and a server communication unit 120. The control unit 110 is a device that controls the server 100. The control unit 110 can be configured, for example, by a computer equipped with a CPU, ROM, RAM, etc. When the computer executes a program, the control unit 110 functions as a notification setting recording unit 111, a performance information recording unit 112, etc.

[0010] The notification setting recording unit 111 stores various settings related to notifications for suggesting the use of a function to the user. The various settings include, for example, a proposal flag and a number of proposals. The proposal flag is information indicating whether or not each of the multiple functions equipped in the vehicle 10 is a target for proposal. Of the multiple functions, only functions whose proposal flag is "on" are considered as candidates for proposal. The number of proposals is the number of times that each of the multiple functions equipped in the vehicle 10 has been suggested to the user for use. The performance information recording unit 112 stores the number of times the user has used each of the multiple functions equipped in the vehicle 10 and the cumulative usage time.

[0011] (Vehicle 10 Configuration) The vehicle 10 mainly includes an in-vehicle device 20, an ECU 40, a microphone 41, a speaker 42, and a touch panel 43. The in-vehicle device 20 includes a vehicle communication unit 21 and a control unit 30. The vehicle communication unit 21 is connected to a communication network CN. The control unit 30 can be configured, for example, by a computer including a CPU, a ROM, a RAM, and the like. When the computer executes a program, the control unit 30 functions as a proposed function determination unit 31, a function usage detection unit 32, an HMI (Human Machine Interface) output unit 33, a setting unit 34, and the like. The details of these units will be described later.

[0012] The ECU 40, microphone 41, speaker 42, and touch panel 43 are connected to the vehicle-mounted device 20 so as to be able to communicate with each other. The ECU 40 is a device that controls the driving state of the vehicle. Data indicating various driving states (e.g., vehicle speed) is input from the ECU 40 to the vehicle-mounted device 20. The microphone 41 is a device that collects voice uttered by the user. The speaker 42 is a device that outputs voice. The touch panel 43 is a device that displays various information and receives operational inputs from the user.

[0013] The vehicle 10 has a plurality of functions. Examples of the functions include an ACC (adaptive cruise control) function, a lane departure prevention support function, an automatic headlamp beam adjustment function, a forward vehicle approach warning function, a pedestrian detection function, a traffic sign recognition function, a driver monitoring function, etc. These functions can be realized by an ECU (not shown) or the like.

[0014] (Feature suggestion processing) The function proposal process performed in the function proposal system 1 will be described with reference to the flowchart in Fig. 2. In the following, "Step 10" will be abbreviated as "S10".

[0015] In S5, the control unit 30 judges whether or not the vehicle 10 is used for the first time (for example, the vehicle 10 is a new vehicle). If the judgment is affirmative (S5: YES), the process proceeds to S50. In S50, the control unit 30 inquires of the user whether or not it is necessary to continue proposing all functions to be proposed (for example, all functions whose proposal flags are "on"). For example, a voice such as "Do you want to continue proposing all recommended functions?" may be output from the speaker 42. The response from the user may also be received by voice recognition using the microphone 41. By employing such a voice dialogue type system, the user does not need to move his / her eyes and can concentrate on driving, which contributes to safe driving.

[0016] If the user responds that it is necessary to continue the proposal (S50: necessary), the flow returns to S10 and continues. On the other hand, if the user responds that it is not necessary to continue the proposal (S50: unnecessary), the flow proceeds to S55.

[0017] In S55, the control unit 30 excludes all functions that are the subject of proposal from future proposal targets. For example, a command to set the proposal flag to "off" for all functions that are the subject of proposal may be sent to the notification setting recording unit 111. Then, the flow ends. This allows a user who already has knowledge of the functions of the vehicle 10 to turn off the notification settings for all proposed functions when using the vehicle 10 for the first time. This makes it possible to prevent a situation in which the user feels annoyed by receiving proposals for functions that are already known.

[0018] On the other hand, if it is determined in S5 that the vehicle 10 is not being used for the first time (S5: NO), the process proceeds to S10. In S10, the control unit 30 determines whether a function that satisfies the proposal condition (proposed function) has occurred. A specific description will be given. First, the proposed function determination unit 31 selects a function to be proposed to the user for use from among a plurality of functions. There may be various selection methods, and the proposed function may be selected based on the driving state input from the ECU 40. For example, when driving on a highway, the ACC function or the lane departure prevention support function may be selected. Also, for example, when it becomes dark around, the automatic headlamp beam adjustment function may be selected.

[0019] Next, the proposed function determination unit 31 acquires the usage history of the selected function from the history information recording unit 112. The function usage detection unit 32 detects whether the selected function is currently being used. If a predetermined period of time has passed since the selected function was last used and the selected function is not currently being used, it is determined that the proposal condition is satisfied. In this case, the selected function becomes the proposed function to be proposed to the user.

[0020] If the proposed function has not occurred (S10: NO), the process returns to S10 and waits. On the other hand, if the proposed function has occurred (S10: YES), the process proceeds to S20. In S20, the HMI output unit 33 presents the proposed function to the user. For example, a voice explaining the proposed function may be output from the speaker 42.

[0021] In S30, the control unit 30 increments the number of times the proposed function has been proposed by 1. For example, the control unit 30 may transmit to the notification setting recording unit 111 a command to increment the number of times the proposed function has been proposed by 1.

[0022] In S40, the setting unit 34 judges whether or not proposals have been made for all the functions to be proposed. This judgment may be made, for example, based on the proposal flag and the number of proposals received from the notification setting recording unit 111. If the judgment is affirmative (S40: YES), the process proceeds to S50. Note that the contents after S50 have already been explained. This allows a user who has received proposals for all the functions to be proposed to turn off the notification settings for all the proposed functions.

[0023] On the other hand, if a negative judgment is made in S40 (S40: NO), the process proceeds to S45. In S45, the setting unit 34 judges whether or not the user has used all of the functions to be proposed. This judgment may be made, for example, based on the usage history read from the history information recording unit 112. If a positive judgment is made (S45: YES), the process proceeds to S50. Note that the contents from S50 onwards have already been explained. This allows a user who has used all of the functions to be proposed to turn off notification settings for all of the proposed functions.

[0024] On the other hand, if a negative judgment is made in S45 (S45: NO), the process proceeds to S60. In S60, the control unit 30 judges whether or not the current proposal is the first proposal for the proposed function. If a positive judgment is made (S60: YES), the process proceeds to S110. In S110, the control unit 30 inquires of the user whether or not to continue proposing the proposed function. For example, a voice such as "Would you like to suggest this recommended function from next time onwards" may be output from the speaker 42.

[0025] If the user responds that it is not necessary to continue the proposal (S110: not necessary), the process proceeds to S130. In S130, the control unit 30 excludes the currently presented proposed function from future proposal targets. For example, a command to set the proposal flag to "OFF" for the currently presented proposed function may be sent to the notification setting recording unit 111. This allows a user who has knowledge of the proposed function to turn off the notification setting for the proposed function when using the proposed function for the first time.

[0026] On the other hand, if the user answers that the proposal needs to be continued (S110: Yes), the process proceeds to S120. In S120, the control unit 30 transmits a command to the notification setting recording unit 111 to reset the number of proposals for the proposed function presented this time. Then, the process returns to S10.

[0027] On the other hand, if it is determined in S60 that the current proposal is not the first proposal for the proposed function (S60: NO), the process proceeds to S70. In S70, the control unit 30 determines whether or not the user has used the proposed function before. This determination may be made based on, for example, the usage history read out from the history information recording unit 112. If the user has not used the proposed function before (S70: NO), the process proceeds to S80.

[0028] In S80, the control unit 30 judges whether or not the current proposal corresponds to a proposal made immediately after the first use of the proposal function. The predetermined period for judging whether or not it is immediately after can be set appropriately. For example, the predetermined period may be 10 minutes or 1 hour. If the judgment is affirmative (S80: YES), the process proceeds to S110. The contents after S110 have already been explained.

[0029] On the other hand, if a negative judgment is made in S80 (S80: NO), the process proceeds to S90. In S90, the control unit 30 judges whether or not the number of times the proposed function has been proposed has reached a first predetermined number or more. If a negative judgment is made (S90: NO), the process returns to S10, and if a positive judgment is made (S90: YES), the process proceeds to S110. The contents from S110 onwards have already been explained. This allows a user who has been proposed a proposed function the first predetermined number of times or more to turn off the notification setting for the proposed function.

[0030] On the other hand, if it is determined in S70 that the user has used the proposed function (S70: YES), the process proceeds to S100. In S100, the control unit 30 determines whether the number of times the proposed function has been proposed is equal to or greater than a second predetermined number. Here, the second predetermined number is smaller than the first predetermined number. If the result is negative (S100: NO), the process returns to S10, and if the result is positive (S100: YES), the process proceeds to S110. The contents from S110 onwards have already been explained. This allows a user who has been proposed the proposed function the first predetermined number of times or more to turn off the notification setting for the proposed function.

[0031] The number of times of proposals at which the notification setting of the proposed function can be turned off is smaller for a user who has used the proposed function (the second predetermined number) than for a user who has not used the proposed function (the first predetermined number). This makes it possible to prevent a situation in which proposals are made more repeatedly than necessary to a user who has used the proposed function.

[0032] (effect) The problem will be described. When frequently used functions are preferentially suggested, the same function may be repeatedly suggested. Also, when suggested functions are selected based on the user's driving behavior, the same function may be repeatedly suggested due to the repetition of similar driving behavior. As a result, the suggested functions may be biased unintended by the user. Then, unused functions are not suggested, and there is a risk that the unused state of the function will continue. Also, the repeated suggestion of functions that the user already knows may cause annoyance to the user. As a result, there is a risk that the user will lose the opportunity to know unused functions if the user turns off the function suggestion function itself.

[0033] Therefore, in the technology of this specification, it is possible to inquire of the user whether or not the proposed function should be continued depending on the number of times the proposed function is presented. Since the frequency of use of the user and the dependency on the driving behavior can be reduced, it is possible to prevent the same function from being repeatedly proposed. As a result, it is possible to propose unused functions. In addition, since it is possible to confirm the user's intention regarding the functions to be continued to be proposed, it is possible to customize the proposed functions to reflect the intentions of each individual user. As a result, it is possible to propose appropriate functions to the user, and it is possible to prevent the user from feeling annoyed.

[0034] (Modification) The various settings (e.g., proposal flag, number of proposals) stored in the notification setting recording unit 111 and the various information (e.g., number of uses, cumulative usage time) stored in the performance information recording unit 112 may be made shareable between a plurality of vehicles. This allows, for example, when a user replaces his / her vehicle, the settings and information of the previous vehicle to be carried over to the new vehicle. In the new vehicle, it becomes possible to control the function proposal process with the same contents as in the previous vehicle.

[0035] In the step (S20) of presenting the proposed function to the user, the content of the proposal may be changed according to the number of proposals made in the past and the usage history. For example, the more the number of proposals made and the more the usage history, the more practical the usage method of the proposed function may be proposed.

[0036] The notification setting recording unit 111 and the performance information recording unit 112 are not limited to being arranged in the server 100, and may be arranged in the vehicle .

[0037] The function suggestion system is not limited to a voice interactive system, and may be, for example, a text interactive system. In this case, an image related to the proposed function may be displayed on the touch panel 43, and a user's input may be received through the touch panel 43. Also, the system may be an interactive system using both voice and text.

[0038] The server 100 may be connectable to a large number of vehicles and may execute the function suggestion process for each vehicle.

[0039] The vehicle-mounted device 20 is an example of a vehicle user interface. [Explanation of symbols]

[0040] 1: Function proposal system 10: Vehicle 20: In-vehicle device 30: Control unit 31: Proposed function determination unit 32: Function usage detection unit 33: HMI output unit 34: Setting unit 100: Server

Claims

[Claim 1] 1. A vehicle user interface for a multi-function vehicle, comprising: a presentation means for selecting a function to be proposed to the user from among the plurality of functions and presenting the selected function to the user; a storage means for storing the number of times each of the functions has been presented by the presentation means for each of the plurality of functions; an inquiry means for inquiring of a user as to whether or not the proposed function should be continued, based on the number of times the function has been presented and the user's usage record, after the function has been presented by the presentation means; Equipped with When the user responds to the inquiry that continuation of the proposal is unnecessary, the presenting means excludes the currently presented function from future proposal targets. Vehicle user interface.

Citation Information

Patent Citations

  • Context-sensitive application / event activation for people with different cognitive ability levels

    JP2016512623A

Cited By

  • Vehicle control device, vehicle control method, and program

    WO2026211066A1