JP5941733B2 - In-vehicle device - Google Patents

Description

  The disclosed embodiment relates to an in-vehicle device.

  Conventionally, an integrated in-vehicle device in which functions such as a car navigation function and a car audio function are integrated into an integrated unit is known.

  Such an integrated vehicle-mounted apparatus has a mode corresponding to each function, and the user can select a desired function by performing a “mode switching” operation for switching the mode.

  In recent years, with the spread of wireless communication technology, in-vehicle devices that cooperate with mobile devices such as mobile phones have also been proposed (see, for example, Patent Document 1).

  The in-vehicle device in cooperation performs an operation such as setting a destination in the car navigation function by remote operation from the mobile device while transmitting / receiving data to / from the mobile device connected by wireless communication or the like. be able to.

  Therefore, the driver of the vehicle can enjoy the convenience that the desired function of the in-vehicle device can be used while entrusting the passenger without operating the in-vehicle device.

JP 2009-145158 A

  However, according to the conventional technology, the convenience at the time of cooperation described above may be impaired. Specifically, when the passenger who operates the mobile device is a child, the child operates the mobile device unintended by the driver. For example, the destination in the car navigation function described above is incorrect. There was a risk of being set.

  One aspect of the embodiments has been made in view of the above, and an object thereof is to provide an in-vehicle device that can appropriately cooperate with a portable device without impairing the convenience enjoyed by the driver.

  An in-vehicle device according to an aspect of an embodiment is an in-vehicle device having a cooperation mode that is a mode that operates in cooperation with a mobile device while communicating with the mobile device, and includes a communication control unit. When the communication control unit receives an instruction to switch to a non-cooperation mode that is a mode other than the cooperation mode during operation in the cooperation mode, an application including a remote operation for the in-vehicle device is executed in the portable device When it is in the middle, the communication between the in-vehicle device and the portable device is disconnected.

  According to one aspect of the embodiment, there is an effect that it is possible to appropriately cooperate with the mobile device without impairing the convenience enjoyed by the driver.

FIG. 1A is a diagram (part 1) illustrating an overview of a communication control method according to an embodiment. FIG. 1B is a diagram (part 2) illustrating an overview of the communication control method according to the embodiment. FIG. 2 is a block diagram illustrating a configuration of the in-vehicle device according to the first embodiment. FIG. 3 is a diagram illustrating an example of screen transition of the in-vehicle device according to the first embodiment. FIG. 4A is a diagram (part 1) illustrating an example of data items included in the instruction signal. FIG. 4B is a second diagram illustrating an example of data items included in the instruction signal. FIG. 5 is a flowchart illustrating a processing procedure executed by the in-vehicle device according to the first embodiment. FIG. 6: A is a figure (the 1) which shows the outline | summary of the vehicle-mounted apparatus which concerns on 2nd Embodiment. FIG. 6B is a diagram (part 2) illustrating an overview of the in-vehicle device according to the second embodiment. FIG. 6C is a diagram (part 3) illustrating an overview of the vehicle-mounted device according to the second embodiment. FIG. 7 is a flowchart illustrating a processing procedure executed by the in-vehicle device according to the second embodiment. FIG. 8 is a diagram illustrating an outline of the in-vehicle device according to the third embodiment. FIG. 9 is a block diagram illustrating a configuration of the in-vehicle device according to the third embodiment. FIG. 10A is a diagram (part 1) illustrating an example of a screen display of the in-vehicle device according to the third embodiment. FIG. 10B is a diagram (part 2) illustrating an example of a screen display of the in-vehicle device according to the third embodiment. FIG. 10C is a diagram (part 3) illustrating an example of a screen display of the in-vehicle device according to the third embodiment. FIG. 11 is a flowchart illustrating a processing procedure executed by the in-vehicle device according to the third embodiment. FIG. 12A is a diagram (part 1) illustrating an overview of an in-vehicle device according to a fourth embodiment. FIG. 12B is a diagram (part 2) illustrating an overview of the in-vehicle device according to the fourth embodiment. FIG. 12C is a diagram (part 3) illustrating an overview of the vehicle-mounted device according to the fourth embodiment. FIG. 13 is a block diagram illustrating a configuration of the in-vehicle device according to the fourth embodiment. FIG. 14A is a diagram (part 1) illustrating an example of data items included in an instruction signal of the in-vehicle device according to the fourth embodiment. FIG. 14B is a diagram (part 2) illustrating an example of data items included in the instruction signal of the in-vehicle device according to the fourth embodiment. FIG. 15 is a flowchart illustrating a processing procedure executed by the in-vehicle device according to the fourth embodiment. FIG. 16 is a diagram illustrating an outline of an in-vehicle device according to the fifth embodiment. FIG. 17 is a block diagram illustrating a configuration of the in-vehicle device according to the fifth embodiment. FIG. 18 is a flowchart illustrating a processing procedure executed by the in-vehicle device according to the fifth embodiment. FIG. 19 is a diagram illustrating an outline of an in-vehicle device according to the sixth embodiment. FIG. 20 is a block diagram illustrating a configuration of the in-vehicle device according to the sixth embodiment. FIG. 21A is a diagram (part 1) illustrating an example of a rejection reason notified by the in-vehicle device according to the sixth embodiment. FIG. 21B is a diagram (part 2) illustrating an example of the refusal reason notified by the in-vehicle device according to the sixth embodiment. FIG. 21C is a diagram (No. 3) illustrating an example of the refusal reasons notified by the in-vehicle device according to the sixth embodiment. FIG. 22 is a flowchart illustrating a processing procedure executed by the in-vehicle device according to the sixth embodiment.

  Hereinafter, an embodiment of an in-vehicle device disclosed in the present application will be described in detail with reference to the accompanying drawings. In addition, this invention is not limited by embodiment shown below.

  In the following description, it is assumed that the in-vehicle device is an integrated in-vehicle device. In the following, for convenience of explanation, the car navigation may be abbreviated as “navigation” and the application may be abbreviated as “application”.

  Moreover, below, after describing the outline | summary of the communication control method which concerns on embodiment using FIG. 1A and FIG. 1B, the vehicle-mounted apparatus to which the communication control method which concerns on embodiment is applied is demonstrated using FIGS. I decided to.

  First, an outline of a communication control method according to the embodiment will be described with reference to FIGS. 1A and 1B. 1A and 1B are diagrams illustrating an outline of a communication control method according to the embodiment.

  As illustrated in FIG. 1A, the in-vehicle device 10 according to the embodiment includes a cooperation mode that is provided in front of the passenger compartment of the vehicle 1 and operates in cooperation with the mobile device 20.

  In the cooperation mode, for example, when the mobile device 20 is a game machine, the output sound of the game application played by the passenger 3 can be output from the speaker 16 of the in-vehicle device 10.

  Further, for example, the passenger 3 can be caused to set a destination in the navigation function of the in-vehicle device 10 via an application having a navigation function that operates in the game machine.

  As a result, the driver 2 can entrust the operation of the in-vehicle device 10 to the passenger 3 who operates the portable device 20, so that the driver 2 uses the desired function of the in-vehicle device 10 while concentrating on his own driving operation. Can do.

  Here, the “cooperation mode” and the “non-cooperation mode” that is opposed to the cooperation mode will be described. The in-vehicle device 10 has a “navigation mode” that provides a navigation function, an “audio mode” that provides a playback function of a sound source such as a radio or a compact disc, and a video source such as a television or a DVD. The cooperation mode is a mode that is executed as one of the functions included in the “audio mode” and operates in cooperation with the mobile device 20 while communicating. On the other hand, the non-cooperation mode is executed as a function included in the “audio mode”, and is, in other words, various modes when the in-vehicle device 10 operates alone.

  Switching between the above-described cooperation mode and these non-cooperation modes can be performed by a “mode switching” operation on the vehicle-mounted device 10 of the driver 2. Such “mode switching” is usually performed by a simple operation such as a one-touch operation of a button.

  In addition, when the “mode switching” from the cooperation mode to the non-cooperation mode is performed, the in-vehicle device 10 and the mobile device 20 are considered in consideration of the response when the “mode switching” to the cooperation mode is assumed again. It is preferred that the communication connection between the two is maintained.

  Here, it is assumed that the passenger 3 is a child. In such a case, the operation of the mobile device 20 by the passenger 3 not intended by the driver 2 is performed, and there is a high possibility that the convenience in the cooperation mode is impaired, for example, the destination in the navigation function is set incorrectly.

  Therefore, it is conceivable that the driver 2 tries to prevent such a situation by performing “mode switching” from the cooperation mode to the non-cooperation mode from the simple operability. However, even if the mode is switched to the non-cooperation mode, if the communication between the in-vehicle device 10 and the portable device 20 is maintained as described above, the in-vehicle device 10 backs up the remote operation by the portable device 20 of the passenger 3. There is a risk of acceptance at the ground.

  Therefore, in the communication control method according to the embodiment, when the in-vehicle device 10 receives an instruction to switch to the non-cooperation mode during the operation in the cooperation mode, the app that allows the remote operation of the in-vehicle device 10 is the mobile device 20. If it is in progress, the communication between the in-vehicle device 10 and the portable device 20 is forcibly disconnected.

  This will be specifically described below. As shown in FIG. 1B, it is assumed that a “mode switching” operation to the non-cooperation mode by the driver 2 is received while the in-vehicle device 10 is operating in the cooperation mode (see “Step 1” in the figure).

  At this time, as shown in FIG. 1B, if an app that allows remote operation of the in-vehicle device 10 (hereinafter referred to as “remote mode app”) is being executed in the mobile device 20, the in-vehicle device 10 is The communication between the in-vehicle device 10 and the portable device 20 is forcibly disconnected (see “Step 2-a” in the figure). Here, the remote mode application is an application that can perform destination setting in the navigation function of the in-vehicle device 10, for example.

  On the other hand, if the mobile device 20 is executing an application that is not allowed to remotely operate the in-vehicle device 10 (hereinafter, referred to as “non-remote mode app”), the in-vehicle device 10 is portable with the in-vehicle device 10. Communication with the device 20 is maintained (see “Step 2-b” in the figure).

  Here, the non-remote mode application is an application that outputs the sound of Karaoke (registered trademark) from the speaker 16 of the in-vehicle device 10, for example. In the case of such a non-remote mode application, for example, a measure such as stopping sound reproduction by the application may be taken while maintaining communication when switched to the non-cooperation mode.

  Thereby, the driver 2 can reliably prevent the mobile device 20 from remotely operating the in-vehicle device 10 with one simple “mode switching” operation. That is, even if the driver 2 is highly likely to perform an inappropriate operation of the mobile device 20 by the passenger 3, the in-vehicle device 10 that includes the cooperation function is not affected by the driver's own driving operation. The desired function can be appropriately utilized. Further, it is possible to suppress the battery consumption of the portable device 20 caused by maintaining communication.

  In addition, for non-remote mode apps that are unlikely to be remotely controlled, communication is made with good response when the mode is switched to the linked mode again, and the functions of the non-remote mode apps can be used without stress. can do.

  Therefore, it is possible to cooperate with the portable device 20 without impairing convenience. Hereinafter, an embodiment of the in-vehicle device 10 to which the communication control method described with reference to FIG. 1 is applied will be described in detail as a “first embodiment” with reference to FIGS.

  By the way, when the driver | operator 2 acquires the convenience in the cooperation function mentioned above, maintaining safety, the vehicle-mounted apparatus 10 is good also as having a various function further. For example, it is good also as urging attention in the cooperation mode. Hereinafter, such an embodiment will be described in detail as a “second embodiment” with reference to FIGS. 6A to 7.

  Similarly, an instruction request from the portable device 20 that may be inappropriate may be canceled by a one-touch operation. Hereinafter, an embodiment in such a case will be described as a “third embodiment” with reference to FIGS. 8 to 11.

  Similarly, an instruction request from the portable device 20 that may be inappropriate may be displayed on the confirmation screen to allow the driver 2 to confirm. Hereinafter, an embodiment in such a case will be described as a “fourth embodiment” with reference to FIGS. 12A to 15.

  Similarly, when the operation by the mobile device 20 is being accepted, a BGM informing that may be output from the speaker 16. Hereinafter, an embodiment in such a case will be described as a “fifth embodiment” and will be described in detail with reference to FIGS. 16 to 18.

  Moreover, when the instruction request from the portable device 20 cannot be accepted, the reason for refusal may be notified to the portable device 20 side. Hereinafter, such an embodiment will be described in detail as a “sixth embodiment” with reference to FIGS. 19 to 22.

  In the following, it is assumed that the mobile device 20 is always operated by the passenger 3. In the following, a case where the instruction request from the portable device 20 is mainly a destination setting request in the navigation function will be described as an example.

(First embodiment)
FIG. 2 is a block diagram illustrating a configuration of the in-vehicle device 10 according to the first embodiment. In FIG. 2, only components necessary for explaining the characteristics of the in-vehicle device 10 are shown, and descriptions of general components are omitted.

  As illustrated in FIG. 2, the in-vehicle device 10 includes a short-range communication unit 11, an operation unit 12, a GPS unit 13, a vehicle speed acquisition unit 14, a display unit 15, a speaker 16, a control unit 17, and a storage. Part 18.

  The control unit 17 further includes an instruction receiving unit 17a, a mode switching unit 17b, a navigation control unit 17d, and an audio control unit 17e. The audio control unit 17e further includes a cooperation control unit 17c and a non-cooperation control unit 17f. The storage unit 18 stores map information 18a and acoustic information 18b. The detailed configurations of the cooperation control unit 17c and the navigation control unit 17d will be described later.

  The short-range communication unit 11 is a communication unit for transmitting and receiving data to and from the portable device 20 by short-range wireless communication using Bluetooth (registered trademark). Similarly, the mobile device 20 is also equipped with a short-range wireless communication function based on Bluetooth (registered trademark). The mobile device 20 is, for example, a device such as a mobile phone, a PHS (Personal Handy-phone System), a PDA (Personal Digital Assistant), or a game machine.

  Here, the portable device 20 will be described. The portable device 20 includes a short-range communication unit 21, an operation unit 22, a display unit 23, a control unit 24, and a storage unit 25. And according to operation to the operation part 22 by the passenger 3, the control part 24 reads and executes the program of the application 25a memorize | stored in the memory | storage part 25, and the vehicle-mounted apparatus 10 and the portable apparatus 20 communicate. Connected as possible.

  For example, the control unit 24 reads and executes the program of the application 25 a and transmits a destination setting request based on an instruction operation to the operation unit 22 by the passenger 3 to the in-vehicle device 10 via the short-range communication unit 21. .

  In the present embodiment and other embodiments described later, a case where communication between the in-vehicle device 10 and the portable device 20 is performed using Bluetooth (registered trademark) will be described. However, Wi-Fi (registered trademark), Another wireless communication standard such as ZIGBEE (registered trademark) may be used. Moreover, it is good also as performing communication between the vehicle equipment 10 and the portable apparatus 20 by wired communication.

  Returning to the description of the in-vehicle device 10. The operation unit 12 is an input device including a “mode switch” button and the like. The GPS unit 13 includes a GPS antenna (not shown) and a GPS receiver. The GPS antenna receives a GPS signal from a satellite and transmits the GPS signal to a GPS receiver. The GPS receiver outputs GPS information generated by demodulating the GPS signal received from the GPS antenna to the control unit 17.

  The vehicle speed acquisition unit 14 includes a vehicle speed sensor and constantly acquires the vehicle speed of the host vehicle. In addition, the vehicle speed acquisition unit 14 outputs the acquired vehicle speed information to the control unit 17.

  The display unit 15 is an output unit configured by an output device such as a liquid crystal display, and displays, for example, a route guidance screen included in the route information generated by the navigation control unit 17d. The speaker 16 is an output unit that outputs an acoustic signal under the control of the audio control unit 17e.

  The control unit 17 performs overall control of the in-vehicle device 10. FIG. 2 shows a functional configuration of the control unit 17. The control unit 17 is physically configured by a CPU (Central Processing Unit), a ROM (Read Only Memory), and a RAM (Random). And an information processing unit having an (Access Memory).

  Then, the CPU reads various programs from the ROM and executes them using the RAM as a work area, so that each processing unit such as the cooperation control unit 17c, the non-cooperation control unit 17f, the navigation control unit 17d, and the audio control unit 17e. Each will function.

  The instruction receiving unit 17 a receives an instruction signal based on an operation from the driver 2 input via the operation unit 12. The mode switching unit 17b switches the operating mode of the in-vehicle device 10 based on the instruction signal corresponding to the “mode switching” operation received by the instruction receiving unit 17a.

  In the “mode switching” operation, the first switching operation (switching operation of main functions) for switching the mode between “navigation mode” and “audio mode” and the audio mode are executed (audio mode screen) Is displayed), a second switching operation (switching operation of detailed functions) for switching the mode between “cooperative mode” and “non-cooperative mode” is included. The first switching operation corresponds to (first switching processing) shown in FIG. 2, and the second switching operation corresponds to (second switching processing) shown in FIG.

  For example, when switching to the “navigation mode” is instructed, the mode switching unit 17b switches to the navigation function operated by the navigation control unit 17d and displays the navigation screen on the display unit 15 of the in-vehicle device 10. . Similarly, when switching to the “audio mode” is instructed, the mode switching unit 17b switches to the audio function operated by the audio control unit 17e and displays the audio screen on the display unit 15 of the in-vehicle device 10. .

  Various buttons for selecting and executing various functions included in the audio mode are displayed on the audio screen displayed on the display unit 15 of the in-vehicle device 10. And when switching to "cooperation mode" is instruct | indicated by selecting a cooperation button among various buttons, for example, the mode switching part 17b is controlling communication with the portable apparatus 20, The vehicle-mounted device 10 is switched to a cooperation mode in which it operates based on data transmission / reception with the mobile device 20.

  On the other hand, when switching to the “non-cooperation mode” is instructed by selecting an AM button, an FM button, a CD button, a DVD button, etc., among the various buttons, the mode switching unit 17b 10 switches the in-vehicle device 10 to a non-cooperation mode that provides a function of reproducing and outputting a sound source such as a radio or a compact disc and a video source such as a television or a DVD.

  The cooperation control unit 17c performs control related to data transmission / reception with the portable device 20 in the cooperation mode. As illustrated in FIG. 2, the cooperation control unit 17c further includes a communication control unit 17ca, an application determination unit 17cb, and a transmission / reception unit 17cc. Further, the non-cooperation control unit 17f performs control related to the reproduction output of the above-described sound source and video source in the non-cooperation mode.

  When instructed to switch to the cooperation mode from the mode switching unit 17b, the communication control unit 17ca connects the short-range communication unit 11 and the short-range communication unit 21 of the portable device 20 so that they can communicate with each other. In addition, the communication control unit 17ca transfers an input signal from the portable device 20 at the time of connection to the application determination unit 17cb.

  The application determination unit 17cb determines an application being executed on the mobile device 20 side based on the input signal received from the communication control unit 17ca. The application determination unit 17cb instructs the transmission / reception unit 17cc to transmit / receive data to / from the determined application. The transmission / reception unit 17 cc performs data transmission / reception with the application via the short-range communication unit 11.

  Further, when instructed to switch to the non-cooperation mode from the mode switching unit 17b, the communication control unit 17ca and the in-vehicle device 10 based on whether or not the application being executed in the mobile device 20 is in the remote mode. Controls communication with the portable device 20.

  That is, the communication control unit 17ca disconnects communication between the in-vehicle device 10 and the portable device 20 if the application is a remote mode application in such a case. Further, in this case, if the app is a non-remote mode app, the communication control unit 17ca maintains the communication between the in-vehicle device 10 and the portable device 20 without disconnecting.

  Here, in order to make the explanation easy to understand, an example of screen transition in the in-vehicle device 10 when the mode is sequentially switched from the cooperation mode to the non-cooperation mode is shown. FIG. 3 is a diagram illustrating an example of a screen transition of the in-vehicle device 10 according to the first embodiment.

  Note that FIG. 3 is divided into “upper stage”, “middle stage”, and “lower stage” by white arrows. As shown in FIG. 3, the display unit 15 is a liquid crystal touch panel that can be touch-operated, and various buttons corresponding to the operation unit 12 (not shown) are displayed as “AM”, “FM”, and the like. It is assumed that it is arranged on the part 15.

  First, the upper part of FIG. 3 shows an example of a screen for switching to the cooperation mode. Such a screen is displayed, for example, when the driver 2 touches the “cooperation” button displayed on the display unit 15 (see (3-1) in the figure).

  Then, when the driver 2 touches the “connect” button also displayed on the display unit 15 (see (3-2) in the figure), the communication control unit 17ca causes the in-vehicle device 10, the portable device 20, and the like. Connect communication between.

  Here, the communication between the in-vehicle device 10 and the portable device 20 is connected by touching the “connect” button after selecting (touching) the “cooperation” button. As a form, it is good also as a structure which connects the communication between the vehicle-mounted apparatus 10 and the portable apparatus 20 while switching to cooperation mode by selecting (touch) a "cooperation" button. According to such a configuration, it is not necessary to display the “connect” button, and it is not necessary to perform an operation of touching the “connect” button, so that the mode can be switched with a simple operation.

  Then, as shown in the middle part of FIG. 3, a map screen of an app being executed in the mobile device 20, for example, a remote mode app having a navigation function, is displayed on the display unit 15 that is “cooperating” with the mobile device 20. Is done.

  Then, when the driver 2 touches the “AM” button to switch to the AM broadcasting mode which is one of the non-cooperation modes from the “cooperating” state ((3-3) in the lower part of FIG. 3). The communication control unit 17ca disconnects communication between the in-vehicle device 10 and the portable device 20. At this time, as shown in the lower part of FIG. 3, a message indicating that “the mobile device has been disconnected” may be displayed.

  Further, if the application being executed in the mobile device 20 is a non-remote mode app, the communication control unit 17ca keeps communication between the in-vehicle device 10 and the mobile device 20.

  Whether or not the application being executed in the mobile device 20 is a remote mode application can be determined by including the type in the instruction signal from the mobile device 20, for example. An example of data items in such a case will be described with reference to FIGS. 4A and 4B.

  4A and 4B are diagrams illustrating examples of data items included in the instruction signal. In addition, the stored value of the data item shown in the following example does not limit the data format.

  As shown in FIG. 4A, the instruction signal from the mobile device 20 includes, for example, a “mobile device name information” item and an “application name information” item, and whether or not the application on the mobile device 20 side is a remote mode application. The “remote operation enabled / disabled” item shown can be included.

  4A shows that an app “remote navigation” is being executed on the mobile device 20 named “game machine # 1”, and the “remote navigation” is “permitted” for remote operation. An example in the case of a remote mode application is shown.

  In this case, the communication control unit 17ca forcibly disconnects communication between the in-vehicle device 10 and the portable device 20 when switching to the non-cooperation mode.

  FIG. 4B shows that an app “Keitai De Karaoke” is being executed in the portable device 20 similarly named “Game Machine # 1”, and the “Keitai De Karaoke” is “No” for remote operation. That is, an example in the case of a non-remote mode application is shown.

  In such a case, the communication control unit 17ca maintains communication between the in-vehicle device 10 and the portable device 20 when switching to the non-cooperation mode.

  Returning to the description of FIG. 2, the navigation control unit 17d will be described. The navigation control unit 17d is a processing unit that mainly controls the operation of the in-vehicle device 10 in the “navigation mode”. Further, the navigation control unit 17d performs operation control related to the navigation function in response to an instruction request from the portable device 20 when the in-vehicle device 10 is in the “cooperation mode”.

  Here, as shown in FIG. 2, the navigation control unit 17d further includes a destination setting unit 17da, a position information acquisition unit 17db, and a route information generation unit 17dc.

  The destination setting unit 17da sets a “destination” in the navigation function. The destination setting is based on a destination setting request input from the operation unit 12 via the instruction receiving unit 17a by the driver 2 when the in-vehicle device 10 is in the “navigation mode”.

  When the in-vehicle device 10 is in the “cooperation mode”, the destination setting request received from the operation unit 22 of the portable device 20 by the passenger 3 and received via the short-range communication unit 11 and the transmission / reception unit 17cc. based on. Furthermore, the destination may be set based on the destination setting request input from the operation unit 12 by the driver 2 via the instruction receiving unit 17a.

  The position information acquisition unit 17db acquires latitude information and longitude information of the current position of the in-vehicle device 10 based on the GPS information received from the GPS unit 13. Also, the position information acquisition unit 17db acquires vehicle speed information from the vehicle speed acquisition unit 14.

  The route information generation unit 17dc generates route information including a route guidance screen based on the above-described destination setting request, current position information, vehicle speed information, map information 18a stored in the storage unit 18, and the like.

  The route information generation unit 17dc outputs the generated route guidance screen to the display unit 15. In addition, the route information generation unit 17dc instructs the audio control unit 17e to acquire and output acoustic data corresponding to the generated route guidance screen from the acoustic information 18b.

  When the in-vehicle device 10 is in the “cooperation mode”, the route information generation unit 17dc may transfer the generated route information to the mobile device 20 and output it on the mobile device 20 side.

  The audio control unit 17e is a processing unit that mainly controls operations related to the functions of the in-vehicle device 10 in the “audio mode”. Also, the audio control unit 17e performs sound output-related operation control in response to an instruction request from the mobile device 20 when the in-vehicle device 10 is in the “cooperation mode”. Further, when the in-vehicle device 10 is in the “non-cooperation mode”, operation control is performed when the in-vehicle device 10 reproduces and outputs an audio source such as a radio or a compact disc and a video source such as a television or a DVD.

  The storage unit 18 is a storage unit configured by a storage device such as a hard disk drive, a nonvolatile memory, or a register, and stores map information 18a and acoustic information 18b.

  The map information 18a includes data for generating route information, such as road data, facility data, display icon image data, and the like. The acoustic information 18b includes route guidance voice data, application sound effect data, BGM data, and the like.

  Next, the process procedure which the vehicle-mounted apparatus 10 which concerns on 1st Embodiment performs is demonstrated. FIG. 5 is a flowchart illustrating a processing procedure executed by the in-vehicle device 10 according to the first embodiment.

  As shown in FIG. 5, first, the instruction receiving unit 17a receives an instruction signal based on an operation from the operation unit 12 by the driver 2 (step S101). Here, when the received instruction signal is a mode switching instruction (step S102, Yes), the instruction receiving unit 17a shifts the control to the process of step S104.

  When the received instruction signal is not a mode switching instruction (No at Step S102), the instruction receiving unit 17a operates the vehicle-mounted device 10 according to the received instruction signal (Step S103), and then from Step S101. Repeat the process.

  Subsequently, the mode switching unit 17b determines whether or not the accepted mode switching instruction is a switching instruction to the non-cooperative mode (step S104). Here, when it is determined that the instruction is to switch to the non-cooperation mode (step S104, Yes), the mode switching unit 17b determines whether or not the mobile device 20 is in cooperation (step S105).

  And when it determines with cooperating with the portable apparatus 20 (step S105, Yes), the communication control part 17ca determines whether the portable apparatus 20 is performing the remote mode application (step S106). . If the determination condition in step S105 is not satisfied (step S105, No), control is transferred to the process in step S109.

  If it is determined that the mobile device 20 is executing the remote mode application (step S106, Yes), the communication control unit 17ca forcibly disconnects communication between the in-vehicle device 10 and the mobile device 20 (step). S107).

  When it is determined that the mobile device 20 is not executing the remote mode application (No at Step S106), the communication control unit 17ca maintains communication between the in-vehicle device 10 and the mobile device 20 (Step S108).

  Subsequently, the mode switching unit 17b causes the in-vehicle device 10 to operate in the non-cooperation mode (step S109).

  On the other hand, when it is determined in step S104 that it is not a switching instruction to the non-cooperation mode, for example, a switching instruction to the cooperation mode (No in step S104), the mode switching unit 17b is not connected to the portable device 20. Is determined (step S110).

  Here, when it is determined that the mobile device 20 is not connected (step S110, Yes), the communication control unit 17ca connects communication between the in-vehicle device 10 and the mobile device 20 (step S111). When it is determined that the mobile device 20 is connected (No at Step S110), the control is transferred to the process at Step S112.

  Subsequently, the mode switching unit 17b causes the in-vehicle device 10 to operate in the cooperation mode (step S112).

  Then, the in-vehicle device 10 determines whether or not there is a process end event (for example, stop of the ACC power supply) (step S113), and if there is a process end event (step S113, Yes), the process ends. To do. If there is no processing end event (No at step S113), the processing from step S101 is repeated.

  As described above, in the first embodiment, the in-vehicle device is configured to include the communication control unit. When the communication control unit receives an instruction to switch to the non-cooperation mode, which is a mode other than the cooperation mode during operation in the cooperation mode, and the application including the remote operation for the in-vehicle device is being executed in the mobile device Disconnects communication between the in-vehicle device and the portable device. Therefore, according to the vehicle-mounted apparatus which concerns on 1st Embodiment, it can cooperate with a portable apparatus appropriately, without impairing the convenience which a driver | operator enjoys.

  In the first embodiment, if the communication control unit receives an instruction to switch to the non-cooperation mode and the application that allows remote operation of the in-vehicle device is being executed in the mobile device, the in-vehicle device The case where the communication with the mobile device is forcibly disconnected has been described.

  However, if a destination setting request from a mobile device is notified, a confirmation screen that confirms whether or not to accept the destination setting request is generated and the driver is asked whether it is acceptable. It is not necessary to disconnect the communication. This point will be mentioned in a fourth embodiment described later.

  By the way, in the above-described first embodiment, the configuration example of the in-vehicle device that emphasizes the point of being able to cooperate with the portable device without impairing convenience has been described. From the viewpoint of maintaining safety, for example, the cooperation mode The driver may be automatically urged to call attention inside. Hereinafter, such an embodiment will be described in detail as a “second embodiment” with reference to FIGS. 6A to 7.

  Although not shown, the in-vehicle device according to the second embodiment will be described with reference numeral “10A”. The block configuration of the in-vehicle device 10A according to the second embodiment is the same as that of the in-vehicle device 10 according to the first embodiment described above (see FIG. 2). Therefore, hereinafter, each processing unit may be described using the same reference numerals as those shown in FIG.

(Second Embodiment)
6A to 6C are diagrams illustrating an overview of the in-vehicle device 10A according to the second embodiment. As shown in the upper part of FIG. 6A, the in-vehicle device 10A displays a warning message in the cooperation mode on the switching screen to the cooperation mode displayed on the display unit 15 (see the upper part of FIG. 3).

  For example, an upper part of FIG. 6A shows an example in which a warning message “Please do not operate this unit or portable device while driving” for safety is displayed. Moreover, as shown in the lower part of FIG. 6A, the in-vehicle device 10A can display such a warning message throughout the cooperation mode.

  As a result, the driver 2 is urged to alert the driver 2 to operate various devices while the vehicle is running, which is originally forbidden, but is often neglected only by being described in a manual or the like. be able to. That is, it is possible to allow the driver 2 to enjoy the convenience of the linkage function while maintaining safety by prompting attention.

  In addition, it is good also as a thing according to the application currently running in the portable apparatus 20 here.

  In such a case, for example, the application being executed in the mobile device 20 is, for example, (1) one that involves the operation of both the in-vehicle device 10A and the mobile device 20, (2) the one that involves the operation of only the in-vehicle device 10A, It can be classified into three types with only 20 operations.

  And when the application actually run in the portable apparatus 20 is an application equivalent to said (1), what is necessary is just to display the alerting message shown to FIG. 6A.

  In addition, in the case of the app corresponding to the above (2), as shown in FIG. 6B, only the in-vehicle device 10A such as “Please do not operate this unit while driving” An alert message may be displayed.

  Similarly, in the case of the app corresponding to the above (3), as shown in FIG. 6C, only the mobile device 20 such as “For safety, the driver should not operate the mobile device while traveling” is targeted. The warning message may be displayed.

  It should be noted that it is possible to discriminate the apps divided in this way by using the app judging unit 17cb (see FIG. 2) shown in the first embodiment.

  Next, a processing procedure executed by the in-vehicle device 10A according to the second embodiment will be described. FIG. 7 is a flowchart showing a processing procedure executed by the in-vehicle device 10A according to the second embodiment.

  As shown in FIG. 7, first, the instruction receiving unit 17a receives an instruction to switch to the cooperation mode (step S201).

  And the mode switching part 17b displays the switching screen to the cooperation mode containing the alert message (step S202). If the connection operation with the mobile device 20 is performed from the screen, the communication control unit 17ca starts communication with the mobile device 20 (step S203).

  And the application determination part 17cb discriminate | determines the application in execution in the portable apparatus 20, produces | generates the alert message according to this application (step S204), and displays it on the display part 15 (step S205). Such a warning message is displayed throughout the cooperation mode.

  Then, an end event of the cooperation mode such as the instruction reception unit 17a receiving an instruction to switch to the non-cooperation mode is received (step S206). Here, after ending the cooperation mode (step S207), the mode switching unit 17b deletes the currently displayed alert message (step S208) and ends the process.

  Moreover, as another embodiment, the configuration may be such that the alert message being displayed is deleted when a predetermined time has elapsed.

  As described above, in the second embodiment, when the mode switching unit receives an instruction to switch to the cooperation mode, the application determination unit determines an application to be executed in the mobile device, and responds to the application. The in-vehicle device was configured to display a warning message to the driver. Therefore, according to the vehicle-mounted device according to the second embodiment, it is possible to prompt the driver to call attention directly according to the application. That is, it is possible to allow the driver to enjoy the convenience of the linkage function while maintaining safety.

  By the way, in 1st Embodiment mentioned above, operation of the portable apparatus which a driver | operator does not intend by the passenger may be performed, and in order to prevent an incorrect destination setting etc. based on such operation, it is necessary. Accordingly, the case where communication between the in-vehicle device and the portable device is disconnected has been described.

  In this regard, for example, when a destination setting request that may be inappropriate is received from the portable device, the driver may be able to cancel the destination set in response to the destination setting request. Note that the canceling operation at this time is preferably a simple operation so as not to hinder the driving operation of the driver.

  Hereinafter, an embodiment in such a case will be described as a “third embodiment” with reference to FIGS. 8 to 11.

(Third embodiment)
FIG. 8 is a diagram showing an outline of the in-vehicle device 10B according to the third embodiment. As shown in FIG. 8, it is assumed that the passenger 3 performs a destination setting operation from the portable device 20 (see (8-1) in the figure), and a destination setting request is transmitted to the in-vehicle device 10B ( (See (8-2) in the figure).

  Here, when the passenger 3 is a child, the destination setting request may be inappropriate.

  Therefore, in the in-vehicle device 10B according to the third embodiment, when a destination setting request is received from the mobile device 20, a cancel button is displayed so that the destination set in response to the instruction request can be canceled. (See (8-3) in the figure). Such a cancel button is configured as an operation component capable of a simple one-touch operation.

  When the driver 2 touches the cancel button, the in-vehicle device 10B deletes the nearest destination set based on the setting request from the portable device 20. That is, the newest destination is deleted from the destinations set from the mobile device 20.

  Thereby, the driver 2 can delete the destination set by the portable device 20 by a simple operation on the in-vehicle device 10B side close to his / her hand, so that the driving operation is not hindered. That is, it is possible to maintain convenience in the cooperation function while maintaining safety.

  The cancel button is preferably displayed when two or more destinations are set in the in-vehicle device 10B. This is because it is possible to reduce the number of operations of the driver 2 by setting a new destination by overwriting, rather than canceling and setting a new destination when there is only one destination. Note that this point does not prevent the cancel button from being displayed when there is only one destination.

  Alternatively, all the destinations set based on the setting request from the mobile device 20 may be displayed in a list and may be deleted collectively by pressing a cancel button. Further, it may be selected from the list and deleted. This point will be described later with reference to FIGS. 10B and 10C.

  Next, the structure of the vehicle-mounted apparatus 10B which concerns on 3rd Embodiment is demonstrated using FIG. FIG. 9 is a block diagram illustrating a configuration of an in-vehicle device 10B according to the third embodiment.

  9 corresponds to the block diagram showing the configuration of the in-vehicle device 10 according to the first embodiment shown in FIG. 2, but overlaps with the first embodiment for the sake of simplicity of explanation. Some of the components are not shown. In FIG. 9, the description will be focused on the navigation control unit 17d shown in the first embodiment.

  In FIG. 9, the same components as those of the first embodiment are denoted by the same reference numerals, and description of the same components as those of the first embodiment is omitted or only a brief description. And

  As shown in FIG. 9, the in-vehicle device 10B is different from the in-vehicle device 10 according to the first embodiment described above in that the navigation control unit 17d further includes a cancel processing unit 17dd. The storage unit 18 is further different from the in-vehicle device 10 in that the destination information 18c is stored.

  The destination information 18c is sequentially added and set by the destination setting unit 17da that receives the destination setting request from the mobile device 20. The cancel processing unit 17dd displays a cancel button on the display unit 15 when the destination setting unit 17da performs destination setting based on the destination setting request from the portable device 20.

  Here, the screen display of the in-vehicle device 10B will be specifically described with reference to FIGS. 10A to 10C. 10A to 10C are diagrams illustrating an example of a screen display of the in-vehicle device 10B according to the third embodiment.

  As illustrated in FIG. 10A, the in-vehicle device 10B displays a cancel button on the display unit 15 on the in-vehicle device 10B side. FIG. 10A shows an example in which only the cancel button is displayed. In such a case, when the driver 2 presses the cancel button, the in-vehicle device 10B deletes only the nearest destination set from the mobile device 20. That is, by pressing the cancel button, only the newest destination set from the mobile device 20 is deleted.

  10B, a cancel button may be displayed on the display unit 15 and all destinations set from the mobile device 20 may be displayed in a list. In such a case, when the driver 2 presses the cancel button, the in-vehicle device 10B can collectively delete all the destinations displayed in the list. Further, the in-vehicle device 10B displays a list of all destinations by pressing the cancel button displayed on the display unit 15, and collectively deletes all the destinations displayed in the list by pressing the cancel button again. It may be a configuration. Note that the destination may be selected by touching the list, and only the selected destination may be deleted.

  FIG. 10C shows a modification of the list display. As shown in FIG. 10C, character information or an icon indicates whether the destination is set from the in-vehicle device 10B (see “this machine” in the figure) or the mobile device 20 (see “mobile” in the figure). Display identifiable. And it is good also as displaying all the destinations of the destination information 18c as a list irrespective of whether it is the destination set from either the vehicle-mounted apparatus 10B or the portable device 20.

  In such a case, the in-vehicle device 10B can collectively delete all the “mobile” destinations displayed in the list. For example, by pressing a display portion (character information, an icon, etc.) indicating “mobile” displayed in the list, and then pressing a cancel button, all the destinations of “mobile” displayed in the list are deleted at once. Further, from this list, the driver 2 may be arbitrarily selected and deleted including the destination of “this machine” (for example, “W point” in the figure). For example, after pressing an arbitrary destination displayed in the list, pressing a cancel button deletes all the selected destinations at once.

  Although not shown in FIGS. 10A to 10C, for the destination setting operation from the portable device 20, the “normal type” one that the passenger 3 performs in accordance with a predetermined procedure and the passenger 3 perform the destination setting operation. There is a “guide type” that is guided by an application of the mobile device 20.

  “Guidance type” destination setting operation is guided to, for example, recommendation (recommend) by an application in accordance with tourist spot information or spot information registered in advance as landmarks, that is, attributes of points that can be set as destinations. Done. Although this “guide type” is easy to operate, it can be said that the passenger 3 can easily set without careful consideration, so that the destination setting request may be inappropriate compared to the “normal type”. High nature.

  Therefore, the in-vehicle device 10B may treat only the destination set by the “guidance type” as a cancel target.

  Returning to the description of FIG. If the cancel processing unit 17dd receives a “cancel operation” from the cancel button, the cancel processing unit 17dd deletes the corresponding destination from the destination information 18c.

  Next, a processing procedure executed by the in-vehicle device 10B according to the third embodiment will be described. FIG. 11 is a flowchart illustrating a processing procedure executed by the in-vehicle device 10B according to the third embodiment.

  FIG. 11 shows a processing procedure centering on “one-touch cancellation processing” by the cancellation processing unit 17dd. In addition, here, a case where only the nearest destination among the destinations set from the mobile device 20 is deleted when two or more destinations are set is shown.

  As shown in FIG. 11, first, the destination setting unit 17da receives the destination setting request (step S301) and sets the destination (step S302).

  Then, the cancel processing unit 17dd determines whether there are two or more destinations set in the destination information 18c (step S303). Here, when the determination condition of step S303 is satisfied (step S303, Yes), the cancel processing unit 17dd determines whether the destination is set based on a request from the portable device 20 (step S304).

  If the determination condition in step S303 is not satisfied (step S303, No), the processing from step S301 is repeated.

  If the determination condition in step S304 is satisfied (step S304, Yes), the cancel processing unit 17dd displays a cancel button on the display unit 15 (step S305). If the determination condition in step S304 is not satisfied (No in step S304), the cancel button is hidden (step S306), and the processing from step S301 is repeated.

  Subsequently, when the cancel button is pressed (step S307, Yes), the cancel processing unit 17dd deletes the nearest destination set from the mobile device 20. That is, the newest destination set from the mobile device 20 is deleted. (Step S308). If the cancel button is not pressed (No at Step S307), the processing from Step S301 is repeated.

  Then, it is determined whether or not there is a process end event (step S309). If there is a process end event (step S309, Yes), the process ends. If there is no processing end event (No at Step S309), the processing from Step S301 is repeated.

  As described above, in the third embodiment, when there is a destination set from the mobile device, the cancel processing unit displays a cancel button on the display unit on the in-vehicle device side, and the display button is pressed. In some cases, the in-vehicle device was configured to delete the most recent destination set from the mobile device. Therefore, according to the in-vehicle device according to the third embodiment, even if inappropriate destination setting is performed from the mobile device, the driver can cancel this by a simple operation. While maintaining safety, it is possible to provide the driver with convenience in the cooperation function.

  By the way, in 3rd Embodiment mentioned above, when the destination setting request | requirement which may be unsuitable from a portable apparatus is received, a driver | operator can cancel the destination set according to this destination setting request | requirement. Explained the case.

  In this regard, similarly, when a destination setting request that may be inappropriate is received from the portable device, a confirmation screen may be displayed to allow the driver to confirm. The destination setting from the portable device is effective for the driver to enjoy high convenience in the cooperation function if the procedure is appropriate.

  Therefore, it is preferable that the confirmation screen is displayed when the above-described “guidance type” destination setting operation is performed. Hereinafter, an embodiment in such a case will be described as a “fourth embodiment” with reference to FIGS. 12A to 15.

(Fourth embodiment)
12A to 12C are diagrams illustrating an overview of the in-vehicle device 10C according to the fourth embodiment. As shown in FIG. 12A, the passenger 3 performs a “normal type” destination setting operation from the portable device 20 (see (12A-1) in the figure), and the “normal type” destination setting request is made in-vehicle. It is assumed that it has been transmitted to the device 10C (see (12A-2) in the figure).

  Here, when receiving the “normal type” destination setting request, the in-vehicle device 10C always permits the destination setting according to the request (see (12A-3) in the figure). That is, priority is given to the convenience in the linkage function for the “normal type” having a high degree of validity following a predetermined procedure.

  Also, as shown in FIG. 12B, the passenger 3 performs a “guide type” destination setting operation from the portable device 20 (see (12B-1) in the figure), and the “guide type” destination setting request. Is transmitted to the in-vehicle device 10C (see (12B-2) in the figure).

  In such a case, the in-vehicle device 10C displays a confirmation screen asking whether the setting according to the destination setting request is possible (see (12B-3) in the figure). In other words, the in-vehicle device 10C handles the “guide type” that is likely to be an inappropriate destination setting request more carefully than the “normal type”.

  Here, an example of a confirmation screen is shown. As shown in FIG. 12C, for example, a simple operation button for selecting “Yes” or “No” together with an easy-to-understand message such as “Can I set the destination transmitted from the mobile device?” Etc. are preferably shown to the driver 2.

  Next, the configuration of the in-vehicle device 10C according to the fourth embodiment will be described with reference to FIG. FIG. 13 is a block diagram illustrating a configuration of an in-vehicle device 10C according to the fourth embodiment.

  FIG. 13 corresponds to a block diagram showing the configuration of the in-vehicle device 10B according to the third embodiment shown in FIG. Therefore, in FIG. 13, as in the case of the third embodiment of FIG. 9, the description centering on the navigation control unit 17 d shown in the first embodiment will be given.

  In FIG. 13, the same components as those in the above-described embodiments are denoted by the same reference numerals, and the description of the overlapping components is omitted or only a brief description.

  As shown in FIG. 13, the in-vehicle device 10C further includes a permission level determination unit 17de and a confirmation screen generation unit 17df in the navigation control unit 17d, and the in-vehicle device 10 according to the first embodiment described above. Is different. Moreover, although the memory | storage part 18 memorize | stores the destination information 18c further differs from the vehicle-mounted apparatus 10, this point is the same as that of the vehicle-mounted apparatus 10B which concerns on 3rd Embodiment.

  The permission level determination unit 17de receives a destination setting request from the mobile device 20, and determines the permission level. Here, a specific operation of the permission level determination unit 17de will be described with reference to FIGS. 14A and 14B.

  14A and 14B are diagrams illustrating examples of data items included in the instruction signal of the in-vehicle device 10C according to the fourth embodiment. 14A and 14B already correspond to the example of the instruction signal shown in FIGS. 4A and 4B, and therefore the description of the overlapping data items is omitted.

  As shown in FIG. 14A, the instruction signal from the mobile device 20 can include, for example, an “permission level” item. The “permission level” item is an item in which different values are stored when there is a difference such as “normal type” or “guide type” in the destination setting operation.

  A specific example of the stored value is shown in FIG. 14B. As shown in FIG. 14B, the “permission level” item can be divided into “always permitted”, “required every time”, and “always denied”. For example, “0x00”, “0x01”, “ Different values such as “0xFF” can be assigned. In the fourth embodiment, the “normal type” destination setting operation corresponds to “always permitted”, and the “guide type” destination setting operation corresponds to “confirm every time”.

  As another embodiment, the association between the “permission level” item and the destination setting operation may be arbitrarily set by the user. For example, if you set the “Normal type” destination setting operation to “Confirm every time” and the “Guided type” destination setting operation to “Always reject”, you can set or change the destination. It cannot be easily performed, and inappropriate destination setting can be prevented.

  And the permission level determination part 17de mentioned above will determine whether a confirmation screen (refer FIG. 12C) is displayed based on the stored value of this "permission level" item.

  Returning to the description of FIG. The confirmation screen generation unit 17df generates a confirmation screen according to the determination result of the permission level determination unit 17de and displays it on the display unit 15. If the “confirmation operation” by the driver 2 is received from the confirmation screen displayed on the display unit 15, the destination setting unit 17da sets the destination.

  In this way, if the driver 2 confirms whether or not the driver 2 is allowed, that is, if the confirmation screen generation unit 17df operates, the communication control unit 17ca (see FIG. 2) The communication between the mobile device 20 and the portable device 20 may not be cut off exceptionally.

  Next, a processing procedure executed by the in-vehicle device 10C according to the fourth embodiment will be described. FIG. 15 is a flowchart illustrating a processing procedure executed by the in-vehicle device 10C according to the fourth embodiment.

  FIG. 15 shows a processing procedure centering on “availability confirmation processing” by the permission level determination unit 17de and the confirmation screen generation unit 17df.

  As shown in FIG. 15, first, the permission level determination unit 17de receives the destination setting request (step S401), and determines whether or not the permission level is “always permitted” (step S402).

  Here, when the determination condition of step S402 is satisfied (step S402, Yes), the destination setting unit 17da sets the destination (step S406). If the determination condition in step S402 is not satisfied (No in step S402), the permission level determination unit 17de determines whether the permission level is “always deny” (step S403).

  If the determination condition of step S403 is satisfied (step S403, Yes), the processing from step S401 is repeated without setting the destination according to the destination setting request. If the determination condition in step S403 is not satisfied (No in step S403), the confirmation screen generation unit 17df generates a confirmation screen corresponding to the permission level and displays it on the display unit 15 (step S404).

  If the setting is permitted through the displayed confirmation screen (step S405, Yes), the destination setting unit 17da sets the destination (step S406). If the setting is not permitted (No at step S405), the process from step S401 is repeated.

  Then, it is determined whether or not there is a process end event (step S407). If there is a process end event (step S407, Yes), the process ends. If there is no processing end event (No at step S407), the processing from step S401 is repeated.

  As described above, in the fourth embodiment, the permission level determination unit determines the permission level for the destination setting request from the portable device, and the confirmation screen generation unit checks the confirmation screen according to the determined permission level. Is generated so that the driver can confirm whether the destination is set or not.

  Therefore, according to the in-vehicle device according to the fourth embodiment, it is possible to allow the driver to confirm whether or not the destination setting request from the portable device is possible by a simple operation. Can be prevented. That is, it is possible to allow the driver to fully enjoy the convenience of the linkage function while maintaining the driver's safety.

  By the way, when the passenger is in the process of setting the destination from the portable device, if the driver is informed of this, the driver must know that there is a possibility that an inappropriate destination is set. Can do.

  In this regard, for example, a message such as “setting” may be displayed on the display unit of the in-vehicle device, but the driver may be overlooked due to the driver's attention. Therefore, it is effective to use sound in order to make the driver surely know.

  For example, BGM that informs that the destination setting operation is being performed from the portable device may be output from the in-vehicle speaker. Hereinafter, an embodiment in such a case will be described as a “fifth embodiment” and will be described in detail with reference to FIGS. 16 to 18.

(Fifth embodiment)
FIG. 16 is a diagram illustrating an overview of an in-vehicle device 10D according to the fifth embodiment. As shown in FIG. 16, it is assumed that a destination search operation is performed from the portable device 20 by the passenger 3 to set the destination, and the destination search is being performed in the portable device 20 ((16- in the figure)). 1)).

  In such a case, the portable device 20 transmits a destination search notification to the in-vehicle device 10D (see (16-2) in the figure).

  When the in-vehicle device 10D receives the destination search in-progress notification, the in-vehicle device 10D outputs BGM indicating that the destination setting operation is being performed in the portable device 20 from the speaker 16 ((16-3) in the figure). reference).

  As a result, passengers other than the driver 2 and the passenger 3 can know that the destination setting operation is being performed on the mobile device 20, so that an inappropriate destination setting without the consent of all the passengers is performed. Can be prevented.

  Next, the configuration of the in-vehicle device 10D according to the fifth embodiment will be described with reference to FIG. FIG. 17 is a block diagram illustrating a configuration of an in-vehicle device 10D according to the fifth embodiment.

  Note that FIG. 17 will be described with a focus on the navigation control unit 17d shown in the first embodiment, as in the third and fourth embodiments.

  In addition, the same components as those in the above-described embodiments are denoted by the same reference numerals, and the description of the overlapping components is omitted or simply described.

  As illustrated in FIG. 15, the in-vehicle device 10D further includes a setting processing unit 17dg in the navigation control unit 17d. The setting processing unit 17dg receives a destination search notification from the mobile device 20, and acquires BGM data indicating that the destination setting operation is being performed in the mobile device 20 from the acoustic information 18b.

  Further, the setting processing unit 17dg outputs BGM based on the acquired BGM data from the speaker 16.

  When the destination setting unit 17da receives the destination setting request from the portable device 20 and performs destination setting, the setting processing unit 17dg stops the BGM being output.

  Next, a processing procedure executed by the in-vehicle device 10D according to the fifth embodiment will be described. FIG. 18 is a flowchart illustrating a processing procedure executed by the in-vehicle device 10D according to the fifth embodiment.

  FIG. 18 shows a processing procedure centered on “setting process” by the setting process unit 17dg.

  As illustrated in FIG. 18, first, the setting processing unit 17dg determines whether or not the mobile device 20 is searching for a destination based on the destination searching notification (step S501).

  If the determination condition of step S501 is satisfied (step S501, Yes), the setting processing unit 17dg causes the speaker 16 to output BGM indicating that the destination setting operation is being performed (step S502).

  If the determination condition in step S501 is not satisfied (step S501, No), the processing from step S501 is repeated.

  Then, the destination setting unit 17da determines whether or not a destination setting request has been received (step S503). Here, when the determination condition of step S503 is satisfied (step S503, Yes), the destination setting unit 17da sets the destination (step S504). If the determination condition in step S503 is not satisfied (step S503, No), the processing from step S503 is repeated.

  Then, the setting processing unit 17dg stops the BGM being output (step S505).

  Then, it is determined whether or not there is a process end event (step S506). If there is a process end event (step S506, Yes), the process ends. If there is no processing end event (step S506, No), the processing from step S501 is repeated.

  As described above, in the fifth embodiment, when the in-setting processing unit (notification unit) receives a destination search notification from the mobile device, it indicates that the destination setting operation is being performed in the mobile device. The in-vehicle device was configured to output BGM from the speaker.

  Therefore, according to the vehicle-mounted device according to the fifth embodiment, it can be ascertained that all the passengers are performing the destination setting operation in the portable device, so that inappropriate destination setting can be prevented. . In other words, the convenience of the linkage function can be sufficiently enjoyed by the passenger.

  By the way, when the destination setting operation is repeatedly performed by the passenger from the portable device, it is conceivable that an unnecessary load is applied to the in-vehicle device. In such a case, for example, an event such as a slow response of the in-vehicle device may occur, which may impair convenience in the cooperation function.

  Therefore, in order to avoid such a situation, the in-vehicle device may reject an unnecessary destination setting request. Moreover, it is good also as notifying the reason for refusal to the portable apparatus side in that case. Hereinafter, such an embodiment will be described in detail as a “sixth embodiment” with reference to FIGS. 19 to 22.

(Sixth embodiment)
FIG. 19 is a diagram illustrating an overview of an in-vehicle device 10E according to the sixth embodiment. As shown in FIG. 19, it is assumed that the passenger 3 performs a destination setting operation from the portable device 20 (see (19-1) in the figure), and a destination setting request is transmitted to the in-vehicle device 10E (see FIG. 19). (See (19-2) in the figure).

  Here, the in-vehicle device 10E performs an acceptability determination process for determining whether or not the destination setting request can be accepted (see (19-3) in the figure). If it is determined that the request cannot be accepted, the in-vehicle device 10E discards the request and notifies the portable device 20 of the reason for refusal (see (19-4) in the figure).

  The rejection reason notification can include, for example, display information such as a screen or a message displayed on the display unit 23 on the mobile device 20 side. An example of such display will be described later with reference to FIGS. 21A to 21C.

  Thereby, it can prevent applying unnecessary load with respect to the vehicle-mounted apparatus 10E. In addition, by notifying the mobile device 20 of the reason for refusal, it is possible to suppress unnecessary repeated operations or the like of the passenger 3 who operates the mobile device 20.

  Next, the structure of the vehicle-mounted apparatus 10E which concerns on 6th Embodiment is demonstrated using FIG. FIG. 20 is a block diagram illustrating a configuration of an in-vehicle device 10E according to the sixth embodiment.

  In FIG. 20 as well, in the same way as in the third to fifth embodiments, the description will be made centering on the navigation control unit 17d shown in the first embodiment.

  In addition, the same components as those in the above-described embodiments are denoted by the same reference numerals, and the description of the overlapping components is omitted or simply described.

  As illustrated in FIG. 20, the in-vehicle device 10E further includes an acceptance determination unit 17dh in the navigation control unit 17d. When receiving a destination setting request from the mobile device 20, the acceptability determination unit 17 dh determines whether or not the request can be accepted.

  If the acceptability determining unit 17dh determines that the destination setting request cannot be accepted, the acceptability determining unit 17dh discards the destination setting request and transmits a rejection reason notification to the mobile device 20.

  As specific examples of reasons for refusal, when the point information included in the destination setting request has an illegal value, or when the number of registered destination information 18c has reached the upper limit, the in-vehicle device 10E For example, when busy.

  Here, an example of the reason for refusal to be displayed on the mobile device 20 side according to the specific example will be shown. FIG. 21A to FIG. 21C are diagrams illustrating an example of the rejection reason notified by the in-vehicle device 10E according to the sixth embodiment.

  FIG. 21A is an example when the point information included in the destination setting request has an incorrect value. In such a case, as shown in FIG. 21A, the in-vehicle device 10E displays a reason for refusal such as “the transmitted information cannot be used” on the display unit 23 of the mobile device 20.

  FIG. 21B is an example when the number of registered destination information 18c has reached the upper limit. In such a case, as shown in FIG. 21B, the in-vehicle device 10E displays a reason for refusal such as “cannot be set any more” and “please delete and use” on the mobile device 20 side.

  FIG. 21C is an example when the in-vehicle device 10E is busy. In such a case, as shown in FIG. 21C, the in-vehicle device 10E displays on the portable device 20 side the reason for refusal such as “System is busy” and “Please reset after a while”.

  In addition, what was shown in FIG. 21A-FIG. 21C is an example to the last. Therefore, if it is assumed that the passenger 3 is a child, a simpler message with hiragana notation may be displayed.

  Returning to the description of FIG. When the acceptability determination unit 17dh determines that the destination setting request can be accepted, the destination setting unit 17da performs destination setting according to the destination setting request.

  Next, a processing procedure executed by the in-vehicle device 10E according to the sixth embodiment will be described. FIG. 22 is a flowchart illustrating a processing procedure executed by the in-vehicle device 10E according to the sixth embodiment.

  Note that FIG. 22 shows a processing procedure of “acceptability determination processing” centered on the acceptability determination unit 17dh.

  As shown in FIG. 22, first, the acceptance / rejection determination unit 17dh determines whether or not a destination setting request has been received (step S601).

  Here, when the determination condition of step S601 is satisfied (step S601, Yes), the acceptance determination unit 17dh determines whether or not the received destination setting request can be received (step S602). If the determination condition in step S601 is not satisfied (No in step S601), the process from step S601 is repeated.

  If the determination condition in step S602 is satisfied (step S602, Yes), the destination setting unit 17da sets the destination (step S603). If the determination condition in step S602 is not satisfied (step S602, No), the destination setting unit 17da discards the destination setting request and notifies the portable device 20 of the reason for refusal (step S604), and from step S601. Repeat the process.

  Then, it is determined whether or not there is a process end event (step S605). If there is a process end event (step S605, Yes), the process ends. If there is no process end event (step S605, No), the process from step S601 is repeated.

  Although not shown, when the in-vehicle device 10E repeatedly receives a destination setting request while busy, the destination setting request is buffered and finally buffered after a predetermined time has elapsed. Setting may be performed using only the latest destination setting request.

  As described above, in the sixth embodiment, the acceptability determination unit determines whether or not the received destination setting request can be accepted, and if not, notifies the reason for refusal to the mobile device side. The in-vehicle device was configured as follows.

  Therefore, according to the vehicle-mounted device according to the sixth embodiment, it is possible to prevent an unnecessary load from being applied to the vehicle-mounted device. In addition, by notifying the mobile device of the reason for refusal, it is possible to suppress unnecessary operations of a passenger who operates the mobile device. In other words, the driver can enjoy the convenience of the linkage function without deteriorating.

  In addition, it cannot be overemphasized that each embodiment mentioned above can be suitably combined and comprised in one vehicle-mounted apparatus.

  Further effects and modifications can be easily derived by those skilled in the art. Thus, the broader aspects of the present invention are not limited to the specific details and representative embodiments shown and described above. Accordingly, various modifications can be made without departing from the spirit or scope of the general inventive concept as defined by the appended claims and their equivalents.

DESCRIPTION OF SYMBOLS 1 Vehicle 2 Driver 3 Passenger 10 In-vehicle device 10A In-vehicle device 10B In-vehicle device 10C In-vehicle device 10D In-vehicle device 10E In-vehicle device 11 Near field communication unit 12 Operation unit 13 GPS unit 14 Vehicle speed acquisition unit 15 Display unit 16 Speaker 17 Control unit 17a Instruction receiving unit 17b Mode switching unit 17c Cooperation control unit 17ca Communication control unit 17cb Application determination unit 17cc Transmission / reception unit 17d Navigation control unit 17da Destination setting unit 17db Location information acquisition unit 17dc Route information generation unit 17dd Cancel processing unit 17de Permission level determination unit 17df Confirmation screen generation unit 17dg Setting processing unit 17dh Acceptability determination unit 17e Audio control unit 17f Non-link control unit 18 Storage unit 18a Map information 18b Acoustic information 18c Destination information 20 Portable device 21 Short range communication unit 22 Operation Production unit 23 Display unit 24 Control unit 25 Storage unit 25a Application

Claims (5)

An in-vehicle device having a cooperation mode that is a mode that operates in cooperation with the portable device while communicating with the portable device,
When receiving an instruction to switch to a non-cooperation mode that is a mode other than the cooperation mode during operation in the cooperation mode, when an application including a remote operation for the in-vehicle device is being executed in the portable device, An in-vehicle device, comprising: a communication control unit that disconnects communication between the in-vehicle device and the portable device.   The linkage mode is
  In this mode, the portable device and the in-vehicle device cooperate with each other and the output sound from the portable device can be output from the speaker of the in-vehicle device.
  The non-cooperation mode is
  In this mode, the in-vehicle device operates as a single unit and outputs sound output from the speaker.
  The in-vehicle device according to claim 1. The communication control unit
The in-vehicle device according to claim 1 or 2 , wherein when the application that does not include a remote operation for the in-vehicle device is being executed in the portable device, communication between the in-vehicle device and the portable device is maintained. . The application including the remote operation is
Notifies the setting request of the destination in the car navigation function from the portable device to the vehicle device, in claim 1, 2 or 3, characterized in that performing a remote operation to set the destination with respect to said vehicle unit The in-vehicle device described. A confirmation processing unit for displaying on the display unit of the in-vehicle device a confirmation screen for confirming whether or not to accept the setting request when the destination setting request is notified from the portable device;
The communication control unit
The in-vehicle device according to claim 4 , wherein when the confirmation processing unit operates, communication between the in-vehicle device and the portable device is not disconnected.

Images