The invention relates to a hearing device comprising an interface for wireless communication with external devices.

Devices communicating with each other via a wireless interface typically establish a mutual trusted relationship through the exchange of cryptographic material once they connect to each other for the first time with the cryptographic material (key material) being stored persistently on both devices in so-called pairing tables in order to facilitate the establishment of subsequent private connections. Hearing devices, such as hearing aids, having a wireless interface may connect (and consequently pair) with a plurality of external devices, such as smartphones, remote controls or servicing devices which assist configuration, repair or service of the hearing device. Hearing devices are typically small battery-powered devices which have a limited user interface and are limited in computational power and storage capacity.

A simple way of maintaining a limited pairing table is to let new pairings override existing entries once there is no space left for additional entries.

US 8,990,438 B2 relates to a system comprising a portable computer and multiple wireless human interface devices. While typically the use of human interface devices involves that an individual wireless USB dongle has to be plugged into the portable computer for each of the human interface devices, thereby using up all available USB ports of the portable computer, US 8,990,438 B2 proposes to overcome this problem by a single dongle which pairs with multiple human interface devices and yet stores multiple pairing entries for that unifying dongle.

US 8,224,004 B2 relates to a hearing system comprising a hearing device and a remote control, wherein the hearing device and the remote control may automatically pair once they are closer than a predetermined distance, and wherein the remote control may recognize the type of hearing device from a look-up table so as to automatically control a hearing device application program selection.

US 2013/0095753 A1 relates to a peer-to-peer device pairing method using a Bluetooth protocol, wherein the pairing information for a certain paired device is deleted from the memory of the counterpart paired device once that device runs short of memory space, unless the pairing information is protected by request. It is an object of the invention to provide for a wireless hearing device which is capable of handling connectivity to a plurality of external devices in a manner which does not require ample resources of the hearing device but nevertheless is user friendly. It is a further object to provide for a corresponding method of operating a wireless hearing device. According to the invention, these objects are achieved by a hearing device as defined in claim 1 and a method as defined in claim 21 , respectively.

The invention is beneficial in that, by providing a plurality of pairing tables, wherein the pairing control unit is configured to decide in which one of the pairing tables a new pairing information entry is to be persistently stored, with the decision being based on target pairing table selection information provided to the pairing control unit during the pairing process, the hearing device is enabled to prioritize a certain pairing over other pairings. For example, one of the pairing tables may be assigned to end-user initiated pairings, while another one of the pairing tables may be associated with service-provider initiated pairings, so that, for example, a new service-provider initiated pairing may be prevented from overwriting a previous end-user initiated pairing. In other words, by providing such split pairing tables, pairings associated with a certain type of user and/or device can be prevented from interfering with pairings of a different type of user and/or device.

Preferred embodiments of the invention are defined in the dependent claims.

Hereinafter, examples of the invention will be illustrated by reference to the attached drawings, wherein:

Fig. 1 is a block diagram of an example of a hearing device according to the invention when connected to two external devices;

Fig. 2 is a schematic representation of an example of a hearing device when connected to a plurality of external devices; Fig. 3 is a schematic illustration of a pairing overwriting in a single pairing table; and

Fig. 4 is an example of a split pairing table according to the invention.

Fig. 1 is a block diagram of an example of a first hearing device 10 to be worn at one ear of a user which typically is used together with a second hearing device 11 to be worn at the other ear of the user. The first and second hearing devices 10, 11 are ear level devices and together form a binaural hearing system. Preferably, the hearing devices 10, 11 are hearing instruments, such as RIC (Receiver in the canal), BTE (behind-the-ear), ITE (in-the-ear), ITC (in the canal) or CIC (completely-in-the-canal) hearing aids. However, the hearing devices, for example, also could be an auditory prosthesis, such as a cochlear implant device comprising an implanted cochlear stimulator and an external sound processor which may be designed as a BTE unit with a headpiece or as an integrated headpiece.

In the example of Fig. 1 , the hearing devices 10, 11 are hearing aids comprising a microphone arrangement 12 for capturing audio signals from ambient sound, an audio signal processing unit 14 for processing the captured audio signals and an electro-acoustic output transducer (loudspeaker) 16 for stimulation of the user's hearing according to the processed audio signals (these elements are shown in Fig. 1 only for the hearing aid 10). For example, the audio signal processing in the unit 14 may include acoustic beamforming (in this case, the microphone arrangement 12 comprises at least two spaced apart microphones).

The hearing aids 10, 11 comprise a wireless interface 20 comprising an antenna 26 and a transceiver 28. The interface 20 is provided for enabling wireless data exchange between the first hearing aid 10 and the second hearing aid 11 via a wireless link 30 which serves to realize a binaural hearing assistance system, allowing the hearing aids 10, 11 to exchange audio signals and/ or control data and status data, such as the present settings of the hearing aids 10, 11.

The interface 20 is also provided for data exchange via a wireless link 30 from or to a client device 40, for example for receiving an audio data stream from an external device acting as an audio source, or data from a remote control device.

According to one example, the interface 20 may be a Bluetooth interface, preferably a Bluetooth Low Energy (BTLE) interface.

The hearing aids 10, 11 also comprise a control unit 38 for controlling operation of the hearing aids 10, 11 , with the control unit 38 acting on the signal processing unit 14 and the transceiver 28, and a memory 36 for storing data required for operation of the hearing aid 10, 11 and data required for operation of the interface 20, such as pairing / network data. In particular, the control unit 38 and the memory 36 are configured to enable to maintain at least two tables which are separate or independent from each other, as will be explained in detail below. In particular, the control unit 38 is configured to handle connectivity of the hearing device 10 via the wireless interface 20 to a plurality of external devices, like the devices shown in Fig. 2. In the example of Fig. 2, the hearing device 10 is connected via a connection 30 to a first fitting station 42 (which acts as one of the client devices), while other external devices, like a smartphone 44, a telephone device 46, a media streamer 48, a second fitting station 50, a remote control 54, and a tablet 56 may try to connect with the hearing device 10 via connections 30A (shown in dashed lines in Fig. 2). Typically, the external devices which may be connected with the hearing device comprise at least one of a contralateral hearing device, a smartphone, a remote control, an audio streaming device, a wireless microphone and a fitting station.

In hearing devices the capacity of pairing tables typically is quite limited. One limitation is caused by the memory footprint of the pairing material (i.e. the pairing keys). Another limitation is the processing involved in the need to check connections which are about to be established against every pairing table entry. This becomes particularly computation intensive when a peer uses random resolvable addresses for which resolution must be tried against the identity resolving key of every entry in the pairing table.

In general, once a pairing table is full, new pairings are either impossible or need to replace existing entries. The replacement of existing pairing entries becomes particularly inconvenient when a pairing initiated by a second user overwrites a pairing initiated by a first user, since the first user then may be annoyed when a pairing initiated by him will no longer be present due to the action of a second user. In the context of wireless hearing devices, such first user and second user may correspond to the owner of, for example, a pair of binaural hearing aids, and a service provider who is in charge of configuration or repair of the hearing aids. Fig. 3 illustrates a single pairing table P having a capacity of three pairing entries, wherein the left-hand side of Fig. 3 shows that at a time ti the pairing table holds three entries for three different devices U ₂ and U ₃ as a result of pairings initiated by the owner of the hearing aid. If now a service provider initiates a pairing with a device one of the existing pairings will be overwritten, for example the pairing as illustrated at the right-hand side of Fig. 3 which shows the pairing table at the time t ₂ of the pairing with the device Since the owner of the hearing aid did not initiate the pairing with the service device S-,, he is likely to be annoyed that his hearing aid no longer connects to the device such as the smartphone of the owner of the hearing aid, which now is no longer represented in the pairing table.

It is to be noted that the pairing of Ui also would have been overwritten if the end user had paired a fourth device U ₄ ; however, since the pairing to U ₄ would be under the user's control and since the user would be aware of the limited capacity of the pairing table of the hearing aid, he is much more likely to accept that his pairing to U ₄ will overwrite an existing entry, compared to the above case in which one of his pairings is overwritten by a pairing initiated by a person other than the owner of the hearing aid.

Such kind of user interference as illustrated in Fig. 3 may be overcome, at least to some extent, by replacing a single pairing table by a plurality of separate/independent pairing tables which, for example, may be assigned to different users. For example, as illustrated in Fig. 4, there may be two independent pairing tables P1 and P2, wherein the first pairing table P1 is assigned to pairings initiated by the owner of the hearing device, whereas pairing table P2 is assigned to pairings initiated by a service provider. The pairing table P1 has a capacity of two pairings and, at the time ti, holds two entries for devices and U ₂ representing pairings initiated by the owner of the hearing aid. Pairing table P2 has a capacity of one pairing and is empty at the time - The total capacity of the pairing tables P1 and P2 is three, which corresponds to the capacity of the single pairing table P in Fig. 3, so that Fig. 4 actually shows a split version of the pairing table P of Fig. 3. With the split pairing tables P1 and P2 of Fig. 4 the service provider initiated pairing with the service device Si at the time t ₂ will be written into the pairing table P2 and thus will not overwrite any owner initiated pairing I ⁾ -,, U ₂ (see right-hand side of Fig. 4). It is to be noted that of course one of the pairings Ui and U ₂ of the pairing table P1 will be overwritten once the owner of the hearing device initiates pairing with a third device U ₃ , since such new pairing U ₃ will be written to the owner- assigned pairing table P1 rather than into the service provider assigned pairing table P2. However, as already mentioned above, such pairing overwriting is likely to be acceptable to the owner once he is aware of the limited capacity of the pairing tables.

It is to be noted that multiple pairing tables also may be realized through a (single) common table where entries are tagged to belong to different categories with an upper limit for the number of tagged entries per category. In other words, in such case the multiple pairing tables actually are "virtual" tables, wherein the tag of each entry of the common table designates the membership to one of the "virtual" tables. While in the above example there are two different "categories" of pairings, namely pairings initiated by the owner (end-user) of the hearing device and pairings initiated by a service provider, pairings with the binaural counterpart of the hearing device, i.e. the pairing with the contralateral hearing device of a binaural system (cf. hearing device 11 in the example of Fig. 1), may be considered as a category on its own in the sense that the binaural pairing should not overwritten by pairings of the other two categories. Thus, there may be actually three different pairing categories, which may be implemented by three separate pairing tables.

For implementing a split pairing table concept, the hearing device has to be enabled to decide for each pairing into which of the pairing tables the present pairing is to be written. To this end, the control unit 38, which also acts as a pairing control unit, is provided with target pairing table selection information during the pairing process so as to decide, based on the target pairing table selection information received during the pairing process, into which one of the pairing tables the respective pairing is to be written. Preferably, the target pairing selection information is provided in such a manner that each of the pairing tables is actually assigned to a certain user, such as the owner of the hearing device and a service provider. In addition, as already mentioned above, a third pairing table may be assigned to the binaural pairing.

According to one example, the hearing device receives the target pairing table selection information as a message from the respective (external) device involved in the pairing process; such message may be sent prior to sending a pairing request to the hearing device, or it may be sent after the pairing request. Sending the target pairing table selection information message prior to sending the pairing request has the advantage that, in case that the hearing device is not willing to accept pairings from devices for which it has no designated pairing table, it may reject the pairing request. Sending the message after the pairing request has the benefit that the hearing device may persistently store the pairing only once it receives the target pairing table selection information message, so that the hearing device can restrict interaction to the pairing device to a predetermined time span or up to the next erasure of volatile storage space. According to an alternative embodiment, the hearing device may receive the target pairing table selection information not from the pairing device but rather from a third device communicating with the hearing device, such as a smartphone, wherein the third device has a user interface for receiving a corresponding user input concerning the target pairing table selection information. In other words, in this case the target pairing table selection information message is not sent from the pairing device but rather from a third device acting as a pairing manager. For example, the hearing device, when having received a pairing request, may send information concerning the pairing request to the third device on which the user then will be prompted to select the target pairing table for the pairing device.

According to a further alternative embodiment, the hearing device is configured to derive the target pairing information from device identification information, such as an address or an attribute, received from the pairing device (i.e. the external device involved in the pairing process); also in this case the pairing device does not send a target pairing table selection information message.

According to one example, the target pairing selection information may be indicative of whether the pairing device belongs to a predefined group of pairable devices, so that in this case a certain one of the pairing tables can be assigned to a certain group of devices. For example, one of the pairing tables may be assigned to services devices. According to one example, the target pairing table selection information may be implemented as a default setting in the respective external device, it may be user configurable or it may be hard-coded. Actually, the same device may send different target pairing table selection information messages, depending on the specific application requesting pairing with the hearing device, i.e. different applications may be run on the same device, which have different target pairing tables. For example, a remote control application used in service context, for example by a hearing care professional when configuring the hearing device, may be configured to request "service-provider pairing", while the same remote control application, when used by a hearing impaired customer, will be configured to request "end-user pairing" (i.e. "owner pairing"). In principle, the application may be even configured to dynamically request the user to designate the target pairing table every time it requests a pairing. Thus, the target pairing table actually is not device-specific but rather is specific to the entity requesting pairing, such as the application presently requesting pairing.

According to one embodiment, the hearing device is configured to ignore pairing requests from pairing devices in case that the hearing device does not receive target pairing table selection information during the pairing process. According to a variant, the hearing device may be configured to not persistently store pairing information in case that the hearing device does not receive target pairing selection information during the pairing process. According to another embodiment, one of the pairing tables may be a default pairing table, wherein the hearing device is configured to select the default pairing table for storing a new pairing information entry in case that the hearing device does not receive target pairing table selection information during the pairing process.

According to one embodiment, the hearing device may ignore pairing requests from devices in case that target pairing table selection information is received which does not correspond to one of the pairing tables of the hearing device.

According to another example, the hearing device may ignore pairing requests from devices in case that the tagging information associated with the pairing request received from the device is not recognized by the hearing device as being supported by the hearing device.

According to one embodiment, there may be only two pairing tables, wherein one of the pairing tables is associated with all pairings which are not associated with the other one of the pairing tables, i.e. one of the pairing tables can be specifically addressed by the target pairing table selection information, while the other pairing table is used for all other cases.