CN112367648A

CN112367648A - Call management method, chip and audio output device

Info

Publication number: CN112367648A
Application number: CN202011047442.3A
Authority: CN
Inventors: 朱明�
Original assignee: Shenzhen Goodix Technology Co Ltd
Current assignee: Shenzhen Goodix Technology Co Ltd
Priority date: 2020-09-29
Filing date: 2020-09-29
Publication date: 2021-02-12
Anticipated expiration: 2040-09-29
Also published as: CN112367648B

Abstract

The application discloses a call management method, a chip and an audio output device. The call management method comprises the following steps: during a first incoming call between an audio output device and one of N terminal devices on a terminal device side, if a plurality of call requests from the N terminal devices are received, storing a plurality of data respectively corresponding to the plurality of call requests according to the plurality of call requests and a preset storage mode, wherein the plurality of data comprise call access information respectively corresponding to the plurality of call requests; and outputting a call control signal according to the stored data and a preset dequeuing mode to enable the audio output device to generate a prompt signal, wherein the prompt signal indicates call access information corresponding to the dequeued data in the data to a user. The call management method can simplify a control mechanism of multiple call accesses and improve user experience.

Description

Call management method, chip and audio output device

Technical Field

The present application relates to call management technologies, and in particular, to a method for managing multiple calls of one or more terminal devices by using an audio output device, and a chip and an audio output device related thereto.

Background

With the application of the wireless bluetooth headset becoming more and more extensive, a user may have a plurality of terminal devices (such as mobile phones, tablet phones or vehicle-mounted terminals), even a user has a plurality of mobile phones which are all used in cooperation with the headset, and the usage scenarios become more and more diversified. For example, in an application scenario where a user connects multiple terminal devices with the same bluetooth headset, when the user is using the bluetooth headset to talk with one terminal device (e.g., a mobile phone), the currently talking terminal device may have another phone access, and the other terminal devices connected to the bluetooth headset may also have calls coming in at the same time. However, existing bluetooth headsets do not support such complex application scenarios. The user needs to answer or switch on each terminal device of the telephone access. That is to say, all the call answering controls need to be operated on the terminal device, for example, sometimes the terminal device is away from the user by a certain distance or the terminal device is placed in a pocket, and the user is inconvenient to operate a plurality of terminal devices, which further causes inconvenience in use. In addition, the number of mobile phones that can be connected to the existing bluetooth headset is limited. Therefore, in the above application scenario, when a voice data connection between the earphone end (bluetooth earphone) and the terminal device fails to be established due to earphone end connection limitation, voice data can only be input/output from the terminal device, resulting in poor user experience.

Disclosure of Invention

One of the objectives of the present application is to disclose a method for managing multiple calls of one or more terminal devices in an audio output device used in cooperation with the terminal device, and a chip and an audio output device related thereto, so as to solve the above technical problems in the prior art.

Certain embodiments of the present application disclose a call management method. The call management method is applied to an audio output device matched with a terminal device side for use, and comprises the following steps: during the first incoming call between the audio output device and one of the N terminal devices on the terminal device side, if a plurality of call requests from the N terminal devices are received, storing a plurality of data respectively corresponding to the plurality of call requests according to the plurality of call requests and a preset storage mode, wherein the plurality of data comprise call access information respectively corresponding to the plurality of call requests; and outputting a call control signal according to the stored data and a preset dequeuing mode to enable the audio output device to generate a prompt signal, wherein the prompt signal indicates call access information corresponding to the dequeued data in the data to a user.

Certain embodiments of the present application disclose a chip applied to an audio output device used in cooperation with a terminal device side. The chip includes a memory and a processor. The memory is to store program instructions. The processor is coupled to the memory and used for calling the program instructions stored in the memory so as to enable the chip to execute the call management method.

Certain embodiments of the present application disclose an audio output device comprising the above chip.

The call management method and the related chip and audio output device can directly manage the multiple calls at the earphone end, and can simplify a control mechanism of multiple call accesses and improve user experience through a simple mechanism of synchronizing control input (such as two control inputs corresponding to answering and hang-up) and state.

Drawings

Fig. 1 is a schematic diagram of an embodiment of the present application for managing multiple call accesses by an audio frequency output device used in conjunction with the terminal device side.

Fig. 2 is a flowchart of an embodiment of a call management method of the present application.

FIG. 3 is a schematic diagram of an embodiment of a memory operation of the chip shown in FIG. 1.

FIG. 4 is a schematic diagram of another embodiment of a memory operation of the chip shown in FIG. 1.

Fig. 5 is a message flow diagram of an embodiment of call management of the headset of fig. 1 for multiple handsets.

Fig. 6 is a message flow diagram of another embodiment of the headset of fig. 1 for call management of multiple handsets.

Detailed Description

The following provides various embodiments or examples for implementing different features of the present application. Specific examples of components and arrangements are described below to simplify the present application. Of course, these statements are merely examples and are not intended to limit the present disclosure. Further, the present application may repeat reference numerals and/or letters in the various examples. Such reuse is for purposes of brevity and clarity and does not in itself represent a relationship between the different embodiments and/or configurations discussed. Further, it will be understood that if an element is referred to as being "connected" or "coupled" to another element, it can be directly connected or coupled to the other element or be indirectly connected or coupled to the other element through the other element.

The call management scheme disclosed by the application can directly manage a plurality of calls at the earphone end, or the call management scheme disclosed by the application can be used for other electronic devices (or audio output devices) matched with the terminal equipment side (terminal device side) to manage the plurality of calls, and the call is not required to be kept and answered on each terminal equipment at the terminal equipment side, so that the user experience can be improved. It should be noted that the control manner of the call management at the earphone end also affects the user experience. In order to further improve user experience, the call management scheme disclosed by the application can perform simple external event input (such as single click, double click or long press) at the earphone end, namely, call holding and answering in a multi-connection scene can be processed, and a control mechanism of a complex call scene is further simplified.

For example, the call management scheme disclosed in the present application may manage a plurality of calls dialed into the terminal device side by storing call access information (which may indicate the terminal device and caller identification information corresponding to each call request) associated with a plurality of call requests in an earphone (such as a wireless earphone used in cooperation with one or more terminal devices on the terminal device side) and performing a simple control input directly in the earphone.

In addition, the call management scheme disclosed in the present application may store call access information related to a plurality of call requests in a queue manner. Therefore, even if the number of terminal devices to be connected to the earphone end exceeds the maximum number supported by a wireless communication protocol (e.g., bluetooth communication protocol), the call management scheme disclosed in the present application can ensure that a voice link can be successfully established between the earphone end and the terminal device requiring voice data connection by storing call access information corresponding to the terminal device not currently performing a call and disconnecting the voice link between the earphone end and the terminal device not currently performing a call, thereby solving the problem that voice data can only be input/output from the terminal device due to connection limitation of the earphone end. Moreover, when the user directly operates on the terminal device to answer the specified phone, the call management scheme disclosed by the application can synchronize the states of the earphone terminal and the phone being answered, and update the call access information stored in the earphone terminal.

Therefore, in a complex call scene, the call management scheme disclosed by the application can process multiple call accesses by utilizing a simple mechanism of controlling input and state synchronization of the headset at the headset end, and does not need to perform complex input control at the headset end, so that the user experience is improved. Further description is as follows.

Fig. 1 is a schematic diagram of one embodiment of the present application for managing multiple talk accesses in an audio frequency output device used with the terminal device side. In this embodiment, the audio output device for call management can be implemented by (but is not limited to) the headset 100, such as a bluetooth wireless headset, an infrared wireless headset, a radio frequency wireless headset, a 2.4G wireless headset or other types of wireless headsets, and thus the audio output device for call management can be considered to be located at the headset end 10. The one or more terminal devices at the terminal device side 12 may be implemented as N handsets 102.1-102.N, where N is a positive integer. Thus, the terminal device side 12 can be regarded as a mobile phone side. However, the present application is not limited thereto. It is also feasible to implement the audio output device for call management with other types of wireless audio output devices or other electronic devices used with the terminal equipment side 12. For example, in some embodiments, the audio frequency output device for call management may be implemented by a bluetooth speaker or a bluetooth watch. Furthermore, at least one terminal device located at the terminal device side 12 may be implemented by a tablet computer, a vehicle-mounted terminal, or other types of terminal devices, such as other portable terminal devices that may support a voice call function and/or a video call function.

The headset 100 is wirelessly coupled to the N handsets 102.1-102.N of the end device side 12 via N wireless links CL1-CLN, respectively, for use with the end device side 12. For example, a wireless link (i.e., one of the N wireless links CL 1-CLN) may be established between the headset 100 and each terminal device (i.e., each handset) on the terminal device side 12 according to a wireless communication protocol, so that the headset 100 may be wirelessly coupled to each terminal device. The wireless communication protocol may include, but is not limited to, a bluetooth communication protocol, an infrared data transfer protocol, a radio frequency wireless communication protocol, and a 2.4G wireless communication protocol. In some embodiments where the wireless link between the headset 100 and each terminal device is established according to the bluetooth communication protocol, the wireless link may include an asynchronous connection less link (ACL) and a hands-free profile (hand-free profile) link.

In this embodiment, the headset 100 may include a chip 101 that manages multiple phones accessed by the terminal device side 12. In this embodiment, the chip 101 may manage the plurality of telephones accessed by the terminal device side 12 by storing call access information associated with one or more call requests sent by the N handsets 102.1-102. N. Please refer to fig. 1 and fig. 2 together. Fig. 2 is a flowchart of an embodiment of a call management method of the present application. The call management method 20 can be applied to an audio output device or an electronic device used with a terminal device. For convenience of description, an embodiment of the headset 100/chip 101 shown in fig. 1 for managing a plurality of phones accessed by the terminal device side 12 will be described below in conjunction with the call management method 20 shown in fig. 2. However, the present application is not limited thereto. In some embodiments, the call management method 20 may also include other steps. The headset 100/chip 101 shown in fig. 1 may employ alternative implementations based on the call management method 20 shown in fig. 2 without departing from the spirit and scope of the present application.

Furthermore, to facilitate understanding of the call management scheme disclosed in the present application, "receiving a call request" described below may mean that the chip 101 (or the earphone terminal 10) receives a call request transmitted from the terminal apparatus side 12. The "receiving a call request" described below may mean that the user inputs an external trigger event, so that the chip 101 sends a control signal or command to the terminal device 12 to prepare to receive an incoming call corresponding to the call request. "answering an incoming call" described below may mean establishing a voice link between the chip 101 and the terminal apparatus side 12 to allow a caller to talk with a user.

In step 26, during a first incoming call between the earphone 100 and one of the N handsets 102.1-102.N of the terminal device side 12, if the chip 101 receives a plurality of call requests (e.g., one or more call requests) from the N handsets 102.1-102.N, a plurality of data respectively corresponding to the plurality of call requests are stored according to the plurality of call requests and a preset storage manner, where the plurality of data includes call access information corresponding to each of the plurality of call requests.

For example, the handset 102.1 may send a call request CR1 to the headset 100 according to the incoming call CC 1. When the chip 101 receives the information that the user accepts the call request CR1 (i.e., the call request is allowed to be answered CC 1) (e.g., the chip 101 receives the user input CIN1 for accepting the call request CR 1), the chip 101 may send a control signal or command to the cell phone 102.1 through the wireless link CL1 between the headset 100 and the cell phone 102.1, so that a voice link is established between the headset 100 and the cell phone 102.1, thereby answering the call CC1 corresponding to the call request CR 1. In some embodiments where the wireless link is established between the headset 100 and the handset 102.1 according to the bluetooth communication protocol, the voice link may be a connection-oriented synchronous link (SCO link) or a connection-oriented extended synchronous link (eSCO link).

Next, during a call between the headset 100 and the handset 102.1 at the incoming call CC1, the chip 101 may receive a plurality of call requests respectively corresponding to a plurality of other incoming calls (e.g. one or more incoming calls) from the terminal apparatus side 12, and store a corresponding plurality of data (e.g. one or more data) accordingly. It is noted that the plurality of call requests may include being sent by the handset 102.1 sending the call request CR1 and/or being sent by one or more of the N handsets 102.1-102.N other than the handset 102.1.

For example, during a call between the headset 100 and the handset 102.1 at the end of incoming call CC1, when the handset 102.1 receives another incoming call CC1 ', the handset 102.1 may send another call request CR1 ' to the chip 101 in response to the incoming call CC1 '. If the chip 101 receives the call request CR1 ', the chip 101 may store data DA1 ' according to the call request CR1 ' and the predetermined storage manner, wherein the data DA1 ' includes call access information corresponding to the call request CR1 ', which may indicate (but is not limited to) the cell phone 102.1 that sent the call request CR1 ' and caller identification information (such as the phone number of the caller) of the call CC1 '. For another example, during a call between the headset 100 and the handset 102.1 at the telephone incoming CC1, the handset 102.2 can receive a telephone incoming CC2 and send a call request CR2 to the chip 101. If the chip 101 receives the call request CR2, the chip 101 may store data DA2 according to the call request CR2 and a predetermined storage manner, wherein the data DA2 includes call access information corresponding to the call request CR2, which may indicate (but is not limited to) the cell phone 102.2 sending the call request CR2 and caller identification information (such as a phone number of the caller) of the call CC 2. For another example, when the chip 101 receives several call requests (e.g. the call request CR1 'and the call request CR 2) during a call between the headset 100 and the cellular phone 102.1 at the incoming call CC1, the chip 101 may store several data (e.g. the data DA 1' and the data DA 2) according to the several call requests and a preset storage manner.

In step 28, a call control signal is output according to the stored data and the predetermined dequeue manner, so that the earphone 100 generates a prompt signal indicating the call access information corresponding to the dequeued data in the data to the user.

For example, during the call of the incoming call CC1, the chip 101 receives a call request CR1 'corresponding to another incoming call CC 1' that is dialed to the cell phone 102.1. The chip 101 may output a communication control signal according to the data DA1 ' and a predetermined dequeue manner, so that the headset 100 generates a prompt signal RS1, which indicates to the user the call access information (such as the phone number of the incoming call CC1 ') corresponding to the dequeued data DA1 '. The communication control signal may cause a prompt signal generating circuit (such as an audio output circuit; not shown in fig. 1) of the headset 100 to generate the prompt signal RS 1. For another example, during the call of the incoming call CC1, the call request received by the chip 101 is the call request CR2 corresponding to the incoming call CC2 dialed to the cell phone 102.2. The chip 101 may output the communication control signal according to the data DA2 and a predetermined dequeue manner, so that the headset 100 generates a prompt signal RS2, which may indicate to the user the call access information (such as the phone number of the incoming call CC 2) corresponding to the dequeued data DA 2. The communication control signal may cause a prompt signal generating circuit (such as an audio output circuit; not shown in fig. 1) of the headset 100 to generate the prompt signal RS 2. For another example, during a call between the headset 100 and the mobile phone 102.1 at the incoming call CC1, the chip 101 receives a plurality of call requests including the call request CR1 'and the call request CR2, and the chip 101 outputs the communication control signal according to a plurality of stored data (respectively corresponding to the call requests) including the data DA 1' and the data DA2 and a preset dequeue manner, so that the headset 100 generates a prompt signal indicating to the user call access information corresponding to the dequeued data in the plurality of data.

In some embodiments, the call access information of the data stored in step 26 may include caller identification information. The chip 101 may play a sound signal prompting the corresponding caller identification information according to the dequeued data in step 28 to serve as the prompt signal. For example, the headset 100 may broadcast a phone number of the incoming call CC1 '/CC 2 according to the data DA 1'/DA 2, wherein a sound signal of the incoming call number is broadcast as the alert signal RS1/RS 2. Therefore, the user can judge whether to hang up or keep the current incoming call CC1 to answer the incoming call CC 1'/CC 2 according to the incoming call number broadcasted by the prompt signal RS1/RS 2.

In some embodiments, the predetermined storage manner of step 26 may be a queue storage manner, for example (but the application is not limited thereto), and the chip 101 may store the data DA1 'and the data DA2 in a queue manner according to the time sequence of receiving the call request CR 1' and the call request CR 2.

In some embodiments, the predetermined dequeue mode of step 28 may be dequeuing the data stored first. Therefore, in the case where the chip 101 sequentially stores the data DA1 'and the data DA2 during the call of the incoming call CC1, the chip 101 may enable the earphone 100 to generate the prompt signal RS1 first, so that the user can respond to the earlier-sent call request CR 1' preferentially. In the case where the chip 101 sequentially stores the data DA2 and the data DA 1' during the call of the incoming call CC1, the chip 101 may enable the earphone 100 to generate the prompt signal RS2 first, so that the user can respond to the earlier-sent call request CR2 with priority.

For example, the chip 101 may employ a first-in-first-out (fifo) queue to store data corresponding to each call request. The headset 100 may generate a corresponding alert signal based on the dequeued data. Since enqueued data may be dequeued first, the headset 100 may preferentially generate a prompt to dial into the N handsets 102.1-102.N earlier. Since the headset 100 may employ the fifo queue to buffer the data corresponding to each of the plurality of call requests, the data queued first (corresponding to the phone first dialed into the N handsets 102.1-102. N) may be dequeued first, allowing the user to respond to the call request sent earlier first.

Fig. 3 and 4 are schematic diagrams of some embodiments of memory operations of chip 101 shown in fig. 1. For convenience of illustration, the storage operations shown in fig. 3 and 4 are performed based on a scenario (i.e., N = 4) in which the chip 101 shown in fig. 1 manages calls of a plurality of handsets 102.1-102.4. In the embodiments shown in fig. 3 and 4, the chip 101 may employ a queue 105 (such as a fifo queue) to store data corresponding to each call request, wherein the fifo queue 105 may be implemented by software or hardware. The queue 105 may perform the storing operation according to the time sequence of the chip 101 receiving the call requests.

Please refer to fig. 3 in conjunction with fig. 1. In the embodiment shown in fig. 3, the handset 102.1 first sends a call request CR1 to the chip 101 according to the incoming call CC 1. Since the communication request CR1 received by the chip 101 is the first communication request sent from the multiple cell phones 102.1-102.4, if the chip 101 receives the information that the user accepts the communication request CR1, the chip 101 can send a control signal or command to the cell phone 102.1 according to the bluetooth communication protocol and the communication request CR1 to receive the incoming call CC1 corresponding to the communication request CR 1. Chip 101 may not need to store call access information corresponding to call request CR1 in queue 105.

Next, when the currently speaking cell phone 102.1 has another incoming call CC 1' or other cell phones connected to the headset 100 (e.g. one of the multiple incoming calls CC2-CC 4) have access, the chip 101 may push the corresponding data into the queue 105 according to the time sequence of receiving the call request. For example, in a case where the chip 101 sequentially receives a call request CR1 ' (corresponding to the incoming call CC1 '), a call request CR2 (corresponding to the incoming call CC 2), a call request CR3 (corresponding to the incoming call CC 3), and a call request CR4 (corresponding to the incoming call CC 4), the chip 101 may sequentially push the corresponding data DA1 ', data DA2, data DA3, and data DA4 into the queue 105. Since the data DA1 ' may include the call access information corresponding to the call request CR1 ', the incoming call CC1 ' for accessing the cell phone 102.1 may be identified. Similarly, the data DA2, the data DA3, and the data DA4 may identify the incoming call CC2 accessing the cell phone 102.2, the incoming call CC3 accessing the cell phone 102.3, and the incoming call CC4 accessing the cell phone 102.4, respectively.

In this embodiment, the data CDA may dequeue the queue 105 when the currently speaking handset 102.1 has another incoming call CC 1' or another handset connected to the headset 100 has incoming call. For example, during a call from the caller CC1, the chip 101 may check whether the queue 105 stores data corresponding to each of any call requests from the multiple handsets 102.1-102.4. When the dequeue 105 is checked to store data corresponding to at least one call request from the multiple handsets 102.1-102.4, the chip 101 may push the data that is most recently entered into the dequeue 105 out of the dequeue 105, and generate a prompt signal according to the pushed data, so as to indicate call access information corresponding to the pushed data to the user. In the embodiment of fig. 3, the chip 101 may push out the data DA1 ' and make the headset 100 report the phone number of the incoming call CC1 ' according to the data DA1 '. The user may decide whether to answer or hang up the incoming call CC 1'. It is noted that chip 101 may enable headset 100 to broadcast the phone number of incoming call CC 1' at a low volume to reduce the impact on the current call.

In some embodiments, the chip 101 may dequeue the queue 105 when the currently speaking handset 102.1 ends the call. For example, when a call coming from CC1 ends, chip 101 may check whether several data stored in queue 105 (respectively corresponding to several call requests) have been dequeued. If the queue 105 stores data corresponding to at least one call request from the plurality of handsets 102.1-102.4, the chip 101 may dequeue the data that was most recently enqueued in the queue 105 and generate a prompt signal according to the dequeued data, so as to indicate call access information of a corresponding incoming call to the user. In the embodiment of fig. 3, when the call of the incoming call CC1 is ended (for example, the call of the incoming call CC1 is ended and the incoming call CC 1' is answered), the chip 101 may check out that the data DA2 is the data of the first-in-queue 105, thereby pushing out the data DA2 to make the headset 100 broadcast the phone number of the incoming call CC 2.

In some embodiments, data stored in queue 105 may have been deleted without being pushed out. Please refer to fig. 4 in conjunction with fig. 1. In this embodiment, the chip 101 receives the call request CR3, the call request CR 1', the call request CR2 and the call request CR4 in sequence. Accordingly, the chip 101 may sequentially push the corresponding data DA3, data DA 1', data DA2, and data DA4 into the queue 105. When the caller of the mobile phone 102.2 actively hangs up the phone call, or the user directly operates on the mobile phone 102.2 to refuse to answer the call CC2, the mobile phone 102.2 may send a related control signal or command to the chip 101, so that the chip 101 deletes the corresponding data DA2 in the queue 105. That is, the state of the earphone end 10 (such as data stored by the chip 101) can be synchronized with the state of the terminal device side 12. Thus, the chip 101 may allow an external trigger event (such as the caller actively hanging up the phone, or the user directly handling incoming calls at the terminal device side 12) to change the call state, thereby providing a control mechanism with a high flexibility.

The above incoming call sequence for the N handsets 102.1-102.N is for ease of illustration only and is not intended to limit the scope of the present application. In some embodiments, the call management method 20 shown in fig. 2 can be applied to an application scenario in which when the mobile phone 102.i (i is a positive integer from 1 to N) shown in fig. 1 is in a call, other incoming calls are dialed into N mobile phones 102.1-102. N.

It should be noted that by storing call access information (which may indicate the handset and caller identification information corresponding to each call request) related to one or more call requests sent by the terminal device side 12 in the chip 101 located at the earphone end 10, a user can directly handle a complex call application scenario at the earphone end 10 by using simple control input. Please refer to fig. 1 again. In this embodiment, the chip 101 may include, but is not limited to, a memory 110 and a processor 120. The memory 110 may be used to store program instructions. The processor 120 is coupled to the memory 110 and is configured to call the program instructions stored in the memory 110, so that the chip 101 executes the call management scheme disclosed in the present application, such as the call management method 20 shown in fig. 2. For example, the memory 110 may be further configured to store data corresponding to a plurality of call requests from the N handsets 102.1-102.N, and the processor 120 may call the program instructions stored in the memory 110, so that the chip 101 may output the call control signal CS0 according to the stored data and a preset dequeue manner. The alert signal generating circuit (such as an audio output circuit; not shown in fig. 1) of the headset 100 may generate an alert signal (such as the alert signals RS1/RS 2) according to the call control signal CS 0.

In addition, the chip 101 may perform call management, such as answering an incoming call, holding a call, hanging up a call, or rejecting an answer, according to a user input from a user interface (not shown in fig. 1) of the headset 100. For example, the user interface of the headset 100 may be implemented as, but not limited to, a physical key, a virtual key, or a touch screen. When the user receives the alert signal, the user may perform a simple control operation (such as a single click, double click, long press) on the user interface of the headset 100. The processor 120 can call the program instructions stored in the memory 110 according to the user input, so that the chip 101 sends a control signal CS1 to a mobile phone to control the mobile phone to answer an incoming call, hang up a call, or keep a current call.

In some embodiments, the memory 110 may employ a software implementation method or a hardware implementation method to store data corresponding to the call requests. For example, the memory 110 may include a queue storage structure implemented in a software implementation method or a hardware implementation method, so that the data may be sequentially stored in the memory 110 in a queue manner. In some embodiments where the queue storage structure is implemented as a first-in-first-out queue, the user may prioritize earlier-sent call requests since the first-in data may be dequeued first.

In some embodiments, if the user actively answers/hangs up the phone call on the terminal device side 12, the terminal device side 12 can send information to the earphone end 10 to synchronize the states of the earphone end 10 and the terminal device side 12.

For example (but the present application is not limited thereto), during a call between the earphone 100 and the cell phone 102.1 at the incoming call CC1, the incoming call CC1 'and the incoming call CC2 are dialed to the terminal device side 12 sequentially, so that the chip 101 can receive the call request CR 1' sent by the cell phone 102.1 and the call request CR2 sent by the cell phone 102.2 sequentially, wherein the data DA1 'corresponding to the incoming call CC 1' can be dequeued from the chip 101 first, and the data DA2 corresponding to the incoming call CC2 is not dequeued from the chip 101 yet. Before the incoming call CC 1' is not answered yet, if the incoming call CC2 is answered by the user at the terminal device side 12, the chip 101 may keep the incoming call CC1 and delete the data DA2 corresponding to the incoming call CC 2. For example, when the user directly operates the mobile phone 102.2 to answer the incoming call CC2, the mobile phone 102.2 can send a control signal CS2 to the chip 101, wherein the control signal CS2 indicates that the incoming call CC2 corresponding to the call request CR2 has been answered. The chip 101 may delete the data DA2 corresponding to the incoming call CC2 according to the control signal CS2, and send another control signal (not shown in fig. 1) to the cell phone 102.1 to hold the incoming call CC 1. That is, when the user actively answers the call on the terminal device side 12, the earphone terminal 10 may synchronize the state of the earphone terminal 10 (such as data stored in the chip 101 or the memory 110) with the state of the terminal device side 12 according to the control signal transmitted by the terminal device side 12.

In addition, after the call of the incoming call CC2 is ended, the chip 101 may make the headset 100 answer the incoming call CC 1' that was dialed to the terminal device side 12 earlier than the incoming call CC 2. Therefore, the earlier dialed call CC 1' can still be answered. It is noted that, in some embodiments, before the incoming call CC1 'is not answered yet, if the incoming call CC2 is answered by the user at the terminal device side 12, the chip 101 may hang up the incoming call CC 1', in addition to the data DA2 corresponding to the hold incoming call CC1 and the delete incoming call CC 2. Therefore, the situation that the caller CC2 is answered and the caller CC 1' waits too long can be avoided.

Similarly, before the incoming call CC 1' is not answered yet, if the incoming call CC2 is hung up by the user on the terminal device side 12, the headset side 10 may delete the corresponding data DA2 in the chip 101 according to the control signal sent by the terminal device side 12, so as to synchronize the state of the headset side 10 with the state of the terminal device side 12. Therefore, the call management scheme disclosed by the application not only can directly manage a plurality of calls on the terminal equipment side by using simple control input on the earphone end, but also can allow a user to directly process incoming calls on the terminal equipment side in a state synchronization mode, thereby providing a simplified and elastic control mechanism.

The circuit structure of the chip 101 is for illustration purposes only and is not intended to limit the scope of the present application. It is possible to implement the chip 101 by using other circuit configurations as long as the headset terminal 10 can store the call request transmitted from the terminal device side and manage the multiple call accesses of the terminal device side accordingly.

For ease of understanding, fig. 5 and 6 illustrate an embodiment of managing multiple phone calls using a bluetooth headset to illustrate the call management scheme disclosed in the present application. However, the present application is not limited thereto. Any circuit chip/audio output device that can manage multiple calls on the terminal device side using the call management method 20 shown in fig. 2 is within the scope of the present application.

Please refer to fig. 5 in conjunction with fig. 1. Fig. 5 is a message flow diagram of an embodiment of the headset 100 shown in fig. 1 for call management of multiple handsets 102.1-102.3 (i.e., N = 3). In this embodiment, the headset 100 may be implemented as a bluetooth headset. The chip 101 and the plurality of mobile phones 102.1-102.3 respectively establish corresponding wireless links (i.e. one of the plurality of wireless links CL1-CL 3) according to the bluetooth communication protocol, which includes asynchronous connectionless links and hands-free profile links. The identification code (or serial number) of the headset 100 may be communicated to a plurality of handsets 102.1-102.3. Therefore, when a call is accessed to one of the plurality of mobile phones 102.1 to 102.3, the mobile phone may send an AT command (AT command) to the chip 101 according to the bluetooth communication protocol, so as to send a phone number dialed into the mobile phone to the chip 101.

In this embodiment, the chip 101 first establishes a voice link CLX1 (i.e., connection-oriented sync link/connection-oriented extended sync link) with the mobile phone 102.1 to answer an incoming call CC1 dialed to the mobile phone 102.1. During the call of the incoming call CC1, the chip 101 receives the call request CR 1' sent by the handset 102.1, the call request CR2 sent by the handset 102.2, and the call request CR3 sent by the handset 102.3 in sequence. However, those skilled in the art should realize that this is for convenience of illustration only and is not intended to limit the scope of the present application.

First, when the handset 102.1 has an incoming call CC1 accessed, the handset 102.1 may send a call request CR1 (such as + CIEV (callsetup =1) defined by the AT command set) to the chip 101 according to the bluetooth communication protocol to notify the chip 101 that the incoming call CC1 has accessed the handset 102.1. In operation 501, the chip 101 may send a control signal (such as an AT command) to the mobile phone 102.1 to answer the incoming call CC1 of the mobile phone 102.1. Furthermore, a voice link CLX1 (i.e. connection-oriented synchronous link/connection-oriented extended synchronous link) can be established between the chip 101 and the handset 102.1.

Then, during the call of the incoming call CC1, the handset 102.1 has another incoming call CC 1' to access. The handset 102.1 may send information 511 (AT command, such as + CCWA defined by the AT command set) and information 512 (call request CR1 ', such as + CIEV (callsetup = 1)) to the chip 101 according to the bluetooth communication protocol to inform the chip 101 that the incoming call CC1 ' has accessed the handset 102.1 and is waiting for a reply, and to send the phone number of the incoming call CC1 ' to the chip 101. In operation 502, the chip 101 may push the data DA1 'corresponding to the call request CR 1' into a queue (e.g., the queue 105 shown in fig. 3/4), wherein the data DA1 'may identify the incoming call CC 1' accessing the cell phone 102.1. In operation 503, the chip 101 may check whether the queue is empty (i.e., check whether the stored data corresponding to the call request has all been dequeued). When the queue is not empty, indicating that there is a call request waiting for response, the chip 101 may dequeue the data (i.e., the data DA1 ') stored first in the queue and generate a prompt signal according to the data DA 1' to alert the user that the incoming call CC1 '(or the call request CR 1') is waiting for response. That is, the chip 101 may check whether the data DA 1' is still stored in the chip 101. When it is checked that the data DA1 ' is still stored in the chip 101, the chip 101 may dequeue the data DA1 ' and generate the hint signal according to the dequeued data DA1 '. In this embodiment, the chip 101 may enable the headset 100 to broadcast the phone number of the incoming call CC1 'according to the dequeued data DA 1'. In some embodiments, chip 101 may cause headset 100 to broadcast the phone number of incoming call CC 1' at a low volume to reduce the impact on the current call.

In addition, during the call of the incoming call CC1, the incoming call CC2 accesses the handset 102.2. The handset 102.2 may send information 513 (call request CR2, such as + CIEV (callsetup = 1)) and information 514 (AT command, such as + CLIP defined by the AT command set) to the chip 101 according to the bluetooth communication protocol to inform the chip 101 that the incoming call CC2 has accessed the handset 102.2 and to send the phone number of the incoming call CC2 to the chip 101. In operation 504, the chip 101 may push data DA2 corresponding to the call request CR2 into the queue, where the data DA2 may identify the incoming call CC2 accessing the cell phone 102.2. During the call of the incoming call CC1, there is also an incoming call CC3 to access the handset 102.3. The handset 102.3 may send information 515 (call request CR3, such as + CIEV (callsetup = 1)) and information 516 (AT command, such as + CLIP) to the chip 101 according to the bluetooth communication protocol to inform the chip 101 that the incoming call CC3 has accessed the handset 102.3 and to send the phone number of the incoming call CC3 to the chip 101. In operation 505, the chip 101 may push data DA3 corresponding to the call request CR3 into the queue, where the data DA3 may identify that the incoming call CC3 accesses the cell phone 102.3.

In this embodiment, when the incoming call corresponding to the other call request different from the call request CR1 is answered, the chip 101 may control the cell phone 102.1 to hold the incoming call CC 1. When the call for the received call is over, the chip 101 may send a control signal (such as an AT command) to the handset 102.1 to resume the call for the incoming call CC 1. For example, after data DA3 is stored in the queue 310 of the chip 101, the chip 101 can receive a user input CIN1 (such as double-clicking or single-clicking the user interface of the chip 101) for accepting a call request corresponding to a data dequeued from the chip 101. The chip 101 may send a control signal (such as an AT command) to the mobile phone sending the call request according to the user input CIN1, so as to answer the incoming call corresponding to the call request. When the call of the incoming call corresponding to the call request is ended, the chip 101 may send a control signal (such as an AT command) to the handset 102.1 to resume the call of the CC 1.

It should be noted that, if the chip 101 receives the user input CIN1 for accepting the call request, the chip 101 can determine whether the call request is sent by the calling handset according to the dequeued data, and accordingly generate a determination result. In addition, the chip 101 may answer the incoming call corresponding to the call request according to the determination result. For example, when the determination result indicates that the call request is sent by the calling handset, since the voice link is already established between the chip 101 and the calling handset, the chip 101 may switch the current call to the incoming call corresponding to the call request without establishing the voice link again. In addition, when the determination result indicates that the call request is sent by another mobile phone different from the mobile phone in the call, the chip 101 may disconnect the voice link between the chip 101 and the mobile phone in the call and establish the voice link between the chip 101 and the another mobile phone to allow the chip 101 to answer the incoming call corresponding to the call request.

In this embodiment, since the call request CR1 'corresponding to the data DA 1' dequeued from the chip 101 is sent by the currently-calling handset 102.1, the chip 101 can send a control signal (message 517) to the handset 102.1 to answer the call CC1 'of the handset 102.1 (corresponding to the call request CR 1'). Furthermore, in some embodiments, the chip 101 may send the control signal to the handset 102.1 to keep the handset 102.1 originally talking (i.e., keep incoming call CC 1'). For example, the chip 101 may send information 517 (AT command, such as AT + CHLD =2 defined by the AT command set) to the handset 102.1 to hold the incoming call CC1 of the handset 102.1, causing the handset 102.1 to send information 518 (AT command, such as + CIEV defined by the AT command set) (callsetup =0, callhold = 1)) to the chip 101 to indicate that the handset 102.1 picked up the second call (incoming call CC 1') and held the first call (incoming call CC 1). The voice link CLX1 between the chip 101 and the handset 102.1 switches to a call of the incoming call CC 1'.

In operation 506, the call of the incoming call CC 1' is ended. For example, the user may use the headset 100 to end the call at the incoming call CC1 ', or the caller at the incoming call CC 1' may hang up. The handset 102.1 may send information 519 (AT command, such as + CIEV (callhold =2) defined by the AT command set) to the chip 101 indicating that the incoming call CC1 of the handset 102.1 is held. Next, the chip 101 may send information 520 (AT instruction, such as AT + CHLD =2) indicating that the incoming call CC1 of the handset 102.1 is ready to be activated. The handset 102.1 may send a message 520 (AT instruction, such as + CIEV (callhold = 0)) to the chip 101 indicating that the voice link CLX1 between the chip 101 and the handset 102.1 switched to a call with the incoming call CC 1.

In operation 507, the chip 101 may check whether the queue is empty (i.e., check whether the stored data corresponding to the call request have all been dequeued). When the queue is not empty, indicating that there is a call request waiting for response, the chip 101 may dequeue the data (i.e., the data DA 2) stored first in the queue and generate a prompt signal according to the data DA2 to remind the user that the incoming call CC2 (or the call request CR 2) is waiting for response. That is, the chip 101 may check whether the data DA2 is still stored in the chip 101. When it is checked that the data DA2 is still stored in the chip 101, the chip 101 may dequeue the data DA2 from the chip 101 and generate the hint signal according to the dequeued data DA 2. In this embodiment, the chip 101 may enable the headset 100 to broadcast the phone number of the incoming call CC2 according to the data DA 2. In some embodiments, chip 101 may cause headset 100 to announce the phone number of incoming call CC2 with a low volume to reduce the impact on the current call.

The chip 101 may then receive user input CIN1 (such as double-clicking or single-clicking the user interface of the chip 101) for accepting a call request corresponding to a data dequeued from the chip 101. The chip 101 may send a control signal (such as an AT command) to the mobile phone sending the call request according to the user input CIN1, so as to answer the incoming call corresponding to the call request. In this embodiment, the data DA2 dequeued from the chip 101 corresponds to the call request CR2 sent by the handset 102.2, not by the handset 102.1 in the call. Thus, the chip 101 may disconnect the voice link CLX1 between the chip 101 and the cell phone 102.1 and establish the voice link CLX2 between the chip 101 and the cell phone 102.2 to allow the chip 101 to answer the incoming call CC2 of the cell phone 102.2. For example, the chip 101 may send a control signal (message 522) to the handset 102.1 to hold the incoming call CC1 of the handset 102.1. The chip 101 may also send another control signal (information 524) to the handset 102.2 to answer the incoming call CC2 of the handset 102.2.

In this embodiment, the chip 101 may send information 522 (AT instruction, such as AT + CHLD =2) to the handset 102.1 to control the handset 102.1 to hold the incoming call CC 1. The handset 102.1 may send information 523 (AT command, such as + CIEV (callhold =2) defined by the AT command set) to the chip 101 to inform the chip 101 that the incoming call CC1 of the handset 102.1 is held. In addition, chip 101 may send information 524 (AT command, such as AT + ATA defined by the AT command set) to handset 102.2 in preparation for answering the incoming call CC2 of handset 102.2. The handset 102.1 may send information 525 (AT command, such as + CIEV defined by the AT command set) to the chip 101 to inform the chip 101 that the incoming call CC2 of the handset 102.2 has been answered.

In operation 508, the call to the incoming CC2 ends. For example, the user may use the headset 100 to end the call at the incoming call CC2, or the caller at the incoming call CC2 may hang up. The handset 102.2 may send information 526 (AT command, such as + CIEV (call =0) defined by the AT command set) to the chip 101 to inform the chip 101 that the incoming call CC2 of the handset 102.2 has hung up.

In operation 509, chip 101 may check whether the queue is empty (i.e., check whether the stored data corresponding to the call request have all been dequeued). When the queue is checked to be not empty, indicating that there is a call request waiting for response, the chip 101 may dequeue the data DA3 (the data stored first in the queue), and generate a prompt signal according to the data DA3 to remind the user that the incoming call CC3 (or the call request CR 3) is waiting for response. That is, the chip 101 may check whether the data DA3 is still stored in the chip 101. When it is checked that the data DA3 is still stored in the chip 101, the chip 101 may dequeue the data DA3 from the chip 101 and generate the hint signal according to the dequeued data DA 3. In this embodiment, the chip 101 may enable the headset 100 to broadcast the phone number of the incoming call CC3 according to the data DA 3. In some embodiments, chip 101 may cause headset 100 to announce the phone number of incoming call CC3 at a low volume to reduce the impact on the current call.

The chip 101 may then receive a user input CIN2 (such as a double-click or single-click on the user interface of the chip 101) that rejects a call request corresponding to data dequeued from the chip 101. The chip 101 may send a control signal (such as an AT command) to the mobile phone sending the call request according to the user input CIN2, so as to hang up the incoming call corresponding to the call request. In this embodiment, the dequeued data DA3 corresponds to the call request CR 3. Therefore, if the chip 101 receives the user input CIN2 for rejecting the call request CR3, the chip 101 can send a message 527 (AT command, such as AT + CHUP defined by the AT command set) to the handset 102.3 to prepare to hang up the incoming call CC3 corresponding to the handset 102.3. The handset 102.3 may send information 528 (AT instruction, such as + CIEV (callsetup =0) defined by the AT instruction set) to the chip 101 to inform the chip 101 that the incoming call CC3 of the handset 102.3 has been hung up.

In operation 510, chip 101 may check whether the queue is empty (i.e., check whether the stored data corresponding to the call request has all been dequeued). When the queue is checked to be empty, it indicates that the data stored in the chip 101 corresponding to the call request is dequeued. That is, no call request is waiting for a response. The chip 101 may send a control signal to the handset 102.1 to resume the call on the incoming call CC 1. For example, the chip 101 may check whether the data corresponding to each call request (which includes call access information for the respective call requests) stored in the chip 101 from the multiple handsets 102.1-102.3 has been dequeued. If it is checked that the data corresponding to each of the call requests of the plurality of handsets 102.1-102.3 are dequeued, the chip 101 may send a control signal to the handset 102.1 to resume the call of the incoming call CC 1. That is, when there is a call request still waiting for a response (e.g., the queue of the chip 101 is not empty), the chip 101 may notify the user to preferentially process the incoming call still waiting; when no call request is waiting for a response (e.g., the queue of chip 101 is empty), chip 101 may resume the call on hold.

In this embodiment, the chip 101 may send information 529 (AT instruction, such as AT + CHLD =2 defined by the AT instruction set) to the handset 102.1 in preparation for activating the incoming call CC1 of the handset 102.1. The handset 102.1 may send information 530 (AT command, such as + CIEV (callhold = 0)) to the chip 101 to inform the chip 101 that the incoming call CC1 of the handset 102.1 has been restored.

In some embodiments, when the user answers/hangs up the phone call directly from the terminal device side 12 (such as the plurality of handsets 102.1-102.3), the terminal device side 12 may send information to the chip 101 to synchronize the states of the headset side 10 and the terminal device side 12, thereby providing a control mechanism with rich elasticity. Please refer to fig. 6. Fig. 6 is a schematic information flow diagram of another embodiment of the chip 101 shown in fig. 1 for call management of multiple handsets 102.1-102.3. The flow of information shown in fig. 6 is substantially the same/similar to the flow of information shown in fig. 5, with the primary difference between the two being that fig. 6 includes a state synchronization operation 60.

In the state synchronization operation 60, after the chip 101 stores the data DA3 corresponding to the call request CR3 (operation 505), the user answers the incoming call CC3 at the cell phone 102.3 (user inputs CIN 3). The handset 102.3 may send information 611 (AT instruction, such as + CIEV (callsetup =0) defined by the AT instruction set) to the chip 101 to inform the chip 101 that the incoming call CC3 of the handset 102.3 has been answered. That is, before the incoming call CC 1' is answered yet, the chip 101 may receive a control signal (such as the message 611) from the handset 102.3, wherein the control signal indicates that the incoming call CC3 corresponding to the call request CR3 has been answered. Since the incoming call CC3 is answered, the chip 101 may delete the data DA3 corresponding to the incoming call CC3 in the chip 101, so as to synchronize the states of the earphone end 10 and the terminal device side 12.

In addition, the chip 101 can control the plurality of mobile phones 102.1-102.3 to hang up the incoming call CC 1' and maintain the incoming call CC1 of the mobile phone 102.1 according to the control signal. For example, in operation 601, the chip 101 may stop the phone number announcement of the incoming call CC 1' of the handset 102.1 according to the message 611. Next, the chip 101 may send information 612 (AT instruction, such as AT + CHLD =0 defined by the AT instruction set) to the handset 102.1 to prepare to hang up the incoming call CC 1'. The handset 102.1 sends information 613 (AT command, such as + CIEV (callsetup =0) defined by the AT command set) to the chip 101 to inform the chip 101 that the incoming call CC 1' of the handset 102.1 has been hung up. Chip 101 may also send information 614 (AT instruction, such as AT + CHLD =2 defined by the AT instruction set) to handset 102.1 in preparation for holding incoming call CC 1. The handset 102.1 then sends a message 615 (AT command, such as + CIEV (callhold =0) defined by the AT command set) to the chip 101 to inform the chip 101 that the incoming call CC1 of the handset 102.1 has been held. The voice link CLX1 between the handset 102.1 and the chip 101 may be released and a voice link CLX3 may be established between the handset 102.3 and the chip 101.

In operation 602, the call to the incoming call CC3 ends. For example, the user may use the headset 100 to end the call at the incoming call CC3, or the caller at the incoming call CC3 may hang up. The handset 102.3 may send information 616 (AT command, such as + CIEV (call =0) defined by the AT command set) to the chip 101 to inform the chip 101 that the incoming call CC3 of the handset 102.3 has hung up.

In operation 603, chip 101 may check whether the queue is empty (i.e., check whether the stored data corresponding to the call request has all been dequeued). When the queue is not empty, indicating that there is a call request waiting for response, the chip 101 may dequeue the data (i.e., the data DA 2) stored first in the queue and generate a prompt signal according to the data DA2 to remind the user that the incoming call CC2 (or the call request CR 2) is waiting for response. For example, the chip 101 may dequeue the data DA2 and cause the headset 100 to broadcast the phone number of the incoming call CC2 according to the dequeued data DA 2.

Since the details of the operation of the information flow shown in fig. 6 can be understood by those skilled in the art after reading the description of the relevant paragraphs in fig. 1 to fig. 5, repeated descriptions are omitted here for brevity.

By storing call access information related to one or more call requests sent by a terminal equipment side (such as a mobile phone end) in an audio output device/electronic device (such as an earphone end) used in cooperation with the terminal equipment side, the call management scheme disclosed by the application can directly perform call management on a plurality of incoming calls of the terminal equipment side on the audio output device/electronic device. In addition, the call management scheme disclosed in the present application can perform a simple control input (such as two control inputs corresponding to answering and hang-up) and state synchronization mechanism on the audio output device/electronic device, i.e. can handle answering scheduling between multiple phones of a single-terminal device and multiple phones of multiple-terminal devices, thereby implementing a simplified and flexible control mechanism and improving user experience.

The foregoing description has provided for a simplified summary of features of certain embodiments of the application so that those skilled in the art may more fully understand the various aspects of the application. Those skilled in the art should appreciate that they may readily use the present disclosure as a basis for designing or modifying other processes and structures for carrying out the same purposes and/or achieving the same advantages of the embodiments introduced above. Those skilled in the art should understand that they can still make various changes, substitutions and alterations herein without departing from the spirit and scope of the present application.

Claims

1. A call management method is applied to an audio output device used in cooperation with a terminal device side, and comprises the following steps:

during the first incoming call between the audio output device and one of the N terminal devices on the terminal device side, if a plurality of call requests from the N terminal devices are received, storing a plurality of data respectively corresponding to the plurality of call requests according to the plurality of call requests and a preset storage mode, wherein the plurality of data comprise call access information respectively corresponding to the plurality of call requests; and

and outputting a call control signal according to the stored data and a preset dequeuing mode to enable the audio output device to generate a prompt signal, wherein the prompt signal indicates call access information corresponding to the dequeued data in the data to a user.

2. The call management method according to claim 1, further comprising:

when receiving a call request corresponding to the dequeued data accepted by a user, judging whether the call request corresponding to the dequeued data is sent by the terminal equipment which carries out the first incoming call in the N terminal equipment according to the dequeued data, and accordingly generating a judgment result; and

and receiving a second incoming call of the call request corresponding to the dequeued data according to the judgment result.

3. The call management method according to claim 2, wherein the step of receiving the second incoming call of the call request corresponding to the dequeued data according to the determination result comprises:

and if the judgment result indicates that the call request corresponding to the dequeued data is sent by the terminal equipment which carries out the first incoming call among the N terminal equipment, enabling the audio output device to send a control signal to the terminal equipment which carries out the first incoming call so as to answer the second incoming call of the terminal equipment which carries out the first incoming call.

4. The call management method according to claim 3, wherein the step of receiving the second incoming call of the call request corresponding to the dequeued data according to the determination result further comprises:

and controlling the terminal equipment for carrying out the call of the first incoming call according to the control signal so as to keep the first incoming call.

5. The call management method according to claim 2, wherein the step of receiving the second incoming call of the call request corresponding to the dequeued data according to the determination result comprises:

if the judgment result indicates that the call request corresponding to the dequeued data is sent by another terminal device different from the one terminal device performing the call of the first incoming call among the N terminal devices, disconnecting the voice link between the audio output device and the one terminal device performing the call of the first incoming call, and establishing the voice link between the audio output device and the another terminal device to allow the audio output device to receive the second incoming call of the another terminal device.

6. The call management method according to claim 5, wherein the step of receiving the second incoming call of the call request corresponding to the dequeued data according to the determination result further comprises:

causing the audio output apparatus to transmit a first control signal to the one terminal device that made the call of the first incoming call to hold the first incoming call of the one terminal device that made the call of the first incoming call; and

causing the audio output device to transmit a second control signal to the other terminal equipment to listen to the second incoming call of the other terminal equipment.

7. The call management method according to any one of claims 1 to 6, wherein the call requests are call requests, and the step of storing the data according to the call requests and the preset storage manner comprises:

and storing the data in a queue mode according to the time sequence of receiving the plurality of call requests.

8. A call management method according to any one of claims 1 to 6, wherein the predetermined dequeue mode is dequeue of data stored first.

9. A call management method according to any one of claims 1 to 6, wherein the dequeued data includes call access information including caller identification information; the step of generating the cue signal comprises:

and playing a sound signal for prompting the caller identification information according to the data, wherein the sound signal is used as the prompt signal.

10. The call management method according to claim 1, further comprising:

if a second incoming call of the call request corresponding to the dequeued data is answered, enabling the audio output device to keep the first incoming call; and

and if the call of the second incoming call is finished, the audio output device is enabled to recover the call of the first incoming call.

11. The call management method according to claim 10, further comprising:

checking whether the stored data are dequeued; and

and if the call of the second incoming call is finished and the data are dequeued, the audio output device is enabled to recover to answer the call of the first incoming call.

12. The call management method according to claim 1, further comprising:

before a second incoming call of the call request corresponding to the dequeued data is not answered, if a third incoming call of the call request corresponding to another data different from the dequeued data in the plurality of data is answered by the user on the terminal equipment side, keeping the first incoming call, and deleting the another data in the plurality of data.

13. The call management method according to claim 12, further comprising:

and after the call of the third incoming call answered by the terminal equipment side is finished, enabling the audio output device to answer the second incoming call.

14. The call management method according to claim 12, further comprising:

and hanging up the second incoming call.

15. A chip, applied to an audio output device used in cooperation with a terminal device side, the chip comprising:

a memory for storing program instructions; and

a processor, coupled to the memory, for invoking program instructions stored in the memory to cause the chip to perform the call management method of any of the preceding claims 1 to 14.

16. An audio output device, comprising:

the chip of claim 15.

17. The audio output device of claim 16, wherein the audio output device is a headset.