Information processing device

Abstract

To propose a detour so as to prevent a user from feeling inconvenience.SOLUTION: A control part of an information processing device acquires an acceptance ratio of vehicle users to past detour proposals in the case that there is a detour recommendation section of recommending a detour on a route of a vehicle. Then, the control part of the information processing device outputs proposal information to propose to detour the detour recommendation section in accordance with the acceptance ratio.SELECTED DRAWING: Figure 5

Description

Technical Field

[0001] This disclosure relates to an information processing apparatus.

Background Art

[0002] Patent Document 1 discloses a navigation apparatus. The navigation apparatus disclosed in Patent Document 1 detects a prohibited entry node which is a node where traffic regulation information of prohibited entry is set. The navigation apparatus detects a plurality of road links that are successively connected from the detected prohibited entry node and are road links in a predetermined section where driving can be presumed to be restricted. The navigation apparatus sets driving restriction information for route search for the detected plurality of road links. Then, the navigation apparatus performs route search with the plurality of road links for which the driving restriction information is set as a restricted section.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] An object of this disclosure is to propose a detour so that a user does not feel bothered.

Means for Solving the Problems

[0005] The information processing apparatus according to this disclosure acquires a acceptance rate of a user of the vehicle with respect to a past proposal of a detour when there is a detour recommended section where a detour is recommended on a route of the vehicle, outputs proposal information for proposing to detour around the detour recommended section according to the acceptance rate, and includes a control unit configured to execute the above.

Advantages of the Invention

[0006] According to the present disclosure, it is possible to propose a detour so that the user does not feel bothered.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Modes for Carrying Out the Invention

[0008] It is assumed that when there is a detour recommended section where a detour is recommended on the route on which the vehicle travels, a detour of the detour recommended section is proposed to the user of the vehicle. At this time, if the user of the vehicle is a user who does not need a detour proposal, the user may feel bothered by the detour proposal. Therefore, the information processing apparatus according to the present disclosure solves such a problem.

[0009] When there is a detour recommended section on the route of the vehicle, the control unit of the information processing apparatus according to the present disclosure acquires the acceptance rate of the user for the past detour proposals (hereinafter, may be simply referred to as "acceptance rate"). Thereby, the control unit of the information processing apparatus can grasp the necessity of proposing a detour to the user. At this time, when the acceptance rate is high, it is assumed that the user needs a detour proposal as compared with the case where the acceptance rate is low. Therefore, the control unit outputs proposal information for proposing to detour the detour recommended section according to the acceptance rate.

[0010] As described above, the information processing apparatus outputs proposal information according to the acceptance rate. Thereby, according to the necessity of the detour proposal that can be assumed from the acceptance rate, it is possible to propose a detour of the detour recommended section. As a result, it is possible to propose a detour so that the user does not feel bothered.

[0011] Hereinafter, specific embodiments of the present disclosure will be described with reference to the drawings. The hardware configuration, module configuration, functional configuration, etc. described in each embodiment are not intended to limit the technical scope of the disclosure only to those unless otherwise specified.

[0012] <Embodiment> (Outline of the system) The proposal system 1 in the present embodiment will be described with reference to FIG. 1. FIG. 1 is a diagram showing a schematic configuration of the proposal system 1. The proposal system 1 includes an in-vehicle device 100 and a server 200. In the proposal system 1, the in-vehicle device 100 and the server 200 are connected to each other by a network N1. As the network N1, for example, a WAN (Wide Area Network) which is a worldwide public communication network such as the Internet or a telephone communication network such as a mobile phone may be adopted.

[0013] (In-vehicle device) The in-vehicle device 100 is a device mounted on the vehicle 10. The in-vehicle device 100 provides various information to the user of the vehicle 10. The in-vehicle device 100 is, for example, a car navigation system. The user of the vehicle 10 inputs a destination to the in-vehicle device 100. The in-vehicle device 100 transmits destination information indicating the current position and destination of the vehicle 10 to the server 200 via the network N1.

[0014] The in-vehicle device 100 receives route information via the network N1. The route information is information including the planned driving route of the vehicle 10. When the in-vehicle device 100 receives the route information, it outputs (displays on a display, and outputs as voice, etc.) the route information to the user of the vehicle 10. Also, the in-vehicle device 100 receives proposal information from the server 200 via the network N1. The proposal information is information that proposes to bypass a section on the planned driving route. When the in-vehicle device 100 receives the proposal information, it outputs (displays, etc.) the proposal information to the user of the vehicle 10.

[0015] (Server) The server 200 is a server device that manages the driving of the vehicle. The server 200 receives destination information from the in-vehicle device 100 via the network N1. The server 200 generates a planned driving route of the vehicle 10 according to the destination information. At this time, there may be a section (hereinafter, may be referred to as "detour recommended section") on the planned driving route of the vehicle 10 where detouring is recommended. The reason for recommending a detour is, for example, a road closure of part or all of the section, flooding, traffic jam, or snow accumulation, etc. In such a case, it is assumed that the server 200 proposes to the user of the vehicle 10 to bypass the detour recommended section. Specifically, the server 200 proposes to bypass the detour recommended section by transmitting the proposal information to the in-vehicle device 100. to propose.

[0016] At this time, depending on the user, there may be cases where a detour proposal is unnecessary. If so, the user may feel annoyed by being presented with an unnecessary detour proposal. Therefore, the acceptance rate of the vehicle 10 for past detour proposals (hereinafter, may be simply referred to as the "acceptance rate") is obtained.

[0017] At this time, when the acceptance rate is high, it is assumed that the user needs a detour proposal compared to when the acceptance rate is low. On the other hand, when the acceptance rate is low, it is assumed that the user of the vehicle 10 does not need a detour proposal compared to when the acceptance rate is high. In this way, by obtaining the acceptance rate, the server 200 can grasp the necessity of proposing a detour to the user of the vehicle 10. Therefore, if an unnecessary detour proposal is made to the user when the acceptance rate is low compared to when the acceptance rate is high, it is assumed that the user will feel annoyed. Therefore, the server 200 outputs proposal information to the in-vehicle device 100 according to the acceptance rate.

[0018] In the present embodiment, the server 200 outputs proposal information to the in-vehicle device 100 via the network N1 when the acceptance rate is equal to or higher than the threshold value. Also, in the present embodiment, the server 200 may not output the proposal information when the acceptance rate is less than the threshold value. A detailed description of the output of the proposal information by the server 200 will be described later.

[0019] Server 200 is configured to include a computer having a processor 210, a main memory unit 220, an auxiliary storage unit 230, and a communication interface (communication I / F) 240. The processor 210 is, for example, a CPU (Central Processing Unit) or a DSP (Digital Signal Processor). The main memory unit 220 is, for example, a RAM (Random Access Memory). The auxiliary storage unit 230 is, for example, a ROM (Read Only Memory). Also, the auxiliary storage unit 230 is, for example, an HDD (Hard Disk Drive), or a disk recording medium such as a CD-ROM, a DVD disk, or a Blu-ray disk. Further, the auxiliary storage unit 230 may be a removable medium (portable storage medium). Here, examples of the removable medium include a USB memory or an SD card. The communication I / F 240 is, for example, a LAN (Local Area Network) interface board or a wireless communication circuit for wireless communication.

[0020] In server 200, the auxiliary storage unit 230 stores an operating system (OS), various programs, and various information tables, etc. Also, in server 200, by the processor 210 loading the program stored in the auxiliary storage unit 230 into the main memory unit 220 and executing it, various functions as described later can be realized. However, some or all of the functions in server 200 may be realized by a hardware circuit such as an ASIC or an FPGA. Note that server 200 does not necessarily have to be realized by a single physical configuration, and may be configured by a plurality of computers that cooperate with each other. Also, the in-vehicle device 100 is also configured to include a computer, similar to server 200.

[0021] (Functional Configuration) Next, the proposed system 1 is configured. The functional configuration of the server 200 will be described based on FIGS. 2 to 4. FIG. 2 is a block diagram schematically showing an example of the functional configuration of the server 200. The server 200 includes a control unit 201, a communication unit 202, a road information database 203 (road information DB 203), and a history information database 204 (history information DB 204).

[0022] The control unit 201 has a function of performing arithmetic processing for controlling the server 200. The control unit 201 can be realized by a processor 210 in the server 200. The communication unit 202 has a function of connecting the server 200 to the network N1. The communication unit 202 can be realized by a communication I / F 240 in the server 200.

[0023] The control unit 201 receives destination information from the in-vehicle device 100 via the communication unit 202. The control unit 201 refers to the current position and the destination of the vehicle 10 included in the destination information, and determines the planned travel route of the vehicle 10. Here, the control unit 201 determines, for example, the route with the shortest travel distance among a plurality of routes from the current position of the vehicle 10 to the destination as the planned travel route. The control unit 201 transmits the determined planned travel route to the in-vehicle device 100 via the communication unit 202.

[0024] The road information DB 203 has a function of holding road information. The road information DB 203 can be realized by an auxiliary storage unit 230 in the server 200. FIG. 3 is a diagram showing an example of the table configuration of the road information held in the road information DB 203. The road information is information indicating whether a detour is recommended in each section. As shown in FIG. 3, the road information has a section ID field, a start point field, an end point field, a detour field, and an event field.

[0025] The interval ID field stores an identifier (interval ID) for identifying a road interval. The start point field stores information indicating the start point of the interval corresponding to the interval ID. The end point field stores information indicating the end point of the interval corresponding to the interval ID. Here, the interval ID is, for example, an identifier for identifying a road link. At this time, the start point field stores an identifier for identifying the node at the start point of the road link corresponding to the interval ID. Also, the end point field stores an identifier for identifying the node at the end point of the road link corresponding to the interval ID.

[0026] The detour field stores information indicating whether a detour for the interval corresponding to the interval ID is recommended. If a detour for the interval corresponding to the interval ID is recommended, the detour field stores information "Recommended". If a detour for the interval corresponding to the interval ID is not recommended (not necessary), the detour field stores information "Not required".

[0027] The event field stores information indicating the event that caused the detour of the interval corresponding to the interval ID when "Recommended" is entered in the corresponding detour field. Here, the event field stores information indicating a partial or complete closure of the interval, flooding, traffic jam, or snow accumulation, etc. In the event field shown in FIG. 3, the event field corresponding to the interval for which a detour is recommended stores information "Flooding". Also, in the event field shown in FIG. 3, the event field corresponding to the interval for which a detour is not recommended stores information "---".

[0028] The control unit 201 updates the road information by acquiring in real time from other server devices or the like that manage the road whether or not a detour is recommended for each section ID. Further, the control unit 201 may perform image analysis on the state of the section included in the moving image captured by the cameras mounted on a plurality of vehicles during travel, and determine whether or not to recommend a detour. In this case, the control unit 201 determines whether or not waterlogging, traffic congestion, snow accumulation, or the like has occurred by performing image analysis on the acquired moving image.

[0029] The history information DB 204 has a function of holding history information. The history information is information indicating the history of acceptance by the user of vehicle 10 of a detour proposal in the past. The history information DB 204 can be realized by the auxiliary storage unit 230 in the server 200. FIG. 4 is a diagram showing an example of the table configuration of the history information held in the history information DB 204. As shown in FIG. 4, the history information has a user ID field, an event field, a section ID field, a date and time ID field, and a proposal result field. The user ID field stores an identifier (user ID) for identifying the user. The event field stores information indicating the event that caused a detour to be recommended for the section for the user corresponding to the user ID. The event field stores information indicating partial or complete road closure, waterlogging, traffic congestion, snow accumulation, or the like in the section. The section ID field stores an identifier (section ID) for identifying the section for which a detour was proposed due to the corresponding event in the past. The date and time information field stores information indicating the date and time when a detour was proposed for the corresponding section in the past. The proposal result field stores information indicating whether or not the user accepted the proposal after the detour was proposed due to the corresponding event in the past.

[0030]

[0031] In this way, in the history information, for each event, the section ID, the information indicating the date and time when the detour was proposed, and the information indicating the result of the detour proposal are stored. By acquiring the history information held in the history information DB 204, the control unit 201 can grasp the acceptance result of the vehicle user for the past detour proposals.

[0032] By acquiring the road information stored in the road information DB 203, the control unit 201 can determine whether there is a detour recommended section on the planned travel route of the vehicle 10 in the route information. Specifically, the control unit 201 acquires the section ID of each section included in the planned travel route in the route information. The control unit 201 determines whether there is a section where a detour is recommended by referring to the detour field of the section corresponding to the section ID that matches the section ID acquired from the route information among the section IDs of each section in the road information.

[0033] When the control unit 201 determines that there is a detour recommended section on the planned travel route of the vehicle 10, it acquires the history information from the history information DB 204. The control unit 201 refers to the information in the proposal result field in the acquired history information and calculates the acceptance rate of the vehicle 10 user. Specifically, the control unit 201 calculates the acceptance rate by referring to the information in the proposal result field in the history information and subtracting the number of times the vehicle 10 user accepted the detour proposal of the section from the number of times the detour proposal of the section was made in the past. Then, the control unit 201 calculates whether the acceptance rate of the vehicle 10 user is equal to or higher than the threshold value.

[0034] At this time, it is assumed that the acceptance rate of the user of the vehicle 10 varies for each event that caused the detour to be recommended. For example, the vehicle 10 may be equipped with studless tires. In this case, the user of the vehicle 10 may not need to detour even in a snow-covered section. On the other hand, the user of the vehicle 10 may accept a proposal to detour when an event other than snow (e.g., traffic jam, etc.) occurs. Thus, it is assumed that the acceptance rate of the user of the vehicle 10 varies for each event that caused the detour to be recommended. Therefore, the control unit 201 acquires information indicating the event that caused the detour to be recommended in the detour recommended section from the event field in the road information held in the road information DB 203. Then, the control unit 201 refers to the history information held in the history information DB 204 and calculates the acceptance rate for the event that caused the detour to be recommended in the detour recommended section. That is, when the event that caused the detour to be recommended in the detour recommended section is, for example, snow accumulation, the control unit 201 calculates the acceptance rate when the detour of the section was recommended due to snow accumulation in the past.

[0035] When the acceptance rate of the user of the vehicle 10 is equal to or higher than the threshold value, the control unit 201 outputs proposal information. Thereby, when the acceptance rate for the event that caused the detour to be recommended in the detour recommended section is equal to or higher than the threshold value, the proposal information is output.

[0036] Also, when the acceptance rate of the user of the vehicle 10 is less than the threshold value, the control unit 201 acquires load information. Here, the load information is information indicating the driving load situation of the user of the vehicle 10. Here, when the vehicle 10 is traveling on a road with many curves, it is assumed that the driving load of the user is higher than when traveling on a road with few curves. Therefore, in the present embodiment, the load information is indicated by the number of curves existing within a predetermined range from the current position of the vehicle 10 and existing on the route that the vehicle 10 has traveled and on the planned travel route.

[0037] The control unit 201 calculates the driving load status of the user of the vehicle 10 based on the planned driving route in the route information and the current position of the vehicle 10. Specifically, the control unit 201 acquires the number of curves that exist within a predetermined range from the current position of the vehicle 10 and that are on the planned driving route. The control unit 201 acquires the number of curves by referring to the map information. Then, when the number of acquired curves is equal to or greater than a predetermined number, the control unit 201 determines that the driving load of the user of the vehicle 10 is high (high load status). Also, when the number of acquired curves is less than the predetermined number, the control unit 201 determines that the driving load of the user of the vehicle 10 is low.

[0038] Here, it is assumed that the user in a high load situation is concentrating on driving. At that time, if an unnecessary detour is proposed to a user who does not need a detour proposal, it is assumed that the user will feel annoyed. On the other hand, even a user who does not need a detour proposal is not expected to feel annoyed if a detour proposal is made when not in a high load situation. Therefore, when the acceptance rate of the user of the vehicle 10 is less than the threshold value, the control unit 201 refers to the load information and determines whether the user of the vehicle 10 is in a high load situation. When the user of the vehicle 10 is in a high load situation, the control unit 201 does not output the proposal information because it is assumed that the user will feel annoyed. Also, when the user of the vehicle 10 is not in a high load situation, the control unit 201 outputs the proposal information to the in-vehicle device 100 because it is assumed that the user will not feel annoyed.

[0039] After outputting the proposal information to the in-vehicle device 100, the control unit 201 determines whether the user of the vehicle 10 has accepted the detour proposal. Specifically, the control unit 201 refers to the current position of the vehicle 10 and determines whether the vehicle 10 has traveled through the detour recommended section. Here, the control unit 201 receives in real time from the in-vehicle device 100 the current position of the vehicle 10 acquired by the GPS device in the vehicle 10.

[0040] When the current position of the vehicle 10 is not on the detour recommended section until the vehicle 10 reaches the destination, the control unit 201 determines that the user of the vehicle 10 has accepted the proposal for detour. Also, when the current position of the vehicle 10 is on the detour recommended section, the control unit 201 determines that the user of the vehicle 10 has not accepted the proposal for detour. The control unit 201 records the result of acceptance of detour by the user of the vehicle 10 in the history information held in the history information DB 204. In this way, the history information is updated. Thereby, the control unit 201 can grasp the latest data regarding the acceptance result (acceptance rate) of the user.

[0041] (First Process) Next, in the proposal system 1, the first process executed by the control unit 201 in the server 200 will be described with reference to FIG. 5. FIG. 5 is a flowchart of the first process. That is. The first process shown in FIG. 5 is a process of outputting proposal information. The first process is repeatedly executed at a predetermined interval after transmitting the route information to the in-vehicle device 100.

[0042] In the first process, first, in S101, the route information transmitted to the in-vehicle device 100 is acquired. Next, in S102, the road information is acquired from the road information DB 203. Next, in S103, the detour field in the acquired road information is referred to, and it is determined whether there is a detour recommended section. Next, in S104, the history information is acquired from the history information DB 204. Next, in S105, it is determined whether the acceptance rate is equal to or higher than the threshold value. At this time, it is determined whether the acceptance rate regarding the event that caused the detour to be recommended in the detour recommended section is equal to or higher than the threshold value.

[0043] If an affirmative determination is made in S105, it is assumed that there is a high need for a detour proposal for the user of vehicle 10. Therefore, when an affirmative determination is made in S105, in S106, the proposal information is output to the in-vehicle device 100. As a result, the in-vehicle device 100 outputs a proposal to the user of vehicle 10 to detour around the detour recommended section. Thereby, a detour proposal can be made to the user who needs a detour proposal. Then, the first process is temporarily terminated.

[0044] Also, when a negative determination is made in S105, the load information is acquired in S107. Next, in S108, it is determined whether the user of vehicle 10 is in a high-load situation. Specifically, the load information is referred to, and it is determined whether the number of curves on the planned travel route within a predetermined range from the current position of vehicle 10 is equal to or greater than a predetermined number. If an affirmative determination is made in S108, since the user of vehicle 10 is in a high-load situation, if the in-vehicle device 100 outputs the proposal information, it is assumed that the user of vehicle 10 will feel bothered. Therefore, when an affirmative determination is made in S108, without outputting the proposal information to the in-vehicle device 100, the first process is temporarily terminated.

[0045] Also, when a negative determination is made in S108, since the user of vehicle 10 is not in a high-load situation, it is assumed that the vehicle 10 has mental leeway. Therefore, it is assumed that even if the in-vehicle device 100 outputs the proposal information, the user of vehicle 10 will not feel bothered. Therefore, when a negative determination is made in S108, in S106, the proposal information is output (transmitted) to the in-vehicle device 100. As a result, the in-vehicle device 100 outputs a proposal to the user of vehicle 10 to detour around the detour recommended section. Then, the first process is temporarily terminated.

[0046] In addition, the first process is repeatedly executed at predetermined intervals after transmitting the route information to the in-vehicle device 100. Also, the road information is updated by obtaining in real time whether or not a detour is recommended for each section ID. That is, when an event of newly recommending a detour occurs, information about the event is included in the road information. Therefore, by repeatedly obtaining the road information, it is possible to determine whether or not to output the proposal information even when an event of newly recommending a detour occurs.

[0047] (Second process) Next, in the proposal system 1, the second process executed by the control unit 201 in the server 200 will be described with reference to FIG. 6. FIG. 6 is a flowchart of the second process. The second process shown in FIG. 6 is a process of updating the history information. The second process is executed after outputting the proposal information to the in-vehicle device 100.

[0048] In the second process, first, in S201, the current position of the vehicle 10 received from the in-vehicle device 100 is obtained. Next, in S202, with reference to the current position of the vehicle 10, it is determined whether or not the vehicle 10 is traveling in a detour-recommended section. That is, it is determined whether or not the current position of the vehicle 10 is on the detour-recommended section.

[0049] If an affirmative determination is made in S202, since the vehicle 10 is traveling in a detour-recommended section, it can be determined that the user of the vehicle 10 did not accept the detour proposal. Therefore, if an affirmative determination is made in S202, in S203, the history information held in the history information DB204 is updated. At this time, information indicating that the user of the vehicle 10 did not accept the detour proposal is added to the history information. Then, the second process ends.

[0050] When a negative determination is made in S202, the user of vehicle 10 is not driving in the detour-recommended section at the time of determination. However, the user of vehicle 10 may drive in the detour-recommended section afterwards. Therefore, when a negative determination is made in S202, in S204, it is determined whether vehicle 10 has reached the destination. Specifically, the destination of vehicle 10 included in the destination information is referred to, and it is determined whether vehicle 10 has reached the destination.

[0051] When a negative determination is made in S204, vehicle 10 has not reached the destination. Therefore, the current position of vehicle 10 is acquired again in S201. At this time, since the current position of vehicle 10 is received in real time, the acquired current position of vehicle 10 is the latest current position of vehicle 10. Then, referring to the latest current position of vehicle 10, the process of S202 is performed. Also, according to the determination result of S202, the processes of S203 and S204 are executed. In this way, the processes of S201 and S202 are repeatedly performed until vehicle 10 reaches the destination.

[0052] In S204, when an affirmative determination is made, vehicle 10 has reached the destination without driving in the detour-recommended section. Therefore, it can be determined that the user of vehicle 10 has accepted the detour proposal. Therefore, in S205, the history information held in the history information DB204 is updated. At this time, information indicating that the user of vehicle 10 has accepted the detour proposal is added to the history information. Then, the second process ends.

[0053] In addition, in the present embodiment, the control unit 201 determines whether the user of the vehicle 10 has accepted the detour proposal by determining whether the vehicle 10 has traveled through the detour recommended section before reaching the destination. However, the user of the vehicle 10 may be determined whether to accept the detour proposal by other methods. The control unit 201 may receive, for example, information indicating an answer to the detour proposal by the user of the vehicle 10 from the in-vehicle device 100. In this case, by the user of the vehicle 10 inputting an answer to the detour proposal to the in-vehicle device 100, information indicating the answer to the detour proposal by the user of the vehicle 10 is transmitted to the server 200.

[0054] As described above, the proposal system 1 outputs proposal information according to the acceptance rate. Thereby, according to the necessity of the detour proposal that can be assumed from the acceptance rate, it is possible to propose a detour in the detour recommended section. Also, at that time, the acceptance rate for the event that caused the detour to be recommended in the detour recommended section is acquired. Thereby, when there is no need for a detour proposal associated with the event that caused the detour to be recommended in the detour recommended section, the output of the proposal information is suppressed. Also, even when it is assumed that the user of the vehicle 10 does not need a detour proposal because the acceptance rate is lower than the threshold value, the availability of the output of the proposal information is determined according to the driving load of the vehicle 10. Thereby, when the vehicle 10 during driving has no mental margin, the output of the proposal information by the in-vehicle device 100 is suppressed. In this way, it is possible to make a detour proposal so that the user does not feel bothered.

[0055] (Modification Example 1) In the present embodiment, the proposal information is such that the acceptance rate is less than the threshold value and the user of the vehicle 10 When in a high-load situation, the in-vehicle device 100 does not output proposal information. However, the proposal information may be output when the acceptance rate is equal to or higher than a threshold value, and may not be output when the acceptance rate is less than the threshold value. That is, when a negative determination is made in S105 during the execution of the first process, the processes of S107 and S108 may not be performed. In this case, when a negative determination is made in S105, the proposal information is not output, and the first process ends. Even in this way, a detour proposal can be made so that the user of the vehicle 10 does not feel bothered.

[0056] (Modification Example 2) In addition, the server 200 may change the method of outputting the proposal information in the in-vehicle device 100 according to the acceptance rate. Here, it is assumed that if a large amount of information is provided to the user of the vehicle 10, the user of the vehicle 10 may feel bothered. Therefore, the server 200 changes the amount of information provided to the user of the vehicle 10 according to the acceptance rate, thereby changing the method of outputting the proposal information in the in-vehicle device 100.

[0057] Specifically, when the acceptance rate is equal to or higher than the threshold value, proposal information for making a detour proposal using voice and display may be output. In this case, the proposal information includes, for example, data for outputting a voice for making a detour proposal and data for displaying a detour proposal on the display in the in-vehicle device 100. The in-vehicle device 100 uses these data to output a voice for making a detour proposal to the user of the vehicle 10 and to perform a display.

[0058] Specifically, the in-vehicle device 100 that has received the proposal information makes a detour proposal using voice by outputting a voice for making a detour proposal through a speaker. In addition, the in-vehicle device 100 that has received the proposal information makes a detour proposal using display by, for example, superimposing and displaying the position of the detour recommended section on the map displayed by the navigation system.

[0059] Also, when the acceptance rate is less than the threshold value, proposal information for making a detour proposal using voice may be output without making a detour proposal by display. In this case, the proposal information does not include data for displaying a detour proposal on the display in the in-vehicle device 100, but includes data for outputting a voice for making a detour proposal. The in-vehicle device 100 outputs a voice for proposing a detour to the vehicle 10 using the data for outputting a voice for making a detour proposal.

[0060] Thus, in this modified example, according to the acceptance rate, it is determined whether to make a detour proposal by voice and display or a detour proposal by voice for the method of outputting the proposal information in the in-vehicle device 100. At this time, when the user of the vehicle 10 needs a detour proposal, a more detailed detour proposal can be made to the user by making a detour proposal by voice and display.

[0061] Also, if the position of the detour recommended section is superimposed and displayed on the map displayed by the navigation system when the user of the vehicle 10 does not need a detour proposal, it is assumed that the user will feel annoyed. On the other hand, if only a detour proposal by voice is made, the amount of information provided to the user of the vehicle 10 is less than the case where a detour proposal by display is also made. Therefore, the annoyance felt by the user of the vehicle 10 can be suppressed. In this way, a detour proposal can be made so that the user does not feel annoyed.

[0062] (Modified Example 3) In the present embodiment, the load information exists within a predetermined range from the current position of the vehicle 10 It is indicated by the number of curves existing on the route along which the vehicle 10 has traveled and on the planned route. However, the load information may be information indicated by other means. For example, when the car navigation system (in-vehicle device 100) in the vehicle 10 frequently performs navigation, since the user of the vehicle 10 is concentrating on driving, it is assumed that the vehicle is in a high-load situation. Therefore, the load information may be information indicated by the timing of navigation by the in-vehicle device 100.

[0063] The server 200 obtains the load information, for example, by referring to the planned route of the vehicle 10 and predicting the timing at which the in-vehicle device 100 performs navigation. And the server 200 determines that it is not in a high-load situation at the timing when the in-vehicle device 100 does not perform navigation for a predetermined time or more.

[0064] Also, before the vehicle 10 departs, since the user of the vehicle 10 has not started driving, it is assumed that the vehicle is not in a high-load situation. Also, if the vehicle 10 is before departure, it is assumed that the user of the vehicle 10 is more likely to accept a route change associated with bypassing the recommended bypass section. On the other hand, after the vehicle 10 has departed, since the user of the vehicle 10 is driving, it is assumed that the vehicle is in a high-load situation. Also, after the vehicle 10 has departed, since it has already decided to drive along the planned route, it may be difficult to accept a route change associated with bypassing the recommended bypass section. Therefore, the load information may be information about whether the vehicle 10 has departed or not.

[0065] In this case, the server 200 receives load information from the in-vehicle device 100. The load information is, for example, the driving history of the vehicle 10, information on the timing of turning the ignition switch of the vehicle 10 on and off, or information on the driving schedule of the vehicle 10. The server 200 refers to the load information and determines whether the vehicle 10 is under a high load situation by determining whether the vehicle 10 is before departure. That is, the server 200 determines that it is under a high load situation when the vehicle 10 is not before departure. Also, the server 200 determines that it is not under a high load situation when the vehicle 10 is before departure.

[0066] And, when the acceptance rate is less than the threshold value and the vehicle 10 is not before departure, the server 200 does not output the proposal information to the in-vehicle device 100. Also, when the acceptance rate is less than the threshold value and the vehicle 10 is before departure, the server 200 outputs the proposal information to the in-vehicle device 100. Even in this way, it is possible to make a detour proposal so that the user of the vehicle 10 does not feel bothered.

[0067] (Modification Example 4) In the present embodiment, the first process is repeatedly executed at a predetermined interval after transmitting the route information to the in-vehicle device 100. That is, in the first process, when there is a detour recommended section on the planned driving route of the vehicle 10, it is determined whether to output the proposal information. On the other hand, in this modification example, the server 200 determines whether to output the proposal information without acquiring the planned driving route of the vehicle 10. Specifically, the server 200 determines whether there is a detour recommended section within a predetermined range from the current position of the vehicle 10. Here, the predetermined range is defined as a range in which the vehicle 10 may travel within a predetermined time. And when there is a detour recommended section within a predetermined range from the current position of the vehicle 10, it is determined whether the acceptance rate is equal to or higher than the threshold value, etc., and it is determined whether to output the proposal information. Even in this way, it is possible to make a detour proposal so that the user of the vehicle 10 does not feel bothered.

[0068] (Modification Example 5) Server 200 may reset the history information of the user of vehicle 10 stored in history information DB204 at a predetermined timing. Here, the predetermined timing is the timing when the user of vehicle 10 instructs the reset of the history information. Also, the predetermined timing may be the timing when a certain period has elapsed.

[0069] At this time, server 200 may delete the history information of the user of vehicle 10 in the period before a predetermined time. Also, control unit 201 may reset all the history information of the user of vehicle 10. In this case, control unit 201 transmits proposal information to in-vehicle device 100 regardless of the acceptance rate for a predetermined period after resetting the history information. Thereby, data for recalculating the acceptance rate during a predetermined period can be collected. Also, even when the necessity of the detour proposal for the user of vehicle 10 changes with the passage of time, the detour proposal can be made so that the user of vehicle 10 does not feel bothered.

[0070] <Other Embodiments> The above-described embodiments are merely examples, and the present disclosure can be appropriately modified and implemented without departing from the gist thereof. Also, the processes and means described in the present disclosure can be freely combined and implemented as long as no technical contradiction occurs.

[0071] Also, the processes described as being performed by one device may be shared and executed by a plurality of devices. Alternatively, the processes described as being performed by different devices may be executed by one device. In a computer system, how each function is realized by what hardware configuration (server configuration) can be flexibly changed.

[0072] The present disclosure can also be realized by supplying a computer program that implements the functions described in the above embodiments to a computer and causing one or more processors included in the computer to read and execute the program. Such a computer program may be provided to the computer by a non-transitory computer-readable storage medium connectable to the system bus of the computer, or may be provided to the computer via a network. The non-transitory computer-readable storage medium includes any type of disk such as a magnetic disk (e.g., a floppy (registered trademark) disk or a hard disk drive (HDD)), an optical disk (e.g., a CD-ROM, a DVD disk, or a Blu-ray disk), a read-only memory (ROM), a random access memory (RAM), an EPROM, an EEPROM, a magnetic card, a flash memory, or an optical card, or any other type of medium suitable for storing electronic instructions.

Explanation of Signs

[0073] 1 ··· Proposed System 10 ··· Vehicle 100 ··· In-vehicle Device 200 ··· Server 201 ··· Control Unit 202 ··· Communication Unit 203 ··· Road Information DB 204 ··· History Information DB

Claims

1. When there is a detour recommended section where detour is recommended on the route of the vehicle, obtaining the acceptance rate of the user of the vehicle for the past detour proposals; Outputting proposal information for proposing to detour through the detour recommended section according to the acceptance rate; Comprising a control unit configured to execute the above; An information processing device.

2. Obtaining the acceptance rate includes obtaining the acceptance rate when a detour proposal was made to the user in the past due to the same detour cause as the cause for recommending to detour through the detour recommended section. The information processing device according to Claim 1.

3. The control unit is configured to further obtain load information about the driving load of the user; Outputting the proposal information according to the acceptance rate includes outputting the proposal information according to the acceptance rate and the load information. The information processing device according to Claim 1 or 2.

4. Outputting the proposal information includes when the acceptance rate is equal to or higher than a threshold value, outputting proposal information for making a detour proposal using voice and display; when the acceptance rate is less than the threshold value, outputting proposal information for making a detour proposal using voice without making a detour proposal using display. The information processing device according to Claim 1 or 2.

5. Outputting the proposal information includes when the acceptance rate is equal to or higher than a threshold value, outputting the proposal information; when the acceptance rate is less than the threshold value, determining whether the vehicle has not yet departed; when the vehicle has not yet departed, outputting the proposal information; when the vehicle has already departed, omitting the output of the proposal information. The information processing device according to Claim 1 or 2. ​ ​ ​

Images