CN112367648B

CN112367648B - Call management method, chip and audio output device

Info

Publication number: CN112367648B
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: 2024-03-08
Anticipated expiration: 2040-09-29
Also published as: CN112367648A

Abstract

The application discloses a call management method, a chip and an audio output device. The call management method comprises the following steps: during the first incoming call between the audio output device and one of N terminal devices at 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, so that the audio output device generates a prompt signal, and the prompt signal indicates call access information corresponding to dequeued data in the data to a user. The call management method can simplify the control mechanism of multiple call accesses and improve the user experience.

Description

Call management method, chip and audio output device

Technical Field

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

Background

With the wider and wider application of wireless bluetooth headsets, a user may have multiple terminal devices (such as a mobile phone, a tablet or a vehicle-mounted terminal), and even a user may have multiple mobile phones that all can be used with the headsets, so that the use scenarios are also more and more diversified. For example, in an application scenario where a user connects a plurality of terminal devices using the same bluetooth headset, when the user is talking with one terminal device (such as a mobile phone) using the bluetooth headset, the terminal device currently talking may have another phone access, and other terminal devices connected to the bluetooth headset may also have a phone incoming at the same time. However, the existing bluetooth headset does not support such a complicated application scenario. The user needs to answer or switch at each terminal device to which the phone is connected. That is, all call answering controls need to be operated on the terminal device, for example, the terminal device is sometimes located at a distance from the user or the terminal device is placed in a pocket, so that the user is inconvenient to operate a plurality of terminal devices, which causes inconvenience to the user in use. In addition, the number of handsets that existing bluetooth handsets can connect to is limited. Therefore, in the above application scenario, when the voice data connection between the headset terminal (bluetooth headset) and the terminal device fails to be created due to the headset terminal connection limitation, voice data can only be input/output from the terminal device, resulting in poor user experience.

Disclosure of Invention

One of the purposes of the present application is to disclose a method for managing a plurality of calls of one or more terminal devices in an audio output device used with the terminal devices, and related chips and audio output devices, 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, and comprises the following steps: during a first incoming call session between the audio output device and one of 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 corresponding to the plurality of call requests respectively according to the plurality of call requests and a preset storage mode, wherein the plurality of data includes call access information corresponding to the plurality of call requests respectively; and outputting a call control signal according to the stored data and a preset dequeuing mode, so that the audio output device generates a prompt signal, and the prompt signal indicates call access information corresponding to dequeued data in the data to a user.

Certain embodiments of the present application disclose a chip for use with an audio output device for use with a terminal device side. The chip includes a memory and a processor. The memory is used for storing program instructions. The processor is coupled to the memory, and is configured to invoke the program instructions stored in the memory, so that the chip executes the call management method.

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

According to the call management method and the related chip and the audio output device, the plurality of calls can be managed directly at the earphone end, and the control mechanism of the plurality of call accesses can be simplified through a simple mechanism of synchronizing control input (such as two control inputs corresponding to answering and hanging up) with the state, so that the user experience is improved.

Drawings

Fig. 1 is a schematic diagram of an embodiment of the present application applied to a tone frequency output device used with a terminal device to manage a plurality of call accesses.

Fig. 2 is a flow chart 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 an information flow diagram of an embodiment of the headset shown in fig. 1 for performing call management on a plurality of handsets.

Fig. 6 is an information flow diagram of another embodiment of the headset shown in fig. 1 for performing call management on a plurality of handsets.

Detailed Description

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

The call management scheme disclosed in the application can be directly used for managing a plurality of calls at the earphone end, or can be used for other electronic devices (or audio output devices (audio output device)) matched with the terminal equipment side (terminal device side) to manage a plurality of calls, and the call maintenance and the answering are not required to be carried out 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 performing call management on 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) on the earphone end, so that call holding and answering of multiple connection scenes can be processed, and a control mechanism of complex call scenes is further simplified.

For example, the call management scheme disclosed in the present application may directly perform simple control input at the earphone end by storing call access information (which may indicate terminal equipment and caller identification information corresponding to each call request) related to a plurality of call requests at the earphone end (such as a wireless earphone used with one or more terminal equipments at the terminal equipment side), so as to manage a plurality of calls at the dial-in terminal equipment side.

In addition, the call management scheme disclosed in the application can store call access information related to a plurality of call requests in a queue mode. Therefore, even if the number of terminal devices required to be connected with the earphone end exceeds the maximum number supported by a wireless communication protocol (such as a Bluetooth communication protocol), the call management scheme disclosed by the application can ensure that the voice link can be successfully established between the earphone end and the terminal device required to be connected with voice data by storing call access information corresponding to the terminal device which is not currently connected with the call and disconnecting the voice link between the earphone end and the terminal device which is not currently connected with the call, thereby solving the problem that the voice data can only be input/output from the terminal device due to the connection limitation of the earphone end. Furthermore, when the user directly operates on the terminal device to answer the appointed call, the call management scheme disclosed by the application can perform state synchronization on the earphone end and the call being answered, and update call access information stored by the earphone end.

Therefore, under a complex call scene, the call management scheme disclosed by the application can process a plurality of call accesses by utilizing a simple mechanism of controlling input and state synchronization of the earphone end, and complex input control is not required to be carried out on the earphone end, so that user experience is improved. Further description is as follows.

Fig. 1 is a schematic diagram of an embodiment of the present application for managing multiple call accesses by audio output devices used with a terminal device. In this embodiment, the audio output device for call management may 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 type of wireless headset, so the audio output device for call management may be considered to be located at the headset end 10. One or more terminal devices located on 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 possible to implement the audio output device for call management using other types of wireless audio output devices or other electronic devices used with the terminal device side 12. For example, in some embodiments, the audio output device for call management may be implemented by a Bluetooth speaker or Bluetooth watch. In addition, at least one of the terminal devices on the terminal device side 12 may be implemented by a tablet computer, a vehicle-mounted terminal, or other type of terminal device, such as other portable terminal devices that may support voice call functionality and/or video call functionality.

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

In this embodiment, the headset 100 may include a chip 101 that may manage a plurality of phones accessed by the terminal device side 12. In this embodiment, the chip 101 may manage a 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 flow chart 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 explanation, the following describes an embodiment of the headset 100/chip 101 shown in fig. 1 for managing a plurality of telephones accessed by the terminal device side 12 in conjunction with the call management method 20 shown in fig. 2. However, the present application is not limited thereto. In some embodiments, call management method 20 may also include other steps. The headset 100/chip 101 of fig. 1 may employ alternative embodiments based on the call management method 20 of fig. 2 without departing from the spirit and scope of the present application.

In addition, for the convenience of understanding the call management scheme disclosed in the present application, the following description of "receiving a call request" may mean that the chip 101 (or the earphone end 10) receives a call request sent from the terminal device side 12. The "accept call request" described below may indicate that the user inputs an external trigger event, so that the chip 101 sends a control signal or instruction to the terminal device side 12 to prepare to answer the call corresponding to the call request. The "answering an incoming call" described below may mean establishing a voice link between the chip 101 and the terminal device side 12 to allow a party making a call to communicate with a user.

In step 26, during a first incoming call between the headset 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 corresponding to the plurality of call requests are stored according to the plurality of call requests and a preset storage manner, wherein the plurality of data includes call access information corresponding to the plurality of call requests.

For example, the mobile phone 102.1 may send a call request CR1 to the earphone 100 according to the incoming call CC1. When the chip 101 receives the information that the user accepts the call request CR1 (i.e., allows to answer the incoming call 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 instruction to the mobile phone 102.1 through the wireless link CL1 between the headset 100 and the mobile phone 102.1, so that a voice link is established between the headset 100 and the mobile phone 102.1, so as to answer the incoming call CC1 corresponding to the call request CR 1. In some embodiments where a wireless link is established according to the bluetooth communication protocol between the headset 100 and the handset 102.1, the voice link may be a connection-oriented synchronization link (synchronous connection oriented link, SCO link) or a connection-oriented extended synchronization link (extended synchronous connection oriented link, eSCO link).

Next, during the conversation between the earphone 100 and the mobile phone 102.1, the chip 101 may receive a plurality of conversation requests corresponding to a plurality of other incoming calls (e.g., one or more incoming calls) from the terminal device side 12, and store a plurality of corresponding 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 handsets other than the handset 102.1 of the N handsets 102.1-102. N.

For example, during a call between the earphone 100 and the mobile phone 102.1, when the mobile phone 102.1 receives another incoming call CC1', the mobile phone 102.1 can 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 a data DA1' according to the call request CR1' and a 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 mobile phone 102.1 sending the call request CR1' and caller identification information (such as a caller phone number) of the caller CC1 '. For another example, during a call between the headset 100 and the mobile phone 102.1, the mobile phone 102.2 receives a call CC2 and sends a call request CR2 to the chip 101. If the chip 101 receives the call request CR2, the chip 101 may store a data DA2 according to the call request CR2 and a predetermined storage manner, where the data DA2 includes call access information corresponding to the call request CR2, which may indicate (but is not limited to) the mobile phone 102.2 sending the call request CR2 and caller identification information (such as a caller phone number) of the caller CC 2. For another example, during the call between the earphone 100 and the mobile phone 102.1, if the chip 101 receives a plurality of call requests (such as the call request CR1 'and the call request CR 2), the chip 101 may store a plurality of related data (such as the data DA1' and the data DA 2) according to the plurality of call requests and the preset storage manner.

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

For example, during the call of the incoming call CC1, the call request received by the chip 101 is a call request CR1 'corresponding to another incoming call CC1' dialed to the mobile phone 102.1. The chip 101 can output a communication control signal according to the data DA1' and a predetermined dequeue manner, so that the earphone 100 generates a prompting signal RS1, which can indicate the call access information (such as the phone number of the incoming call CC1 ') corresponding to the dequeue data DA1' to the user. The communication control signal may cause a reminder signal generating circuit (such as an audio output circuit; not shown in fig. 1) of the headset 100 to generate a reminder signal RS1. 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 mobile 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 earphone 100 generates a prompting 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 reminder signal generating circuit (such as an audio output circuit; not shown in fig. 1) of the headset 100 to generate a reminder signal RS2. For another example, during the call between the earphone 100 and the mobile phone 102.1 in the line of 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 may output the communication control signal according to a plurality of data (corresponding to the plurality of call requests respectively) including the data DA1' and the data DA2 and a preset dequeue manner, so that the earphone 100 generates a prompt signal, which may indicate to the user call access information corresponding to 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 for prompting the caller identification information according to the dequeue data in step 28 as the prompting signal. For example, the earphone 100 may broadcast the phone number of the incoming call CC1'/CC2 according to the data DA1'/DA2, wherein the sound signal of the incoming call number is broadcast as the prompt signal RS1/RS2. In this way, the user can judge whether to hang up or keep the current incoming call CC1 to answer the incoming call CC1'/CC2 according to the incoming call number broadcasted by the prompt signal RS1/RS2.

In some embodiments, the preset storage mode of step 26 may be a queue storage mode, 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 mode according to the time sequence of receiving the call request CR1' and the call request CR2.

In some embodiments, the predetermined dequeuing mode of step 28 may be a first-in-first dequeuing of data stored first. Therefore, in the case that the chip 101 sequentially stores the data DA1 'and the data DA2 during the call of the incoming call CC1, the chip 101 can make the earphone 100 generate the prompting signal RS1 first, so that the user responds to the call request CR1' sent earlier preferentially. In the case that the chip 101 sequentially stores the data DA2 and the data DA1' during the call of the incoming call CC1, the chip 101 may make the earphone 100 generate the prompting signal RS2 first, so that the user responds to the call request CR2 sent earlier preferentially.

For example, the chip 101 may use a first-in-first-out (first-in-first-out) queue to store data corresponding to each call request. The earphone 100 can generate a corresponding prompt signal according to the dequeued data. Since the first-in data can be first-out, the headset 100 can preferentially generate alert signals for earlier dialing into N phones 102.1-102. N. Because the earphone 100 may employ a fifo queue to buffer data corresponding to the call requests, respectively, the first-in data (corresponding to the first-in N phones 102.1-102.N phones) may be first dequeued, so that the user may preferentially respond to the call request sent earlier.

Fig. 3 and 4 are schematic diagrams of certain embodiments of a memory operation of the chip 101 shown in fig. 1. For convenience of explanation, the storage operation shown in fig. 3 and 4 is performed based on the scenario (i.e., n=4) in which the chip 101 shown in fig. 1 performs call management on the plurality of handsets 102.1-102.4. In the embodiment shown in fig. 3 and 4, the chip 101 may use a queue 105 (such as a fifo queue) to store data corresponding to each call request, where the fifo queue 105 may be implemented by software or hardware. The queue 105 may perform a store operation according to the chronological order in which the chip 101 received the call requests.

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

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

In this embodiment, the data CDA may dequeue the queue 105 when another incoming call CC1' is received by the currently communicating handset 102.1 or other handsets connected to the headset 100. For example, during a call of incoming call CC1, chip 101 may check whether queue 105 stores data corresponding to each of any call requests from the plurality of handsets 102.1-102.4. When the check queue 105 stores data corresponding to at least one call request from the plurality of handsets 102.1-102.4, the chip 101 can push the data that first enters the queue 105 out of the queue 105, and generate a prompting 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 cause the earphone 100 to report the phone number of the incoming call CC1' according to the data DA 1'. The user may decide whether to answer or hang up the incoming call CC1'. It should be noted that the chip 101 may enable the earphone 100 to broadcast the phone number of the incoming call CC1' at a low volume, so as to reduce the influence on the current call.

In some embodiments, the chip 101 may dequeue the queue 105 when the currently talking handset 102.1 ends the talking. For example, when the call of the incoming call CC1 ends, the chip 101 may check whether several data (corresponding to several call requests, respectively) stored in the queue 105 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 can dequeue the data that first enters the queue 105, and generate a prompt signal according to the dequeued data, so as to indicate the call access information of the 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 CC1' is answered), the chip 101 may check that the data DA2 is the data that first enters the queue 105, so as to push out the data DA2, so that the earphone 100 broadcasts the phone number of the incoming call CC 2.

In some embodiments, data stored in the 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 CR1', the call request CR2, and the call request CR4 in order. Thus, chip 101 may sequentially push corresponding data DA3, data DA1', data DA2, and data DA4 into queue 105. When the party dialing the mobile phone 102.2 actively hangs up the call or the user directly operates on the mobile phone 102.2 to refuse to answer the incoming call CC2, the mobile phone 102.2 may send a related control signal or instruction 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 side 10 (such as data stored in the chip 101) can be synchronized with the state of the terminal device side 12. Thus, the chip 101 may allow an external triggering event (such as a party actively hanging up a call, or a user handling an incoming call directly at the terminal device side 12) to change the call state, thereby providing a resilient control mechanism.

The above-described incoming call access sequence for the N handsets 102.1-102.N is for convenience of description 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 may be applied to an application scenario in which, while the mobile phone 102.I (i is a positive integer from 1 to N) shown in fig. 1 is making a call, there are other calls dialed into N mobile phones 102.1-102. N.

It should be noted that, by storing the call access information (which may indicate the mobile phone 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, the user can directly process a complex call application scenario at the earphone end 10 by using a 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. Memory 110 may be used to store program instructions. The processor 120 is coupled to the memory 110 and is operable to invoke program instructions stored in the memory 110 to cause the chip 101 to execute the call management scheme disclosed herein, such as the call management method 20 shown in fig. 2. For example, the memory 110 may be further configured to store a plurality of data corresponding to a plurality of call requests from the N handsets 102.1-102.N, and the processor 120 may invoke the program instructions stored in the memory 110, so that the chip 101 may output the call control signal CS0 according to the plurality of 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 earphone 100 may generate an alert signal (such as alert signals RS1/RS 2) according to the call control signal CS0.

In addition, the chip 101 may perform call management such as answering an incoming call, holding a call, hanging up a phone 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 is not limited to, a physical key, a virtual key, or a touch screen. When the user receives the prompt signal, the user can perform a simple control operation (such as a single click, a double click, a long press) on the user interface of the earphone 100. The processor 120 may invoke 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 phone 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 several data corresponding to several call requests, respectively. For example, the memory 110 may include a queue storage structure implemented in a software implementation or a hardware implementation, 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 because the first-in data may be dequeued first-out.

In some embodiments, if the user actively answers/hangs up the call at the terminal device side 12, the terminal device side 12 may send information to the earphone side 10, so that the states of the earphone side 10 and the terminal device side 12 are synchronized.

For example (but not limited to this in the application), during the conversation between the earphone 100 and the mobile phone 102.1, the incoming call CC1 'and the incoming call CC2 are dialed to the terminal device side 12 in sequence, so that the chip 101 can receive the conversation request CR1' sent by the mobile phone 102.1 and the conversation request CR2 sent by the mobile phone 102.2 in sequence, wherein the data DA1 'corresponding to the incoming call CC1' 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 call CC1' is answered, if the call CC2 is answered by the user at the terminal device side 12, the chip 101 may keep the call CC1 and delete the data DA2 corresponding to the call CC 2. For example, when the user directly operates on the mobile phone 102.2 to answer the incoming call CC2, the mobile phone 102.2 may 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 mobile phone 102.1 to maintain the incoming call CC1. That is, when the user actively answers the call at the terminal device side 12, the earphone end 10 may synchronize the state of the earphone end 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 from the terminal device side 12.

In addition, after the call of the incoming call CC2 is ended, the chip 101 may enable the earphone 100 to answer the incoming call CC1' dialed to the terminal device side 12 earlier than the incoming call CC 2. Thus, the incoming call CC1' dialed earlier can still be answered. It should be noted that, in some embodiments, if the incoming call CC2 is received by the user at the terminal device side 12 before the incoming call CC1 'has not been received, the chip 101 may hang up the incoming call CC1' except for maintaining the incoming call CC1 and deleting the data DA2 corresponding to the incoming call CC 2. Therefore, the situation that the caller of the incoming call CC1' waits too long because the incoming call CC2 is answered can be avoided.

Similarly, before the incoming call CC1' has not been answered, if the incoming call CC2 is hung up by the user at the terminal device side 12, the earphone end 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 earphone end 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 at the terminal equipment side by utilizing simple control input at the earphone side, but also can allow a user to directly process the accessed call at the terminal equipment side in a state synchronization mode, thereby providing a simplified and elastic control mechanism.

The circuit configuration of the chip 101 is for illustrative purposes only and is not intended to limit the scope of the present application. As long as the earphone end 10 can store the call request sent by the terminal device side and manage the plurality of call accesses by the terminal device side, it is possible to implement the chip 101 by adopting other circuit configurations.

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 herein. 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 call management for a plurality of handsets 102.1-102.3 (i.e., n=3) by the headset 100 shown in fig. 1. In this embodiment, the headset 100 may be implemented as a Bluetooth headset. Corresponding wireless links (i.e., one of the plurality of wireless links CL1-CL 3) are established between the chip 101 and the plurality of handsets 102.1-102.3 according to a bluetooth communication protocol, respectively, including an asynchronous connectionless link and a hands-free specification link. The identification code (or serial number) of the headset 100 may be notified to the plurality of handsets 102.1-102.3. Thus, when a call is placed to one of the plurality of handsets 102.1-102.3, the handset may send an AT command (attention command, AT command) to the chip 101 according to the bluetooth communication protocol, thereby sending the telephone number dialed into the handset to the chip 101.

In this embodiment, the chip 101 first establishes a voice link CLX1 (i.e., connection-oriented synchronous link/connection-oriented extended synchronous 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 CR1' sent by the mobile phone 102.1, the call request CR2 sent by the mobile phone 102.2, and the call request CR3 sent by the mobile phone 102.3 in sequence. However, those skilled in the art will appreciate that this is for convenience of illustration only and is not intended to limit the scope of the present application.

First, when the mobile phone 102.1 has an incoming call CC1 accessed, the mobile phone 102.1 may send a call request CR1 (such as +ciev (callsetup=1) defined by AT instruction set) to the chip 101 according to the bluetooth communication protocol to inform the chip 101 that the incoming call CC1 has accessed the mobile phone 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. In addition, a voice link CLX1 (i.e., a connection-oriented synchronous link/a connection-oriented extended synchronous link) may be established between the chip 101 and the handset 102.1.

Then, during the call of the incoming call CC1, the mobile phone 102.1 has another incoming call CC1' connected. The handset 102.1 may send information 511 (AT instructions, such as +ccwa defined by the AT instruction 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 been connected to the handset 102.1 and is waiting for a reply, and send the phone number from the incoming call CC1' to the chip 101. In operation 502, the chip 101 may push the data DA1 'corresponding to the call request CR1' to a queue (e.g. the queue 105 shown in fig. 3/4), wherein the data DA1 'may identify the incoming call CC1' to access the mobile 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 been dequeued). When the queue is checked to be not empty, it indicates that a call request is waiting for a 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 DA1', so as to remind the user that the incoming call CC1 '(or the call request CR 1') is waiting for a response. That is, the chip 101 may check whether the data DA1' 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 earphone 100 to report the phone number of the incoming call CC1 'according to the dequeued data DA 1'. In some embodiments, the chip 101 may cause the earphone 100 to broadcast the phone number of the incoming call CC1' at a low volume to reduce the impact on the current call.

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

In this embodiment, when an incoming call corresponding to a call request different from the call request CR1 is received, the chip 101 can control the mobile phone 102.1 to keep the incoming call CC1. When the call of the received call is ended, the chip 101 may send a control signal (such as an AT command) to the mobile phone 102.1 to resume the call of the received call CC1. For example, after data DA3 is stored in the queue 310 of chip 101, chip 101 may receive a user input CIN1 (such as a double-click or single-click user interface of chip 101) for accepting a call request corresponding to a data dequeued from chip 101. The chip 101 may transmit a control signal (such as an AT command) to a mobile phone transmitting the call request according to the user input CIN1 to answer an 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 mobile phone 102.1 to resume the call of the incoming call CC1.

It should be noted that, if the chip 101 receives the user input CIN1 for accepting the call request, the chip 101 may determine whether the call request is sent by the mobile phone that is talking according to the dequeue data, and generate a determination result accordingly. 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 mobile phone that is being called, since the voice link is already established between the chip 101 and the mobile phone that is being called, the chip 101 can 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 that is being used for the call, the chip 101 may disconnect the voice link between the chip 101 and the mobile phone that is being used for the call, and establish the voice link between the chip 101 and the other mobile phone, so as 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 dequeued data DA1' from the chip 101 is sent by the mobile phone 102.1 in the call, the chip 101 can send a control signal (information 517) to the mobile phone 102.1 to answer the incoming call CC1 '(corresponding to the call request CR 1') of the mobile phone 102.1. Furthermore, in some embodiments, the chip 101 may send the control signal to the mobile phone 102.1 to hold the original call of the mobile phone 102.1 (i.e., hold the incoming call CC 1'). For example, the chip 101 may send information 517 (AT instructions, such as at+chld=2 defined by the AT instruction 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 instructions, such as +ciev (callsetup=0, callhold=1) defined by the AT instruction set) to the chip 101 to indicate that the handset 102.1 has answered the second incoming call (incoming call CC 1') and held the first incoming call (incoming call CC 1). The voice link CLX1 between the chip 101 and the handset 102.1 switches to the call of the incoming call CC 1'.

In operation 506, the call of incoming call CC1' ends. For example, the user ends the call of the incoming call CC1 'using the earphone 100, or the caller of the incoming call CC1' hangs up. The handset 102.1 may send information 519 (AT instructions, such as + CIEV (callheld=2) defined by the AT instruction 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 information 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 is switched to the call of the incoming call CC1.

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 has been dequeued). When the queue is checked to be not empty, it indicates that a call request is waiting for a 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, so as to remind the user that the incoming call CC2 (or the call request CR 2) is waiting for a 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 can enable the earphone 100 to broadcast the phone number of the incoming call CC2 according to the data DA 2. In some embodiments, the chip 101 may cause the earphone 100 to low volume broadcast the phone number of the incoming call CC2 to reduce the impact on the current call.

The chip 101 may then receive user input CIN1 (such as a double-click or single-click on a user interface of the chip 101) for accepting a call request corresponding to a data dequeued from the chip 101. The chip 101 may transmit a control signal (such as an AT command) to a mobile phone transmitting the call request according to the user input CIN1 to answer an incoming call corresponding to the call request. In this embodiment, the call request CR2 corresponding to the data DA2 dequeued from the chip 101 is 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 handset 102.1 and establish the voice link CLX2 between the chip 101 and the handset 102.2 to allow the chip 101 to answer the incoming call CC2 of the handset 102.2. For example, the chip 101 may send a control signal (information 522) to the mobile phone 102.1 to maintain the incoming call CC1 of the mobile phone 102.1. The chip 101 may also send another control signal (information 524) to the mobile phone 102.2 to answer the incoming call CC2 of the mobile phone 102.2.

In this embodiment, the chip 101 may send information 522 (AT instruction, such as at+chld=2) to the cell phone 102.1 to control the cell phone 102.1 to hold the incoming call CC1. The handset 102.1 may send a message 523 (AT instruction, such as +ciev (callheld=2) defined by the AT instruction set) to the chip 101 to inform the chip 101 that the incoming call CC1 of the handset 102.1 is held. In addition, the chip 101 may send information 524 (AT instruction, such as at+ata defined by the AT instruction set) to the cell phone 102.2 in preparation for answering the incoming call CC2 of the cell phone 102.2. The handset 102.1 may send information 525 (AT instructions, such as +ciev (call=1, call setup=0) defined by the AT instruction 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 of incoming CC2 ends. For example, the user ends the call of the incoming call CC2 using the earphone 100, or the caller of the incoming call CC2 hangs up. The handset 102.2 may send a message 526 (AT instruction, such as + CIEV (call=0) defined by the AT instruction set) to the chip 101 to inform the chip 101 that the incoming call CC2 of the handset 102.2 has been hung up.

In operation 509, the chip 101 may check whether the queue is empty (i.e., check whether the stored data corresponding to the call request has been dequeued). When the queue is checked to be not empty, it indicates that a call request is waiting for a response, the chip 101 may dequeue the data DA3 (the data stored in the queue first), and generate a prompt signal according to the data DA3, so as to remind the user that the incoming call CC3 (or the call request CR 3) is waiting for a 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 can enable the earphone 100 to broadcast the phone number of the incoming call CC3 according to the data DA 3. In some embodiments, the chip 101 may cause the earphone 100 to broadcast the phone number of the incoming call CC3 at a low volume to reduce the impact on the current call.

The chip 101 may then receive user input CIN2 (such as a double-click or single-click on the user interface of the chip 101) that is used to reject 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 CIN2, so as to hang up the incoming call corresponding to the call request. In this embodiment, dequeued data DA3 corresponds to call request CR3. Thus, if the chip 101 receives user input CIN2 to reject the call request CR3, the chip 101 may send information 527 (AT instructions, such as AT+CHUP defined by the AT instruction 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 instructions, 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, the chip 101 may check whether the queue is empty (i.e., check whether the stored data corresponding to the call request has been dequeued). When the queue is checked to be empty, it indicates that all the data stored in the chip 101 corresponding to the call request has been dequeued. That is, no call request is waiting for a response. The chip 101 may send a control signal to the mobile phone 102.1 to resume answering the call of the incoming call CC 1. For example, the chip 101 may check whether data corresponding to each call request (which includes call access information for the corresponding call request) from the plurality of handsets 102.1-102.3 stored in the chip 101 has been dequeued. If it is checked that the data corresponding to each call request of the plurality of handsets 102.1-102.3 has been dequeued, the chip 101 may send a control signal to the handset 102.1 to resume answering 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 incoming calls 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 in hold.

In this embodiment, the chip 101 may send information 529 (AT instructions, 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 instruction, 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 a user picks up/hangs up a phone directly from the terminal device side 12 (such as a 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 earphone side 10 and the terminal device side 12, thereby providing a resilient control mechanism. 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 performing call management on a plurality of handsets 102.1-102.3. The information flow shown in fig. 6 is substantially the same/similar to the information flow shown in fig. 5, the main 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 mobile phone 102.3 (user input CIN 3). The handset 102.3 may send a message 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 CC1' has not been answered, the chip 101 may receive a control signal (such as information 611) from the mobile phone 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 has been answered, the chip 101 may delete the data DA3 corresponding to the incoming call CC3 in the chip 101, so that the states of the earphone end 10 and the terminal device side 12 are synchronized.

In addition, the chip 101 can control the plurality of handsets 102.1-102.3 to hang up the incoming call CC1' and hold the incoming call CC1 of the handset 102.1 according to the control signal. For example, in operation 601, the chip 101 can stop the phone number broadcast of the incoming call CC1' of the mobile phone 102.1 according to the information 611. The chip 101 may then send information 612 (AT instruction, such as at+chld=0 defined by the AT instruction set) to the handset 102.1 in preparation for hanging up the incoming call CC1'. The handset 102.1 sends information 613 (AT instructions, such as + CIEV (callsetup=0) defined by the AT instruction set) to the chip 101 to inform the chip 101 that the incoming call CC1' 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 CC1. The handset 102.1 then sends information 615 (AT instructions, such as +ciev (callheld=0) defined by the AT instruction 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 the voice link CLX3 may be established between the handset 102.3 and the chip 101.

In operation 602, the call of the incoming call CC3 ends. For example, the user ends the call of the incoming call CC3 using the earphone 100, or the caller of the incoming call CC3 hangs up. The handset 102.3 may send information 616 (AT instructions, such as + CIEV (call=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 hung up.

In operation 603, the chip 101 may check whether the queue is empty (i.e., check whether the stored data corresponding to the call request has been dequeued). When the queue is checked to be not empty, it indicates that a call request is waiting for a 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, so as to remind the user that the incoming call CC2 (or the call request CR 2) is waiting for a response. For example, the chip 101 may dequeue the data DA2 and cause the earphone 100 to broadcast the phone number of the incoming call CC2 according to the dequeued data DA 2.

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

By storing call access information related to one or more call requests sent by a terminal device side (such as a mobile phone side) in an audio output device/electronic device (such as a headset side) used with the terminal device side, the call management scheme disclosed in the application can directly perform call management on a plurality of calls of the terminal device side on the audio output device/electronic device. In addition, the call management scheme disclosed by the application can perform a mechanism of synchronizing simple control input (such as two control inputs corresponding to answering and hanging up) and state on the audio output device/electronic device, namely, can process answering scheduling between a plurality of telephones of single terminal equipment and a plurality of telephones of multi-terminal equipment, thereby realizing a simplified and elastic control mechanism and improving user experience.

The foregoing description briefly sets forth features of certain embodiments of the present application so that those skilled in the art may more fully understand the several aspects of the present application. Those skilled in the art should appreciate that they may readily use the present application 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 described herein. Those skilled in the art should understand that they can make various changes, substitutions and alterations herein without departing from the spirit and scope of the present application.

Claims

1. A call management method, which is applied to an audio output device used with a terminal device side, the call management method comprising:

during a first incoming call session between the audio output device and one of 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 corresponding to the plurality of call requests respectively according to the plurality of call requests and a preset storage mode, wherein the plurality of data includes call access information corresponding to the plurality of call requests respectively; and

And outputting call control signals according to the stored data and a preset dequeue mode, so that the audio output device generates prompt signals according to dequeue data in the data, and the prompt signals indicate call access information corresponding to dequeue data in the data to a user, wherein if first data different from dequeue data in the data are dequeued from the data, the first data are dequeued from the data after call requests corresponding to the prompt signals corresponding to dequeue data are responded.

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

when receiving a call request corresponding to the dequeue data received by a user, judging whether the call request corresponding to the dequeue data is sent by one of the N terminal devices for making the call of the first incoming call according to the dequeue data, and generating a judging result according to the judging result; and

and answering a second incoming call of the call request corresponding to the dequeue data according to the judging result.

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

if the judging result indicates that the call request corresponding to the dequeue data is sent by one of the N terminal devices for making the call of the first call, the audio output device sends a control signal to the one terminal device for making the call of the first call so as to answer the second call of the one terminal device for making the call of the first call.

4. The call management method as claimed in claim 3, wherein the step of answering 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 as claimed in claim 2, wherein the step of answering the second incoming call of the call request corresponding to the dequeued data according to the determination result comprises:

If the judging result indicates that the call request corresponding to the dequeue data is sent by another terminal device different from the one terminal device which carries out the call of the first incoming call in the N terminal devices, disconnecting a voice link between the audio output device and the one terminal device which carries out the call of the first incoming call, and establishing the voice link between the audio output device and the other terminal device so as to allow the audio output device to answer the second incoming call of the other terminal device.

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

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

and enabling the audio output device to send a second control signal to the other terminal equipment so as to answer 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 plurality of call requests are a plurality of call requests, and the step of storing the plurality of data according to the plurality of call requests and the preset storage means comprises:

the plurality of data is stored in a queue in a time sequence in which the plurality of call requests are received.

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

9. The call management method according to any one of claims 1 to 6, wherein the dequeue 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 dequeue data, wherein the sound signal is used as the prompting signal.

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

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

and if the call of the second incoming call is ended, enabling the audio output device to resume answering 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

if the call of the second incoming call is ended and the plurality of data are dequeued, the audio output device resumes answering the call of the first incoming call.

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

before a second call of the call request corresponding to the dequeue data is not answered, if a third call of the call request corresponding to the second data different from the dequeue data in the plurality of data is answered by the user at the terminal device side, the first call is kept, and the second data in the plurality of data is deleted.

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 ended, enabling the audio output device to answer the second incoming call.

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

hanging up the second incoming call.

15. A chip, characterized in that it is applied to an audio output device used 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 claims 1-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.