GB2447242A

GB2447242A - Personal audio management

Info

Publication number: GB2447242A
Application number: GB0704222A
Authority: GB
Inventors: Stuart Nathan John; Kamal Jamil Munir
Original assignee: FUNKTIONAL SOFTWARE Ltd
Current assignee: FUNKTIONAL SOFTWARE Ltd
Priority date: 2007-03-05
Filing date: 2007-03-05
Publication date: 2008-09-10
Also published as: GB0704222D0

Abstract

An audio controlling unit 40 comprises an input to receive data from at least two software applications 20, 22, an output 41 for audio data, and a controller to control the audio output in response to the detection of an event 34 and according to a set of audio rules 42. One of the inputs could be from internet telephone or softphone software, more commonly known as VOIP. The rules which are used to control the output could be predetermined or they could be determined using dynamic system characteristics. An example operation of the control unit 40 would involve the detection of an incoming phone call whilst music is being played via speakers. The audio controlling unit 40 would then automatically mute the music and direct the call to an appropriate headset or earpiece, thereby intelligently switching the source of the audio output.

Description

Applkatrnn No. GB07042229 RTM Date.27 June 2007 The following terms are

registered trademarks and should be read as such wherever they occur in this document:

BLUETOOTH

1 2447242

PERSONAL AUDIO MANAGER

This invention relates to the management of audio data and audio outputs, especially audio outputs from a computer.

Personal computers were once dedicated word processing machines for use in largely administrative capacities. However, in recent times personal computers have developed to become multi-media entertainment hubs. Internet "softphones", MP3 players, and audio mixing applications, are common aspects of a modern computer being used as an audio studio.

A modern computer may have connections to a wide variety of different audio devices, applications and tools. There may be multiple audio inputs, and normally there is a single audio output; an audio mixer such as the Windows (RTM) Audio Mixer, may be used to merge the various inputs into a single output. Despite this, each audio element tends to operate independently of the other elements. The lack of integration between the various audio elements can cause a wide variety of different problems. For example, it may be desirable to block certain audio outputs in particular circumstances.

The situation may be contrasted with the common use of a mobile phone. In certain situations it is desirable to operate a mobile phone in "silent mode" in order to prevent undesirable audio outputs. This is more easily achievable in a mobile phone than in a computer because the various audio functions are inter-related in a common unit that is dedicated to a single function. While it may be desirable to prevent or control certain audio outputs from a computer in particular situations, it is complex for this to be arranged, in general terms, due to a lack of integration between the various audio elements.

According to an aspect of the present invention there is provided an audio controlling unit on a computer for controlling an audio output and interfacing between at least two software applications on the same computer, the unit comprising: receiving means for receiving input data from at least two software applications; means for outputting an audio output, the audio output being related to the input data received from at least one of the two software applications; means for detecting an event; a memory unit comprising a set of audio control rules stored in memory; and a controller operable to control the audio output in response to the detection of an event, and according to the set of audio control rules.

Thus, the audio controlling unit may effectively manage and control audio content from various software applications to produce a desirable audio output.

In many circumstances it is desirable for the audio output to relate uniquely to the input data from one of the software applications. Thus, audio data from a single software application may be streamed directly into the audio output. The controlling step may be operable to switch the source of an audio output between different software applications in response to the detection of an event, and according to the audio control rules.

As well as switching between the sources of an audio output, the present apparatus allows the audio output to be controlled in a wide variety of ways. For example, audio data from different applications may be merged together in an output and the relative pitch, speed and volume of the respective audio inputs can be controlled in the audio output.

By using an audio controlling unit on a computer, the present method is applicable to receiving inputs from softphones, media players and other standard media applications, and to providing an audio output via a wide variety of output devices, whether they be connected to the computer by wire or by a wireless protocol such as Bluetooth.

Preferably at least one audio control rule in the set of audio control rules is predetermined. The audio control rules may be predetermined by system defaults.

Alternatively, a user may update or replace system defaults with their personal preferences to create a new set of predetermined audio control rules.

By way of example, two software applications could be a softphone and a MP3 player. While the softphone is idle, the normal audio output may be music from the MP3 player. It may be a predetermined default setting that music is muted in the output in response to the detection of an incoming call. Equally, a user may choose to over-ride this default setting by selecting a user preference that music from the MP3 player is muted only when the means for detecting an event detects that an incoming call has been answered; this user preference may replace the specific default setting in the predetermined criteria. There may be many levels of complexity at which user defined predetermined rules may be applied.

At least one audio control rule in the set of audio control rules may be determined by dynamic system characteristics. In this way, a wide variety of different system characteristics may be used to control the audio output. Relevant system characteristics may include: recent user actions, historic user actions, user preferences, trends derived from historic user actions, and audio controlling unit or computer performance.

Thus the audio control rules may be modified "intelligently" according to system characteristics. For example, if a user continually indicates, by user interaction, that the audio output should be controlled in a certain way then the audio control rules may be adapted to control the output in the way indicated by the user, without the user needing to make the indication. Preferably dynamic system characteristics are used to modify predetermined audio control rules which may have been stored as factory defaults.

In certain embodiments there may be some audio control rules that are predetermined and some audio control rules that are determined by dynamic system characteristics.

The controller may switch the source for the audio output between the at least two software applications in response to the detection of an event. Thus, the audio controlling unit may be an intelligent switch that automatically switches an audio output between multiple audio sources. Sophisticated switching may be particularly necessary where there is a large number of connected software applications and, possibly, a large number of audio outputs.

The audio output may be related to the input data received from two or more software applications. Thus, the audio output may comprise a mix of input data from multiple software applications.

The controller may control an aspect of the input data received from at least one software application in the audio output. Aspects of the input data which may be controlled include the volume, the frequency and/or the pitch of the audio input in the audio output. However, many other aspects of the input data may be controlled, for example there may be a configurable time delay between receiving an audio input and creating an audio output or the sampling rate of the audio input may be varied. Where more than one audio input is present in the audio output, the controller may control the relative volumes, frequencies and/or pitches of the two audio inputs. Thus, there may be a high degree of flexibility in the control of a merged audio output.

Preferably the controller controls the volume of the audio input from a software application in the audio output. Where more than one audio input is present in the audio output, their relative volumes may be controlled. In this way it is possible to mute, or reduce the volume of, one of the audio inputs with respect to the other audio input. This may enable a particular audio input to be heard more clearly in the audio output, as required.

The means for detecting an event may be arranged to detect an event in hardware.

Examples of possible events in hardware include: the operation of an external button, device state transition (plug/unplug, connect/disconnect, etc), change in Bluetooth signal strength, operation of a touch-screen monitor, and security or access control events. Any of these events could precipitate the need to control the audio output in a certain way, in dependence on the audio control rules.

Alternatively the means for detecting an event may be arranged to detect an event in software. Examples of possible software events include: softphone events such as incoming call, outgoing call, rejectf accept call, hold/resume call, dial contact, call; voice messaging operations such as playback message start/end, record message start/end; chat messaging operations such as incoming chat message alert, playback of chat message using Text-to-Speech (T2S), outgoing chat message using Speech-to-Text (S2T) through voice recognition; the state presence of a softphone such as connected presence, call in progress state presence, disconnected state presence, and device state presence.

Preferably the means for detecting an event can detect both hardware and software events with the set of audio control rules comprising rules for dealing with all possible scenarios.

The audio controlling unit may comprise receiving means for receiving input data from a device. In this way there may be bi-directional audio streams in the audio controlling unit, one audio stream transferring data from a software application to a device, and the other audio stream transferring data in the reverse direction.

There may be a controller operable to control the audio that is output in the reverse direction, i.e. to a software application. Also, the reverse direction audio output may be controlled in response to the detection of an event, and according to the set of audio control rules.

One software application may be a softphone. The present apparatus is particularly suitable for use with softphones. The nature of softphones is such that a call may be received at unpredicted times. Thus, by detecting events related to softphones, the audio controlling Unit can control the audio output appropriately. A softphone may be used in conjunction with a device such as a headset, comprising a microphone and an earpiece; this may be suitable for use with bi-directional audio streams in the audio controlling unit.

Other possible software applications include media players and third party applications such as MS Office (RTM). There may be more than one softphone input such as a Skype (RTM) softphone and a MSN (RTM) softphone.

Preferably the audio controlling unit comprises at least one connection to an audio device and the audio output is arranged to be relayed on an audio device.

Possible audio devices include: headphones, wireless headphones, dedicated loud speakers, and computer integrated loud speakers.

As an alternative, an audio output may be recorded in a memory device, which memory may be accessible via a CDIDVD or computer hard disk/flash memory.

There may be a device manager for maintaining a log of connections between the audio controlling unit and at least one audio device. Where wireless protocols such as Bluetooth are to be used, a device manager may be arranged to keep an up to date record of all of the devices in range. This may be an advantageous feature because moving Bluetooth devices have varying signal strengths, meaning that they will come in and out of range of a computer. Also, wireless devices are often powered by batteries, which have a limited lifespan. For these reasons it is desirable to maintain an accurate log of connections to audio devices.

The audio controlling unit may further comprise means for outputting a second audio output that is related to the input data received from at least one software application. By creating two audio outputs, audio data from one software application may be relayed on one output, whereas audio data from another software application may be relayed on the other output. The outputs may be switched between different audio devices according to audio control rules, as appropriate. The specific control of allocating a particular output to a particular device may be carried out by a device selection engine.

In an alternative arrangement the same audio content may be output on two audio outputs. Also, different relative combinations of the two audio inputs may be relayed on different audio outputs.

There may be a feedback controller operable to control data that are output from at least one software application, in response to the detection of an event, and according to the set of audio control rules. By controlling data from the data sources, the audio controlling unit may be arranged in feedback control of the software applications. It may be desirable to control several aspects of the audio data by feedback control of different software applications. For example, in the case of a media player, it may be desirable to pause or stop the audio stream and skip or scan between audio tracks. Preferably the audio controlling unit loads a plugin for each connected software application and controls that data source via the application's Application Programming Interface (API).

The audio controlling unit may comprise means for detecting digital licenses and means for checking for updates to the digital license. Preferably a connection to the internet is provided so that updates to digital licenses can be checked via the internet. In this way, the functionality of a device, or a software application, may be enhanced or restricted, as appropriate.

Preferably the digital licenses are associated with external devices. Devices such as USB Bluetooth relay transceivers often have digital licenses associated with them. By updating the digital license the functionality of devices may be controlled either by enhancement or restriction. This is desirable because a manufacturer who sells a device with a license may have no way of updating a digital license post sale.

The audio controlling unit may comprise means for converting the format of the output. Thus, an audio output may be converted into a text output by speech recognition software.

The audio controlling unit is preferably implemented as software modules running on a computer, although it could also be at least partially implemented as hardware.

According to another aspect of the present invention there may be provided a computer comprising: an audio controlling unit as previously defined; at least two software applications arranged to supply inputs to the audio controlling unit; and an interface to an audio device for outputting an audio output from the audio controlling unit.

The computer may be any device with a processor. In many desirable applications the computer may be a standard desk top computer, but many other devices may include processors capable of embodying the present invention.

Other examples include laptops, palm tops, Personal Digital Assistants (PDAs), or embedded computers such as may be found in portable devices such as MP3 players. It may be particularly appropriate to apply the present method on a personal computer that enables the use of softphones over the internet.

According to another aspect of the present invention there is provided a method of interfacing between software applications and controlling an audio output on a computer, the method comprising the steps of: receiving input data at an audio controlling unit on a computer, the input data being from at least two software applications on the same computer; outputting an audio output that is related to the input data received from at least one of the two software applications; and controlling the audio output in response to the detection of an event by the audio controlling unit, and according to a set of audio control rules.

According to yet another aspect of the present invention there is provided a personal audio manager on a computer for controlling an audio output and interfacing between at least two software applications on the same computer, the personal audio manager comprising: an interface to at least two software applications so that the personal audio manager receives input data from the software applications; an audio output line, wherein the audio output data that are output via the audio output line are related to the input data received from at least one of the two software applications; an event detection unit; a rules database comprising a set of audio control rules stored in memory; and a main controller operable to control the audio output in response to the detection of an event by the event detection unit, and according to the set of audio control rules in the rules database.

According to yet another aspect of the present invention there is provided a computer readable storage medium having stored thereon a computer program, the computer program comprising: a program module that when running on a computer receives input data from at least two software applications on the same computer; a program module that outputs an audio output that is related to the input data received from at least one of the two software applications; and a program module that controls the audio output in response to the detection of an event by the audio controlling unit, and according to a set of audio control rules.

The computer program stored on the computer readable storage medium may be in computer memory or may be transferred to computer memory. Computer memory may include, for example, flash memory, a standard computer hard disk and RAM. The computer readable storage medium may be portable; optional portable media include USB flash memory sticks, CDs and DVDs. Also, the computer readable storage medium may be located on an internet server so that it may be downloaded via a network computer.

Any of the apparatus features may be provided as method features and vice versa.

Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which: Figure 1 shows a personal audio manager operating as an intelligent switch between various audio inputs and external devices, in an embodiment of the present invention; Figure 2 shows a schematic diagram representing the internal operations of a personal audio manager in an embodiment of the present invention; Figure 3 shows a flow diagram illustrating various modes of operation for a personal audio manager in an embodiment of the present invention; and Figure 4 shows a flow diagram showing the operation of the personal audio manager when an event is detected in an embodiment of the present invention; Figure 5 shows a personal computer comprising a personal audio manager and connected to a USB Bluetooth transceiver in an embodiment of the present invention.

Figure 1 shows a personal audio manager (PAM) 2 as an interface between a plurality of data sources 4, 6, 8 and a plurality of devices 10. The PAM 2 is a software application that controls the connections between data sources 4, 6, 8 and devices 10, and controls the audio output sent to audio output devices. The inputs to the PAM 2 include a group of softphones 4a,b,c, a group of media applications 6a,b,c, and a group of other applications 8a,b,c. The devices 10 include wired headphones lOa, a Bluetooth earpiece lOb, a remote control lOc and a pair of dedicated loudspeakers lOd. The remote control lOc is not capable of providing an audio output and may be used as an input to control the operations of the PAM 2 The softphones 4a,b,c may include softphones such as those provided by Skype (RTM), MSN (RTM) and Cisco Systems (RTM). Media applications 6a,b,c may include applications such as Windows Media (RTM), or iTunes (RTM); these are all software applications running on the same computer as the PAM 2. Other applications 8a,b,c may include Microsoft Office (RTM), Microsoft (RTM) Word, or Microsoft Outlook (RTM).

The PAM 2 is operable as an intelligent switch for switching the source of an audio output between different data sources 4, 6, 8 in response to the detection of an event, and according to audio control rules. In one example of an operating condition of the PAM, the PAM 2 may detect an incoming softphone call while music from a media player 6a is being played via dedicated loudspeakers lOd. At the establishment of the softphone call, using a softphone application 4a, the PAM 2 may be arranged to open an audio connection with a preferred audio device, such as a Bluetooth earpiece lOb, and to automatically stop, pause, or lower the music from the media player 6a, in accordance with defined rules.

When the softphone call is terminated, the previous media player settings may be restored so that music playback can be resumed. A different set of rules may apply in different operating conditions, for example, if the user were initially listening to music from a media player 6a with a Bluetooth earpiece lOb, the music could be diverted to dedicated loudspeakers lOd, at a low volume, when the incoming softphone call is answered via the Bluetooth earpiece lOb.

Figure 2 shows a schematic diagram illustrating the internal operations of the PAM 2. As in the situation shown by Figure 1, the PAM 2 receives inputs from a set of softphone applications 20 and a set of other applications inputs 22 which may include media applications. Both the softphones 20 and the other applications inputs 22 are arranged for connection to a respective Application Programming Interface (API) 21, 23. The APIs 21, 23 are of use to a program developer and can be used to control the softphones 20 or other applications 22.

The softphone input 22 to the PAM 2 is received by a softphone exchange (PBX) 24. The PBX 24 is arranged to connect to all softphone applications and is a software version of a standard telephone exchange. The PBX 24 is connected to a call manager 26 which is arranged to keep a log of all incoming and outgoing calls. The call manager 26 remembers the state of each call and arranges for calls to be put on hold, when required. Both the call manager 26 and the PBX 24 provide inputs to a main controller 40. The main controller 40 is the hub of the PAM 2 and the other applications inputs 22 also provide an input to the main controller 40.

The main controller 40 is arranged to provide at least one audio output, via an audio output line 41, to an audio device, which may be just one device among a set of devices 60. The output line 41 from the main controller 40 is fed initially to a device manager 28. The device manager 28 keeps a log of the devices which are connected to the PAM 2. It is important to keep an up to date log because the number of connected devices may vary: wired devices can be plugged or unplugged and wireless devices can go out of range or run out of battery.

The device manager 28 is connected to an audio manager 30 which arranges for an audio output to be sent to a particular audio device. The audio manager 30 may also be arranged to control the volume of the audio output on a particular audio device. There may be more than one output line 41 if there is lobe more than one audio output.

An optional feature is shown between the audio manager 30 and the devices 60, this is a speech manager 32. The speech manager is adapted to convert speech to text (commonly referred to as S2T) and text to speech (T2S). This feature may be particularly useful for blind or deaf users, so that audio can be converted to text for display on a device, or vice-versa. Speech may also be used as a detectable event, for example using speech detection of particular verbal commands. To this end there may be a connection (not shown) between the speech manager 32 and the event detection unit 34.

The main controller 40 is arranged to control the audio output in response to the detection of an event. To this end there is an event detection unit 34 connected to the main controller 40. The event detection unit 34 receives a plurality of inputs; in the embodiment shown in Figure 2 the unit 34 has inputs from the devices 60, the softphone inputs 20, the other applications inputs 22, and a presence manager 36. The event detection unit 34 monitors its inputs for any changes in status that correspond to a predetermined detectable event. For example, a detectable event from the softphone input 20 may be a new incoming call, the termination of an old call, the placing of a call on hold, and the rejection or acceptance of an incoming call. Many other events may also be associated with the softphone input 20, the other applications inputs 22, and the devices 60. These events may be events in software, which do not correspond to a physical change, or else may be events in hardware such as a change in the availability of a particular device. A human interface device (HID) 38 is provided between the devices 60 and the event detection unit 34. The HID 38 is arranged to monitor Windows (RTM) compatible devices for events; these may include hardware events such as mouse clicks. In a similar way, a Bluetooth controller 39 is arranged to monitor Bluetooth devices for events.

A presence manager 36 is connected to the softphone input 20 and is arranged to monitor the presence of a user and their contacts in a softphone application. The presence of a user is an indication of a user's availability. Common presences include online, offline, online (busy), and "sleeping". The presence manager 36 can be used as an input to the event detection unit 34 so that an event can be detected when an individual's presence changes. The presence manager 36 may be connected to applications other than softphones 20 which also use "presence"; this could include e-mail accounts, for example.

Upon detection of an event by the event detection unit 34, the event is identified, and the relevant rules that are associated with that event are extracted from a rules database 42. The rules database 42 is a data storage unit comprising a set of rules for controlling the actions of the main controller 40 in response to the detection of a particular event by the event detection unit 34. There may be a default rule for each individual event. However, these default rules may not be appropriate in all operating conditions and may not fit with an individual's preferences. Therefore, the rules database 42 may be modified by a user to update the predetermined rules with their own preferences. In addition, the rules database 42 may comprise connections (not shown) to the call manager 26, the device manager 28, and other elements of the PAM 2 so that the rules can be dynamically changed depending on dynamic system characteristics. For example, there may be a default rule that is appropriate for dealing with the detection of a new incoming call; however, a different rule may be appropriate for an incoming call when a wireless headset is in range, as reported by the device manager 28.

In operation, the event detection unit 34 detects an event, determines the nature of the event, and ascertains the appropriate rule from the rules database 42. The event detection unit 34 then sends a command to the main controller 40 instructing it how to respond to the detection of the event. The main controller 40 has a wide variety of different possible responses, and examples include: switching the content of an audio output between different audio inputs; creating a new audio output for a specific device; switching audio outputs between different audio devices; merging a number of audio inputs into a single audio output; and controlling the softphones 20 or other applications 22 by feedback control via their respective API 21, 23.

The PAM 2 comprises a contact manager 44 with connections to both the softphones 20 and the other applications 22. The contact manager 44 stores a user's contacts in an address book. Each contact in the contact manager 44 has a unique two digit code associated with them that may be used for speed-dialling.

By entering a two digit code via a device such as a Bluetooth handset, users can arrange for the PAM2 to speed-dial the relevant contact. In addition, the PAM 2 comprises a licence manager 46 arranged for

connection to the main controller 40 and the devices 60. The licence manager 46 is arranged to examine the digital licences of various devices, such as USB Bluetooth transceivers, and to perform a check via the internet for updates to the digital licence. This feature will be explained in further detail later with reference to Figure 5.

The PAM 2 comprises its own API 48. The PAM API 48 is available for other program developers to interface with the PAM 2 and to drive its functions. The PAM API 48 is also used during the process of connecting to new devices. A connection "wizard" leads a user through the process of connecting new hardware so that the device manager 28 can be updated via the PAM API 48.

USB (Universal Serial Bus) drivers 50 are provided for controlling connected USB devices. The USB drivers 50 comprise a connection to both the main controller 40 and the devices 60. There is also feedback from the USB drivers to the event detection unit 34 so that relevant events may be detected.

Figure 3 shows a flow diagram showing common uses of a PAM. The PAM is initiated during the stan up step 69, configured during a configuration step 70, normal operations occur in the operation step 72, and the PAM may be shut down in the shut down step 74.

The start up step 74 occurs on initiation of the PAM application. During the configuration step 70 the PAM automatically detects software applications that are ntnning and connects to their public APIs. This enables the PAM to later control these applications in response to the detection of events. The configuration step 70 may also involve the establishment of connections to various audio devices via the connection "wizard" referred to previously. Finally the configuration step 70 may comprise a check that the user is licensed to use the application on a trial or full-time basis, exposing the functionality of the PAM accordingly.

During the operation step 72 the PAM listens for events that may be generated by the user, the operating system, or the user's contacts. The PAM is able to control an audio output in response to the detection of events. The control may be direct of indirect through control of media players or softphones via their respective APIs. In other words, the PAM is arranged to control and mediate an audio output between data sources such as softphones and media players.

In an example of an operating condition, a user may be listening to music via a Bluetooth wireless headset comprising a multi-function button. The multi-function button can be pressed and this may be a detectable event. However, the action that is performed in response to the depression of the multi-function button depends on the particular scenario. In the case of a softphone, the multi-function button may be arranged to answer an incoming call, make a call to a configured quick dial contact, or hang up a call, depending on the scenario at the time. A long press of the multi-function button may be a separate detectable event, and a long press may be used, for example, to return to a call on hold. Where a media player is being used, the multi-function button may be used to start or stop music, and a long press may be used to skip between audio tracks. Where a presentation application is being used the depression of the multi-function button may be an event that precipitates the advancement to the next slide of a presentation. The actions in response to the detection of the depression of a multi-function button, or other dedicated buttons, can be redefined by a user if they so choose.

In another example, when the PAM detects that a presentation application is running, the PAM may be arranged to block incoming calls from a softphone by setting the user's presence to "do not disturb" using the softphone API. When the presentation is finished the user's presence may be restored to the previous setting.

The shutdown step 74 occurs on termination of the PAM application. The PAM is arranged to disconnect from audio devices, softphones and media and third party applications so that it no longer responds to events. It also stops searching for wireless audio devices.

Figure 4 shows a flow chart detailing further operations of the operating step 72.

At a listening step 80, the PAM is idle in normal operating mode while listening for any events. Upon detection of an event at the detection step 82, the event is also determined. The appropriate action is then determined by the action determination step 84 by reference to the relevant audio rules. As already discussed there are a variety of different rules that may be set as system defaults, modified to reflect a user's preference, or dynamically altered by the system. The appropriate action is then performed at the action step 86 (it being understood that a positive decision to take no action is still an action within this context).

Following an action, the update step 88 is arranged to update the various logs in the PAM, as appropriate. For example, if the action in the action step 86 caused a softphone call to be answered then the update step 88 may be arranged to reflect this in the call manager 26. Finally, the PAM returns to listening mode 80, awaiting the detection of a new event.

Figure 5 shows a laptop computer 90 comprising a PAM module 92 loaded in memory. The laptop 90 is connected to a USB Bluetooth transceiver 94 which is arranged in Bluetooth communication with a wireless headset 96. The PAM 92 is arranged to detect the USB transceiver 94 as a device and to examine whether the USB transceiver 94 has a digital licence. The PAM 92 then checks for any updates to the detected digital licence via the internet 98. Any updates are then loaded into the USB transceiver 94; this may be conditional on the successful entry of a password, or the completion of a payment.

The digital licence on the USB transceiver 94 may be such that a Bluetooth connection to only one headset 96 is allowed, even if the USB transceiver 94 is capable of communicating with multiple headsets. The licensor may decide to enhance or restrict the functionality of the USB transceiver 94 by supplying internet licence updates so that extra features are enabled, or disabled, via the PAM 92, as appropriate.

The laptop computer 90 is also connected to a second Biuetooth transceiver 100 which is arranged in Bluetooth communication with a second Bluetooth headset 102. In this arrangement the second Bluetooth headset 102 has a digital license.

The PAM 92 is arranged to communicate with the Bluetooth headset 102, via the Bluetooth transceiver 100, and to examine whether the headset 102 has a digital licence. The PAM 92 then checks for any updates to the detected digital licence via the internet 98.

Claims

Claims 1. An audio controlling unit on a computer for controllmg an

audio output and interfacing between at least two software applications on the same computer, the unit comprising: receiving means for receiving input data from at least two software app! ications; means for outputting an audio output, the audio output being related to the input data received from at least one of the two software applications; means for detecting an event; a memory unit comprising a set of audio control rules stored in memory; and a controller operable to control the audio output in response to the detection of an event, and according to the set of audio control rules.
2. An audio controlling unit according to claim 1 wherein at least one audio control rule in the set of audio control rules is predetermined.
3. An audio controlling unit according to claim 1 or claim 2 wherein at least one audio control rule in the set of audio control rules is determined by dynamic system characteristics.
4. An audio controlling unit according to any of the preceding claims wherem the controller switches the source for the audio output between at least two software applications in response to the detection of an event.
5. An audio controlling unit according to any of the preceding claims wherein the audio output is related to the input data received from two or more software applications.
6. An audio controlling unit according to any of the preceding claims wherein the controller controls an aspect of the input data received from at least one software application in the audio output.
7. An audio controlling unit according to any of the preceding claims wherein the controller controls the volume of the audio input from a software application in the audio output.
8. An audio controlling unit according to any of the preceding claims wherein the means for detecting an event are arranged to detect an event in hardware.
9. An audio controlling unit according to any of claims 1 to 7 wherein the means for detecting an event are arranged to detect an event in software.
10. An audio controlling unit according to any of the preceding claims further comprising receiving means for receiving input data from an audio device.
11. An audio controlling unit according to any of the preceding claims wherein there are bi-directional audio streams in the audio controlling unit between a software application and an audio device.
12. An audio controlling unit according to any of the preceding claims wherein one software application is a softphone.
13. An audio controlling unit according to any of the preceding claims wherein the audio controlling unit comprises at least one connection to an audio device and wherein the audio output is arranged to be relayed on an audio device.
14. An audio controlling unit according to any of the preceding claims further comprising a device manager for maintaining a log of connections between the audio controlling unit and at least one audio device.
15. An audio controlling unit according to any of the preceding claims further comprising means for outputting a second audio output that is related to the input data received from at least one software application.
16. An audio controlling unit according to any of the preceding claims further comprising a feedback controller operable to control data that are output from at least one software application, in response to the detection of an event, and according to the set of audio control rules.
17. An audio controlling unit according to any of the preceding claims further comprising means for detecting digital licenses and means for checking for updates to the digital license.
18. An audio controlling unit according to claim 17 wherein the digital licenses are associated with external devices.
19. A computer comprising: an audio controlling unit according to any of the preceding claims; at least two software applications arranged to supply inputs to the audio controlling unit; and an interface to an audio device for outputting an audio output from the audio controlling unit.
20. A method of interfacing between software applications and controlling an audio output on a computer, the method comprising the steps of: receiving input data at an audio controlling unit on a computer, the input data being from at least two software applications on the same computer; outputting an audio output that is related to the input data received from at least one of the two software applications; and controlling the audio output in response to the detection of an event by the audio controlling unit, and according to a set of audio control rules.
21. A computer readable storage medium having stored thereon a computer program, the computer program comprising: a program module that when running on a computer receives input data from at least two software applications on the same computer; a program module that outputs an audio output that is related to the input data received from at least one of the two software applications; and a program module that controls the audio output in response to the detection of an event by the audio controlling unit, and according to a set of audio control rules.
22. An audio controlling unit substantially as described herein with reference to and as illustrated in the accompanying drawings.
23. A method substantially as described herein with reference to and as illustrated in the accompanying drawings.