JP2011101198A - Telephone call confirming method of hands-free system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To construct a hands-free system having higher versatility, after also assuming the possibility that a device which does not satisfy the specification of a communication standard in part is used. <P>SOLUTION: An in-vehicle electrical unit 12 with a BT module 30 mounted can construct the hands-free system with a cellular phone 18 as an audio gateway (BTAG). In this case, although a hands-free telephone call can be obtained by RFCOMM connection completion (ST1), a host CPU 28a is not able to confirm the end of the telephone call, when the notification of "+CIEV(Call=0)" is not performed, even if BTAG 18 ends the telephone call. Hence, the BT module 30 issues an inquiry event for "AT+CIND?" (ST12), after the disconnection of an SCO link (ST10). When there is a response event of the "+CIEV(Call=0)" from the BTAG 18, the host CPU 28a can confirm the end of the telephone call. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a call confirmation method for a hands-free system that enables a hands-free call through a call device separately prepared without the user actually holding a portable device such as a mobile phone.

  Conventionally, as a hands-free system of a type mounted on a vehicle, for example, a prior art of a type in which a mobile phone and an in-vehicle unit are connected by wire is known (for example, see Patent Document 1). This prior art uses a vehicle-mounted unit (system main unit) in a wired connection with a mobile phone, thereby realizing a hands-free call with the other party (far end) through a speaker or microphone built into the main unit. . In addition, in this prior art, a “call start” key and a “call end” key are separately provided in the main body of the system, so that when a user operates the “call start” key at the time of an incoming call, a call on a mobile phone can be started. If the user operates the “call end” key during a call, the call on the mobile phone can be ended.

  Apart from the above, a prior art relating to a hands-free system of a type in which a mobile phone and an in-vehicle unit are wirelessly connected is also known (see, for example, Patent Document 2). In this prior art, a mobile phone and an in-vehicle unit are connected using short-range wireless communication of Bluetooth (registered trademark) standard. For this reason, the user can realize a hands-free call simply by bringing the mobile phone into the vehicle, and the user-friendliness is improved accordingly.

  Since the prior art (Patent Document 1) mentioned above uses wired for connection between the system main body and the mobile phone, there is little influence of noise and mutual communication is stable. However, since a hands-free system can be constructed only with devices that have compatible connection interfaces such as cables and connectors, there is a difficulty in receiving hardware restrictions. In this regard, when the connection is made using general-purpose short-range wireless communication as in the latter prior art (Patent Document 2), both the in-vehicle unit and the mobile phone are equipped with a communication module compliant with the communication standard. If so, a hands-free system can be constructed relatively easily. For this reason, it is considered that wireless connection using short-range wireless communication will become the mainstream of hands-free systems in the future.

JP 2001-309008 A (page 4-5, FIGS. 1 and 2) Japanese Patent No. 395948

  However, when general-purpose short-distance wireless communication (for example, Bluetooth: registered trademark) is used for a hands-free system, if each device does not faithfully execute an operation conforming to the communication standard, the operation of the entire system can be performed by itself. It should also be noted that defects will occur.

  For example, if a mobile phone ends a call with the other party (far end) during a hands-free call, the "call end (end call)" is reliably notified to the in-vehicle unit (eg car audio device) It is required in the specifications of communication standards. This is because the in-vehicle unit that is not directly connected to the telephone line is once released from the “calling” state, and the subsequent operation is enabled. Assuming this, if the call is not notified to the in-vehicle unit even after the call has actually ended on the mobile phone, the in-vehicle unit will continue to recognize that the call is in progress and will Even if there is an incoming call from the (far end), the incoming call itself is not accepted, or other operations (for example, music playback, radio broadcast output, etc.) are restricted.

  Of course, many devices (communication modules) that support general-purpose short-range wireless communication are usually designed with the expectation that they will operate normally in accordance with the communication standard. However, when there are a wide variety of specifications in communication standards, there are actually some devices that do not meet some requirements (for example, mobile phones of specific models or model numbers), and many of them are in the global market. The fact that it is in circulation is not to be missed. For this reason, if it is overconfident that all devices always meet the specifications of the communication standard and an easy hands-free system is constructed, the operation of the system may become unstable in some cases, resulting in a loss of user convenience. There is a practical problem.

  Therefore, an object of the present invention is to provide a technique capable of realizing the construction of a hands-free system with higher versatility, assuming that a device that does not partially satisfy the specifications of the communication standard is also used.

In order to solve the above problems, the present invention employs the following solutions.
Solution 1: The present invention assumes a case where a portable device, a call device, and a hands-free system are constructed. A portable device can be connected to a telephone line, and a telephone device can perform hands-free calling through a telephone line using equipment different from the portable device by communicating with the portable device. It is. If the mobile device is a mobile phone having a built-in speaker, microphone, etc., the call device corresponds to a hands-free unit having a speaker or microphone as another facility. If mobile devices and telephone devices are each equipped with a device (communication module, etc.) that complies with general-purpose communication standards, a hands-free system can be easily constructed simply by bringing both devices close to a communicable distance. it can.

  The built system will cover the function of actually establishing a connection with the other party (far end) via the telephone line with the resources of the mobile device, but voice exchange (sending and receiving) during a hands-free call is not The call equipment is in the middle. In this case, basically, while the mobile device establishes a connection with the telephone line, the call device needs to secure its own resources in order to realize a hands-free call. On the other hand, when the user (near end) terminates the call with the other party (far end), the mobile device itself terminates the connection with the telephone line, and accordingly, the call device is also notified of the end of the call. It is necessary to cancel the entire system from the hands-free call state.

  Usually, when a general-purpose short-range wireless communication standard is used for a system, it is required in the specification that, in principle, the end of a call is voluntarily notified from a portable device to a communication device. For this reason, if each device is operating correctly in accordance with the specifications of the communication standard, it is possible to automatically confirm the end of the hands-free call as the entire system as the call ends. However, when a device that does not satisfy some of the specifications is mixed in, it becomes difficult to confirm the call as a whole system as described above.

  The present invention is a call confirmation method for stably confirming (ascertaining) the state of a call by the system in the above case, and includes the following steps.

(1) Questioning step In this step, the calling device makes an inquiry to the portable device about the operating state related to the connection with the telephone line. For inquiries from the telephone device to the portable device, for example, a communication unit that conforms to a general-purpose communication standard can be used.

(2) Confirmation step In this step, the state of a call by the hands-free system is confirmed by the calling device based on the response result from the portable device to the previous inquiry. Note that the response from the portable device to the call device can also use a communication means compliant with a general-purpose communication standard, for example.

  According to the call confirmation method of the present invention, by making an inquiry to the portable device in the questioning step (1), the operation state relating to the connection with the telephone line can be made to respond to the calling device at that time. The “operating status related to connection with the telephone line” here is not only “connected” or “not connected”, but also “standby”, “calling”, “not talking (end of call) ) ", Etc. In addition, the service operation status as a telephone is included, and more specifically," busy "," holding three-way call "," calling "," calling "," calling "," calling " The state of the call when actually making a call such as “on hold” is also included.

  Therefore, in the confirmation step (2), it is possible to recognize the current state based on the response result from the portable device and to correctly confirm the state of the call as the entire system. For example, if there is a response from the portable device indicating that it is already in the “call end (end call)” state, it can be confirmed that the call device is in a state where the hands-free call should be ended as a whole system. . On the other hand, it means that the mobile device is in a “calling”, “holding three-way call”, “calling”, “calling”, “receiving”, “pending call” status, etc. If there is a response, it is possible to confirm that the calling device is in a state in which a hands-free call should be continued as a whole system. As a result, it is possible to always stabilize the operation of the entire system and assure normal operation.

  Solution 2: In the questioning step (1) above, when the voice link between the portable device and the calling device is disconnected, the call from the calling device to the portable device is terminated. It is preferable to make an inquiry about whether or not.

  When short-range wireless communication is used in the system, a voice link (for example, SCO link) is established at the start of a hands-free call. The voice link is established when a call is made with the other party (far end), but is disconnected when “end of call” occurs in the portable device. At this time, even if the mobile device does not voluntarily notify the call device of “end of call”, by making the above inquiry when the voice link is disconnected, It can be confirmed whether or not “end” has occurred.

  Solution 3: Alternatively, in the questioning step (1) above, when the voice link between the portable device and the calling device is disconnected, a call using the telephone line is made from the calling device to the portable device. It may be inquired about what state it is.

  Similarly, in this case, the connection of the voice link is maintained during a call with the other party (far end), but is disconnected when “end of call” occurs in the portable device. At this time, even if the mobile device does not voluntarily notify the call device of “end of call”, by making the above inquiry when the voice link is disconnected, Can be confirmed. In addition, since the inquiry in this case is “what state the call is in”, the above “busy”, “holding three-way call”, “calling”, “calling”, “calling” In addition to being able to confirm a detailed call state such as “on hold”, it is also possible to confirm that the call has already ended.

  Also, the voice link disconnection occurs when the call with the other party (far end) ends as described above, but even if the mobile device is still talking, a hands-free call using the equipment of the call device It can also occur if you exit. For example, if a user had previously made a call with the other party (far end) hands-free and started the call with a mobile device in his hand from a certain point in time, the previously established voice link was disconnected. Is done. In this case, even if the mobile device does not voluntarily notify the call device of “end of call”, by making the above inquiry when the voice link is disconnected, It is possible to confirm the state of the call.

  Solution 4: In Solution 3 described above, if there is a response from the portable device that the call has not yet ended in response to the inquiry in the questioning step, a response that the call is ended from the portable device is then sent. The inquiry in the questioning process can be repeated with a predetermined waiting time until there is a certain time. Note that the “waiting time” does not always have to be a fixed time, and can be shortened or extended, for example, each time an inquiry is repeated.

  In this case, by repeatedly making an inquiry for each waiting time, it is possible to confirm the call state including the end of the call at regular or irregular intervals. Therefore, if a call is still in progress at the time of inquiry, it can be confirmed, and if the call has already ended, it can be confirmed reliably.

  Solution 5: The call confirmation method of the present invention is also the call confirmation method according to the present invention, in the solution 1 from the call device to the portable device triggered by the disconnection of the voice link between the portable device and the call device. The first inquiry about whether or not the call using the telephone line is completed, and if there is no response indicating that the call is ended from the portable device, the telephone line is used from the calling device to the portable device. A mode in which a second inquiry as to what state the call is in may be performed.

  According to the above aspect, if “call end” can be confirmed from the result of the first inquiry, the state of the call as a system can be confirmed for the time being, so there is no need to make a second inquiry thereafter. On the other hand, when there is still no “call end” response to the first inquiry, the subsequent “call state” can be confirmed by the second inquiry. As a result, if the call is actually continued even after the first inquiry, the status is “busy”, “holding three-way call”, “calling”, “calling”, “incoming” It is possible to check whether the call is in the middle, incoming call hold status, or the like. If the call has already ended, it can be confirmed that the call is in the “end call” state.

  Solution 6: In Solution 5, if there is a response from the mobile device that the call has not yet ended in response to the second inquiry in the above question process, the call is ended from the mobile device after that. It is also possible to repeat the inquiry in the questioning process with a predetermined waiting time until there is a response.

  That is, when there is a response “in call (call is not finished)” from the mobile device in response to the first inquiry, and in response to any “in-call state” response to the next second inquiry, After that, by repeatedly making inquiries until there is a “call end” response for each waiting time, it is possible to finally confirm “call end”.

  Note that the present invention may be a hands-free system that includes the above-described portable device and a call device, and executes the call confirmation methods of the solving means 1 to 6 using the portable device and the call device.

  According to the call confirmation method of the hands-free system of the present invention, for example, a stable hands-free call can be realized by effectively utilizing a general-purpose communication standard and preventing a problem of the system due to a device defect. .

  In addition, since a hands-free system can be stably constructed without depending on individual devices (model, model number, etc.), operation as a more versatile hands-free system can be guaranteed.

It is a figure which shows schematically the structural example of the hands-free system which performs the telephone call confirmation method of one Embodiment. It is a sequence diagram which shows the flow in case each device performs BT communication normally between a vehicle-mounted electrical equipment unit and a mobile telephone. It is a sequence diagram which shows the 1st pattern of a call confirmation method. It is a sequence diagram which shows the 2nd pattern of a call confirmation method. It is a sequence diagram which shows the 3rd pattern of a call confirmation method. It is a sequence diagram which shows the 4th, 5th pattern of the call confirmation method. It is a flowchart which shows the example of a procedure of the telephone call confirmation process which a BT module performs as a control program.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a diagram schematically illustrating a configuration example of a hands-free system 10 that executes a call confirmation method according to an embodiment. In the hands-free system 10, for example, an in-vehicle electrical unit 12 mounted in an automobile is used as a hands-free call device, and a mobile phone 18 brought into the vehicle is used as a mobile device. Each of the in-vehicle electrical unit 12 and the mobile phone 18 has a wireless communication function compliant with the Bluetooth (registered trademark) standard. In the following description, Bluetooth (registered trademark) is abbreviated as “BT”.

  The in-vehicle electrical unit 12 has, for example, a travel route guidance (navigation) function, an audio playback function, a video playback function, a reception function such as a radio and a television, and the like. For this reason, the in-vehicle electrical unit 12 includes a display unit 20 using a liquid crystal display or the like, an operation unit 22 having a push switch, a key switch, a rotary knob, etc. (not shown), a speaker 24 for sound output, Peripheral equipment such as a microphone 26 for collecting sound is attached.

  In addition, the in-vehicle electrical unit 12 includes a control unit 28 that controls the peripheral equipment, and also includes a BT module 30 in order to exhibit a wireless communication function using BT. The control unit 28 is a microcomputer including a host CPU 28a, which is a central processing unit, and a memory device such as a ROM and a RAM (not shown). For this reason, the BT module 30 can provide a service (for example, wireless connection such as an ACL link or an SCO link) using BT communication with the in-vehicle electrical unit 12 (host CPU 28a) as a host.

  The cellular phone 18 is a portable device that can be connected to a telephone line using wireless communication (for example, CDMA service). The cellular phone 18 is first connected to the base station 16 by wireless communication, and can communicate with the fixed telephone 14 of the other party (far end) through a wired telephone line. Here, the fixed telephone 14 is taken as an example of the other party (far end), but the other party (far end) may be another mobile phone. In any case, the mobile phone 18 also includes a BT module (not shown), and the mobile phone 18 can use the wireless communication function of the BT by using this BT module.

  The hands-free system 10 can provide a so-called “hands-free call” function in a state in which the mobile phone 18 and the in-vehicle electrical unit 12 are voice-linked (SCO link) by wireless connection. A hands-free call is, for example, a call with the user H3 of the fixed telephone 14 through the in-vehicle speaker 24 or the microphone 26, even if the user (driver H1, passenger H2, etc.) who is a vehicle occupant does not have the mobile phone 18 in his hand. Is realized.

  In addition, the hands-free system 10 reproduces audio data stored in the mobile phone 18 in real time while transferring the audio data stored in the mobile phone 18 to the in-vehicle electrical unit 12 in a state where the mobile phone 18 and the in-vehicle electrical unit 12 are wirelessly connected, for example. The function of outputting music from the speaker 24 can also be provided. Alternatively, it is possible to provide a function of transferring address book data stored in the mobile phone 18 to the in-vehicle electrical unit 12 and outputting it to the display unit 20. The hands-free system 10 can make a telephone call using the transferred address book data, and can display a called party when an incoming call is received from a party registered in the registered address book.

[Configuration of BT module]
Although not specifically shown here, the BT module 30 is connected to, for example, a BT antenna or an antenna matching circuit in the in-vehicle electrical unit 12, and another BT device (here, the mobile phone 18) is connected to the BT antenna and the antenna matching circuit. ) Wireless communication according to the BT standard. The BT antenna and the antenna matching circuit may be built in the BT module 30.

  The BT module 30 includes an RF processing unit, a baseband processing unit, and a transmission / reception processing unit as communication circuits. Among these, the RF processing unit performs reception processing of an RF signal (for example, 2.4 GHz band) through a BT antenna and an antenna matching circuit. The baseband processing unit converts the signal received by the RF processing unit into an IF signal and demodulates it to generate packet data (received packet). The transmission / reception processing unit reconstructs the reception packet data generated by the baseband processing unit for the upper layer, and conversely provides the transmission packet data (transmission frame) generated by the upper layer to the baseband processing unit. Or The transmission packet data is modulated by the baseband processing unit and transmitted to the mobile phone 18 through the RF processing unit, the antenna matching circuit, and the BT antenna.

  In addition, the BT module 30 has a built-in host interface, and this host interface controls communication between the control unit 28 (host CPU 28a) of the in-vehicle electrical unit 12 and the BT module 30. That is, the host interface outputs, for example, voice call data received by a hands-free call (call voice received by the mobile phone 18 into packet data) to the control unit 28 on the host side or picked up by the microphone 26 The communication when data (the voice of the driver H1 and the passenger H2 converted into packet data) is received from the control unit 28 is controlled.

  The received voice call data is converted into an analog signal (voltage) in the in-vehicle electrical unit 12 and output to the speaker 24 through an amplifier (not shown). The voice call data picked up by the microphone 26 is packet-transmitted from the BT module 30 to the mobile phone 18 by BT communication (SCO link). Thereby, for example, voice call data received from the mobile phone 18 by BT communication can be output from the speaker 24, and conversely, voice picked up by the microphone 26 can be transferred to the mobile phone 18.

[Call confirmation method]
Next, an example of a call confirmation method executed in the hands-free system 10 of this embodiment will be described.

[When device is normal]
FIG. 2 is a sequence diagram showing a flow when each device normally performs BT communication between the in-vehicle electrical unit 12 and the mobile phone 18. In FIG. 2, two columns located on the left side show processing by the in-vehicle electrical unit 12, and one column located on the right side shows processing by the mobile phone 18. In the following description, the in-vehicle electrical unit 12 will be described separately for the host CPU 28a and the BT module 30. The mobile phone 18 is generally referred to as “BT audio gateway (BTAG)”.

[BT connection]
ST1: First, in the hands-free system 10, the BT module 30 and the BTAG 18 complete the BT wireless connection (RFCOMM connection). Thereby, a voice link (SCO link) and a data link (ACL link) can be used between the BT module 30 and the BTAG 18.

  ST2 and ST3: Upon completion of the RFCOMM connection, each device of the BT module 30 and the BTAG 18 starts transmission / reception processing necessary for a hands-free call. Thereby, after that, while the BT module 30 and the BTAG 18 communicate with each other, in the vehicle, a voice call between the BTAG 18 and the fixed telephone 14 can be realized in a hands-free manner through the in-vehicle speaker 24 and the microphone 26.

[When the last episode occurs]
ST4: After this, for example, when an end call (end of call) occurs at the far-end fixed telephone 14 or the near-end BTAG 18, the end-of-call process is performed at the BTAG 18.

  ST5: Also, due to the occurrence of the end talk, the BTAG 18 issues an end talk event expressed as “+ CIEV (Call = 0)” to the BT module 30 based on the specification of the BT communication standard.

ST6: The BT module 30 performs reception processing and interprets the end-call event notified from the BTAG 18.
ST7: The BT module 30 notifies the host CPU 28a of “+ CIEV (Call = 0)” of the received end-call event. As a result, the host CPU 28a can confirm that the call has ended in the hands-free system 10.

  The above processing sequence is realized when each device operates normally based on a general BT communication standard. However, there is actually a BTAG 18 that does not satisfy a part of the specifications of the BT communication standard. In this case, even if the BTAG 18 is terminated, the end event “+ CIEV (Call = 0)” is BT. The module 30 is not notified. In this case, since the BT module 30 has not received “+ CIEV (Call = 0)” of the call end event even if the call is actually ended, the host CPU 28a cannot confirm the end of the call as it is.

  Therefore, in this embodiment, the state of a call as the hands-free system 10 is confirmed by adopting a sequence of a plurality of patterns listed below.

[First pattern]
FIG. 3 is a sequence diagram showing a first pattern of the call confirmation method. In FIG. 3 and subsequent figures, the same processes as those already described with reference to FIG.

[From BT connection to end of call]
ST1 to ST4: Also in the first pattern, the sequence from the BT connection to the end of the call is executed.

  However, if the device (built-in module) in the BTAG 18 does not meet the specifications, as shown by the dotted arrow in FIG. 3, even if the end of the call occurs, “+ CIEV (Call = 0)” of the end of call event is set. Not issued (marked with “x” in the figure). Accordingly, since the BT module 30 does not receive the end-call event, the end-event “+ CIEV (Call = 0)” is notified from the BT module 30 to the host CPU 28a as shown by the dotted arrow in FIG. Cannot be done (marked with “x” in the figure).

[When SCO link is disconnected]
ST10: However, the voice link (SCO link) between the BT module 30 and the BTAG 18 is disconnected due to the end of the call.

[Question process]
ST11: Triggered by the disconnection of the voice link (SCO link), the BT module 30 executes a question process, and generates a command for inquiry represented by, for example, “AT + CIND?”. This command inquires the BTAG 18 about the current service status (service, call, callsetup, signal, room).

  ST12: The BT module 30 issues an inquiry event described above as “AT + CIND?” To the BTAG 18.

  ST13: The BTAG 18 executes an event reception process and interprets a command represented by “AT + CIND?” In the inquiry event. The BTAG 18 generates a response event for the command.

  ST14: The BTAG 18 issues the generated response event to the BT module 30. If the call has actually ended at this time, the content of the response event should be a call end event represented by “+ CIEV (Call = 0)” (the notation in the figure is different).

[Confirmation process]
ST15: In this case, the BT module 30 performs reception processing and interprets the end-call event notified from the BTAG 18.
ST16: The BT module 30 notifies the host CPU 28a of “+ CIEV (Call = 0)” of the received end-call event. As a result, the host CPU 28a can confirm that the call has ended in the hands-free system 10 (the notation in the figure is different here).

  The above sequence is a flow when the BTAG 18 device normally notifies a response event in response to the inquiry event “AT + CIND?”. Therefore, the first pattern is effective as a call confirmation method when the device operates normally at this stage.

[When device is not operating normally]
ST14: However, as described above, when the BTAG 18 device still does not satisfy the specifications of the BT communication standard, as shown in FIG. BTAG 18 may issue an event during a call represented by “+ CIEV (Call = 1)” having different contents.

  ST15: In this case, the BT module 30 performs reception processing, and interprets the busy event notified from the BTAG 18 as it is.

  ST16: The BT module 30 notifies the host CPU 28a of “+ CIEV (Call = 1)” of the received busy event. In this case, the host CPU 28a cannot yet confirm that the call is actually ended in the hands-free system 10. Therefore, in the present embodiment, the second pattern of the call confirmation method described below can be executed.

[Second pattern]
FIG. 4 is a sequence diagram showing a second pattern of the call confirmation method. This second pattern can be applied, for example, when the call cannot be confirmed in the first pattern (when “+ CIEV (Call = 0)” is not notified from the BTAG 18). However, the second pattern can also be executed without considering such a condition.

[From BT connection to end of call, SCO link disconnection]
ST1 to ST4, ST10: Also in the second pattern, the flow from the BT connection to the end of the talk and the disconnection of the SCO link is performed in the same manner.

[Question process]
ST20: In the second pattern, the BT module 30 executes a question process triggered by the disconnection of the voice link, and generates a command for inquiry represented by, for example, “AT + CLCC”. This command inquires the BTAG 18 about the current call state (during a call, holding a three-way call, calling, calling, receiving, or holding an incoming call).

  ST21: The BT module 30 issues an inquiry event represented by the above “AT + CLCC” to the BTAG 18.

  ST22: The BTAG 18 executes an event reception process and interprets a command represented by “AT + CLCC” of the inquiry event. The BTAG 18 generates a response event for the command.

  ST23: The BTAG 18 issues the generated response event to the BT module 30. At this time, if the call has actually ended (the state where the call is not being made), the content of the response event is expressed only by “OK”. On the other hand, if the call has not actually ended (the state where the call is in progress), the content of the response event is expressed as “OK + CLCC”, and the current state is “busy” at “+ CLCC” ”,“ Holding three-way call ”,“ calling ”,“ calling ”,“ receiving ”, or“ holding incoming ”.

[Confirmation process]
ST24: In this case, the BT module 30 performs reception processing and interprets the content of the response event notified from the BTAG 18.

  ST25: The BT module 30 notifies the host CPU 28a of “OK” or “OK + CLCC” of the received response event. Thereby, for example, when receiving “OK”, the host CPU 28a can confirm that the call is ended in the hands-free system 10 (not in a call state). On the other hand, when “OK + CLCC” is received, the host CPU 28a can confirm the current call state notified by “+ CLCC”.

[At the end of the actual episode]
Normally, if the call is actually terminated at the BTAG 18 when the voice link (SCO link) is disconnected at “ST10”, the response event at “ST23” is only “OK”. Therefore, when the voice link (SCO link) is disconnected due to the actual end of the talk, if the second pattern sequence is applied, the host CPU 28a correctly confirms that the call by the hands-free system 10 has ended. can do.

[Call after disconnecting SCO link]
On the other hand, in the hands-free system 10, there may be a case in which a call is being performed on the BTAG 18 even after the voice link (SCO link) is disconnected between the BT module 30 and the BTAG 18. For example, even if the user is the same near-end user, when the passenger H2 who is not the driver H1 makes a call (for example, a private call) in the vehicle, the hands-free call is not always used. In this case, for example, the passenger H2 turns off the hands-free call function by the in-vehicle electrical unit 12 and performs a call or incoming call by operating the BTAG 18 by key operation, and the subsequent call is in the state of holding the BTAG 18 (that is, the mobile phone 18). To do.

  In the above case, after the voice link is disconnected in the previous “ST10”, in response to the inquiry event “AT + CLCC” from the BT module 30 in “ST21”, the BTAG 18 is actually “OK + CLCC (busy)” in “ST23”. Notify the response event. Then, in response to this, the BT module 30 notifies the host CPU 28a of “OK + CLCC (during a call)” in “ST25”. In this case, the host CPU 28a can confirm that it is in a state of “continuing a call with the BTAG 18 after the voice link (SCO link) is disconnected”.

[Third pattern]
FIG. 5 is a sequence diagram showing a third pattern of the call confirmation method. This third pattern is applied, for example, when the voice link (SCO link) is disconnected in the above second pattern and then “conversation” is confirmed by the BTAG 18 (when “OK + CLCC” is notified from the BTAG 18). can do.

[From BT connection to end of call, SCO link disconnection]
ST1 to ST4 and ST10: Also in the third pattern, the flow from the above BT connection to the end of the talk and the disconnection of the SCO link is performed similarly.

[Call after disconnecting SCO link]
Thereafter, for example, when the passenger H2 makes a telephone call by directly operating the BTAG 18 without using the hands-free function, the BTAG 18 enters a private conversation state with the fixed telephone 14 at the far end.

[From SCO link disconnection to inquiry / response event notification]
ST20-ST25: On the other hand, also in the third pattern, an inquiry event issuance after a SCO link is disconnected and a response event is notified and received. At this time, since the BTAG 18 is actually in a call, the response event in “ST23” is “OK + CLCC”, and as a result, the host CPU 28a confirms the “in call” state.

[End story at far end]
ST30: Thereafter, when the far-end user H3 (fixed telephone 14) terminates the call, for example, the connection to the telephone line by the BTAG 18 is thereby disconnected.
ST31: In this case, the BTAG 18 also performs the end call process.

[When device is not operating normally]
(ST32 (Fail)): Similarly, when the device (built-in module) does not satisfy the specification of the BT communication standard in the BTAG 18, as shown by the dotted arrow in FIG. Also does not issue “+ CIEV (Call = 0)” of the end-call event (marked with “x” in the figure).

(ST34 (Fail)): Therefore, since the BT module 30 does not receive the end-call event, the end-event “+ CIEV (Call) is also sent from the BT module 30 to the host CPU 28a as shown by the dotted arrow in FIG. = 0) "cannot be notified (indicated by" x "in the figure).

  Therefore, in this state, the host CPU 28a cannot confirm the “call end” state. Therefore, in the third pattern, the state of the call is confirmed by executing the following sequence.

[Event trigger occurrence]
ST35: For example, when the response event “OK + CLCC” is received in the previous “ST23”, the BT module 30 receives the response event and generates an event trigger. The event trigger can be generated on condition that the response event “OK + CLCC” is received. After that, the event trigger can be generated as a regular event using a timer, for example, or can be generated randomly without using a timer. In the sequence example of FIG. 5, the event trigger is generated after the end of the call at the far end (ST30), but the event trigger is generated spontaneously by the BT module 30 before the end of the call (ST30). It is also possible to use a sequence.

[Question process]
ST36: In any case, when an event trigger occurs, the BT module 30 executes a question process and generates an inquiry command represented by the above “AT + CLCC”.

  ST37: The inquiry event “AT + CLCC” is issued from the BT module 30 to the BTAG 18.

  ST38: The BTAG 18 executes an event reception process and interprets a command represented by “AT + CLCC” of the inquiry event. The BTAG 18 generates a response event for the command.

  ST39: The BTAG 18 issues the generated response event to the BT module 30. As described above, if the call is actually ended at this time (in a state where no call is made), the content of the response event is expressed only by “OK”. On the other hand, if the call has not yet ended (in a call state), the content of the response event is represented by “OK + CLCC”.

[Confirmation process]
ST40: The BT module 30 performs reception processing and interprets the content of the response event notified from the BTAG 18.

  ST41: The BT module 30 notifies the host CPU 28a of “OK” or “OK + CLCC” of the received response event. Thereby, for example, when receiving “OK”, the host CPU 28a can confirm that the call is ended in the hands-free system 10 (not in a call state). On the other hand, when “OK + CLCC” is received, the host CPU 28a can confirm the current call state notified by “+ CLCC”.

[Repetition of inquiry and confirmation]
When “OK + CLCC” is notified in the previous “ST41”, the BT module 30 subsequently generates an event trigger in “ST35”. Thus, every time an event trigger occurs, the sequence from “ST36” to “ST41” is repeatedly executed.

  After that, for example, when the telephone call is actually ended at the far-end fixed telephone 14, a response event of only “OK” is notified from the BTAG 18 in “ST39”. In response to this, the BT module 30 notifies only “OK” to the host CPU 28a in “ST41”. Thereby, the host CPU 28a can confirm that the call by the hands-free system 10 has been completed.

  The above third pattern is a sequence in the case where “AT + CLCC” is issued as an inquiry event from the BT module 30 after the voice link (SCO link) is disconnected. In addition, in this embodiment, after the voice link (SCO link) is disconnected, “AT + CIND?” Is first issued as an inquiry event, and “+ CIEV (Call = 0)” is not notified as a response event. A sequence of issuing “AT + CLCC” as an inquiry event can also be adopted. Hereinafter, the sequence in this case will be described as the fourth pattern of the call confirmation method.

[Fourth pattern]
FIG. 6 is a sequence diagram showing a fourth pattern of the call confirmation method. In the fourth pattern, for example, when the first pattern cannot be confirmed in the first pattern (the BTAG 18 does not voluntarily notify “+ CIEV (Call = 0)”), then the voice link (SCO link) is set. It can be applied when disconnected.

[From BT connection to end of call, SCO link disconnection]
ST1 to ST4 and ST10: Also in the fourth pattern, the flow from the BT connection to the end of the call and the disconnection of the SCO link is performed similarly.

[First inquiry: Question process]
ST11: Triggered by the disconnection of the voice link (SCO link), the BT module 30 executes a question process, and generates a command represented by “AT + CIND?” As the first inquiry command.

  ST12: The BT module 30 issues an inquiry event represented by the above “AT + CIND?” To the BTAG 18.

  ST13: The BTAG 18 executes an event reception process and interprets a command represented by “AT + CIND?” In the inquiry event. The BTAG 18 generates a response event for the command.

  ST14: The BTAG 18 issues the generated response event to the BT module 30. At this time, if the call has not actually ended, the content of the response event is an end-call event represented by “+ CIEV (Call = 1)”.

[Confirmation process]
ST15: In this case, the BT module 30 performs reception processing and interprets the end-call event notified from the BTAG 18.
ST16: The BT module 30 notifies the host CPU 28a of “+ CIEV (Call = 1)” of the received end event. As a result, the host CPU 28a can confirm that the hands-free system 10 is busy.

[Event trigger occurrence]
ST35: In the fourth pattern, when a response event other than “+ CIEV (Call = 0)” is received in the previous “ST14”, that is, a response event of “+ CIEV (Call = 1)” is received, this is used as a trigger for the BT module. 30 generates an event trigger. After that, the event trigger can be generated as a periodic interrupt event using a timer, for example, or can be generated randomly without using a timer.

[Second inquiry: Question process]
ST36: In any case, when an event trigger occurs, the BT module 30 executes question processing, and this time generates “AT + CLCC” as the second inquiry command.

  ST37: The inquiry event “AT + CLCC” is issued from the BT module 30 to the BTAG 18.

  ST38: The BTAG 18 executes an event reception process and interprets a command represented by “AT + CLCC” of the inquiry event. The BTAG 18 generates a response event for the command.

  ST39: The BTAG 18 issues the generated response event to the BT module 30. As described above, if the call is actually ended at this time (in a state where no call is made), the content of the response event is expressed only by “OK”. On the other hand, if the call has not yet ended (in a call state), the content of the response event is represented by “OK + CLCC”.

[Confirmation process]
ST40: The BT module 30 performs reception processing and interprets the content of the response event notified from the BTAG 18.

  ST41: The BT module 30 notifies the host CPU 28a of “OK” or “OK + CLCC” of the received response event. Thereby, for example, when receiving “OK”, the host CPU 28a can confirm that the call is ended in the hands-free system 10 (not in a call state). On the other hand, when “OK + CLCC” is received, the host CPU 28a can confirm the current call state notified by “+ CLCC”.

  When the BT module 30 receives the response event “OK” during the sequence of the fourth pattern, it is possible to confirm the end of the call, but when the response event “OK + CLCC” is received, the following Five patterns of sequences can be executed.

[Fifth pattern: Repeat of second inquiry / confirmation]
That is, when “OK + CLCC” is notified in the previous “ST41”, the BT module 30 subsequently generates an event trigger in “ST35”. Thus, every time an event trigger occurs, the sequence from “ST36” to “ST41” is repeatedly executed. The event trigger can be generated regularly or irregularly.

  After that, for example, when the telephone call is actually ended at the far-end fixed telephone 14, a response event of only “OK” is notified from the BTAG 18 in “ST39”. In response to this, the BT module 30 notifies only “OK” to the host CPU 28a in “ST41”. Thereby, the host CPU 28a can confirm that the call by the hands-free system 10 has been completed.

[Example of control program]
Each sequence of the first to fifth patterns listed above can be realized, for example, by incorporating the following control program into the BT module 30. The control program can be stored in a ROM built in the BT module 30, for example.

[Call confirmation processing]
FIG. 7 is a flowchart illustrating a procedure example of the call confirmation process executed by the BT module 30 as a control program. The BT module 30 can execute the call confirmation process shown in FIG. 7 as a timer interrupt process during a hands-free call, for example. Hereinafter, it demonstrates along the example of a procedure.

Step S100: With the start of processing, the BT module 30 confirms whether or not the “+ CIEV (Call = 0)” of the end-call event is notified from the BTAG 18.
Step S101: As a result, if “+ CIEV (Call = 0)” is actually notified (Step S100: Yes), the BT module 30 confirms the end of the call here and ends this processing.

  On the other hand, if “+ CIEV (Call = 0)” of the end-call event is not notified from the BTAG 18 (step S100: No), the BT module 30 next executes step S102.

  Step S102: The BT module 30 confirms whether or not the SCO link is disconnected with the BTAG 18. If the SCO link has not been disconnected yet (No), the BT module 30 returns to step S100 and repeats the confirmation of the call end event.

[In case of the first pattern]
On the other hand, when it is confirmed that the SCO link is disconnected (step S102: Yes), the BT module 30 proceeds to step S104.

  Step S104: The BT module 30 issues an inquiry event “AT + CIND?” To the BTAG 18.

  Step S106: The BT module 30 confirms whether “+ CIEV (Call = 0)” is notified from the BTAG 18 as a response event.

  Step S101: As a result, if a response event of “+ CIEV (Call = 0)” is actually notified (Step S106: Yes), the BT module 30 confirms the end of the call here and ends this process.

  By the procedure so far, the above-described sequence by the first pattern (FIG. 3) can be realized. Next, a procedure for realizing the sequence by the second pattern (FIG. 4) will be described.

[In case of the second pattern]
When it is confirmed that the SCO link is disconnected in the previous step S102 (step S102: (Yes)), this time, the BT module 30 follows the connection symbol “A” → “A” in FIG. Proceed to

  Step S108: The BT module 30 issues an inquiry event “AT + CLCC” to the BTAG 18.

  Step S110: The BT module 30 confirms whether or not “OK + CLCC” is notified from the BTAG 18 as a response event.

  Step S101: As a result, when a response event written with only “OK” is notified (Step S110: No), the BT module 30 confirms the end of the call here and ends this process.

  By the procedure so far, the above-described second pattern sequence (FIG. 4) can be realized. Next, a procedure for realizing the sequence by the third pattern (FIG. 5) will be described.

[In case of 3rd pattern]
When it is confirmed that “OK + CLCC” is notified from the BTAG 18 as a response event in the previous step S110 (step S110: Yes), the BT module 30 proceeds to step S112.

  Step S112: In this case, the BT module 30 counts an event timer. Specifically, the timer counter that has been stopped is activated and the count is started.

  Step S114: The BT module 30 checks whether or not the value of the event timer has reached a preset count value (for example, about several seconds to several tens of seconds). If the count value has not yet been reached (No), the BT module 30 returns to step S112 and continues the timer count.

  Thereafter, when it is confirmed that the value of the event timer has reached the count value (step S114: Yes), the BT module 30 stops the event timer, resets the value, and returns to step S108.

  Thereafter, the BT module 30 repeatedly executes step S108 to step S114. Thereby, the BT module 30 can repeatedly issue the inquiry event “AT + CLCC” until a response event “OK” is notified from the BTAG 18, thereby realizing the sequence according to the third pattern described above.

[In case of the 4th pattern]
In FIG. 7, when the determination in step S102 is affirmative (Yes), the sequence from the step S102 to the step S108 according to the connection symbol “A” → “A” results in a sequence according to the third pattern. On the other hand, when the process proceeds to step S104 without following the connection symbol “A” → “A”, the above-described fourth pattern sequence (FIG. 6) can be realized.

  Step S104: That is, the BT module 30 issues an inquiry event “AT + CIND?” To the BTAG 18 (first inquiry).

  Step S106: The BT module 30 confirms whether “+ CIEV (Call = 0)” is notified from the BTAG 18 as a response event.

  Step S101: As a result, if a response event of “+ CIEV (Call = 0)” is actually notified (Step S106: Yes), the BT module 30 confirms the end of the call here and ends this process.

  On the other hand, if “+ CIEV (Call = 0)” is not notified as a response event from the BTAG 18 in the previous step S106 (step S106: No), the BT module 30 next executes step S108.

  Step S108: Here, the BT module 30 issues an inquiry event “AT + CLCC” to the BTAG 18 (second inquiry).

  Step S110: The BT module 30 confirms whether or not “OK + CLCC” is notified from the BTAG 18 as a response event.

  Step S101: As a result, when a response event written with only “OK” is notified (Step S110: No), the BT module 30 confirms the end of the call here and ends this process.

  By the procedure so far, the sequence (FIG. 6) according to the fourth pattern described above can be realized. In addition, by executing step S112 and subsequent steps, the above-described sequence of the fifth pattern (same figure) can be realized.

[In case of 5th pattern]
That is, when it is confirmed that “OK + CLCC” is notified from the BTAG 18 as a response event in the previous step S110 (step S110: Yes), the BT module 30 proceeds to step S112.

  Step S112: In this case, the BT module 30 counts an event timer. Specifically, the timer counter that has been stopped is activated and the count is started.

  Step S114: The BT module 30 checks whether or not the event timer value has reached the count value. If the count value has not yet been reached (No), the BT module 30 returns to step S112 and continues the timer count.

  Thereafter, when it is confirmed that the value of the event timer has reached the count value (step S114: Yes), the BT module 30 stops the event timer, resets the value, and returns to step S108.

  Thereafter, the BT module 30 repeatedly executes step S108 to step S114. As a result, the BT module 30 can repeatedly issue the inquiry event “AT + CLCC” until a response event “OK” is notified from the BTAG 18, thereby realizing the sequence according to the fifth pattern described above.

  As described above, according to the call confirmation method of the present embodiment, even if the BTAG 18 (mobile phone 18) is equipped with a device that does not satisfy some specifications of the BT communication standard, an inquiry from the BT module 30 is made. By doing so, the host CPU 28a can finally confirm the state of the call end (end call).

  Therefore, the host CPU 28a does not destabilize the operation of the hands-free system 10 without confirming the end of the call forever. If the end of the call is confirmed, the subsequent operation (hands-free call by next incoming / outgoing call, audio output) Etc.) can be realized smoothly.

  Moreover, if it is the mobile telephone 18 corresponding to BT communication, the hands-free system 10 can be easily constructed | assembled combining this with the vehicle-mounted electrical equipment unit 12, without being restrict | limited to the model and model number. Therefore, versatility as the hands-free system 10 can be improved, and more practical operation can be guaranteed.

  In the flowchart shown in FIG. 7, it is first confirmed whether or not an end event “+ CIEV (Call = 0)” has been received in step S100, but without particularly determining such a condition, The process may be started from step S102.

  The present invention can be implemented with various modifications without being limited to the above-described embodiment. For example, the hands-free system 10 may be configured not only by a combination of the mobile phone 18 and the in-vehicle electrical unit 12 but also by a combination of other devices.

  Further, the hands-free system 10 does not always apply all the call confirmation methods of the first to fifth patterns, but may selectively apply any one of the call confirmation methods.

10 Hands-free system 12 On-board electrical unit 14 Fixed telephone 16 Base station 18 Mobile phone (BTAG)
24 Speaker 26 Microphone 28 Controller 28a Host CPU
30 BT module

Claims (6)

A portable device that can be connected to a telephone line, and a communication device that enables hands-free calling through the telephone line using equipment different from the portable device by communicating with the portable device. A call confirmation method for a hands-free system equipped with
A questioning process for inquiring about an operating state related to connection with the telephone line from the calling device to the portable device;
A call confirmation method for a hands-free system, comprising: a confirmation step of confirming a state of a call by a hands-free system at the call device based on a response result from the portable device to the inquiry. In the call confirmation method of the hands-free system according to claim 1,
In the question process,
When the voice link between the mobile device and the call device is disconnected, the call device makes an inquiry to the mobile device whether the call using the telephone line has ended. A call confirmation method for a hands-free system. In the call confirmation method of the hands-free system according to claim 1,
In the question process,
When the voice link between the portable device and the calling device is disconnected, the calling device makes an inquiry to the portable device as to what state the call using the telephone line is. A call confirmation method for a hands-free system. In the call confirmation method of the hands-free system according to claim 3,
If there is a response from the mobile device that the call has not yet ended in response to the inquiry in the questioning step, a predetermined waiting time is allowed until a response that the call is ended from the mobile device. A call confirmation method for a hands-free system, wherein the inquiry in the questioning step is repeated. In the call confirmation method of the hands-free system according to claim 1,
In the question process,
A first inquiry as to whether or not a call using the telephone line is terminated from the call device to the portable device when a voice link between the portable device and the call device is disconnected As a result, if there is no response from the portable device to the effect that the call has ended, the second inquiry is made from the calling device to the portable device regarding what state the call using the telephone line is. A call confirmation method for a hands-free system. In the call confirmation method of the hands-free system according to claim 5,
If there is a response from the portable device that the call has not yet ended in response to the second inquiry in the questioning step, a predetermined wait is made until there is a response from the portable device that the call has ended. A call confirmation method for a hands-free system, characterized in that the inquiry in the questioning process is repeated after a while.

Images