US20130097244A1

US20130097244A1 - Unified communications bridging architecture

Info

Publication number: US20130097244A1
Application number: US13/633,033
Authority: US
Inventors: Peter H. Manley; Brett Harris; Derek L. Graham; Michael Tilelli
Original assignee: ClearOne Communications Inc
Current assignee: ClearOne Inc
Priority date: 2011-09-30
Filing date: 2012-10-01
Publication date: 2013-04-18
Also published as: US20170054677A1; US9935915B2

Abstract

A method, system, and apparatus for bridging communications between unified communications (UC) clients. Included herein is a UC client driver module with a set of UC client drivers configured to translate UC client specific human interface device (HID) commands to a common format. Also included is a UC audio assistant module configured to receive the HID commands in the common format and translate the HID commands from the common format into a device specific format. A device specific driver module with a set of device specific drivers is configured to pass the HID commands in the device specific format to an output device.

Description

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. patent application Ser. No. 61/541,990, filed Sep. 30, 2012, the disclosure of which is hereby incorporated herein by this reference in its entirety.

TECHNICAL FIELD

Embodiments of the present disclosure generally relate to communications software and applications. More specifically, embodiments of the present disclosure relate to Unified Communications (UC) software applications and compatibility issues between such UC software and hardware applications.

BACKGROUND

Several Unified Communications (UC) applications have proliferated into the enterprise communications market. These UC clients may provide many communication tools across multiple devices and media types including audio, video, collaboration (shared whiteboard, application sharing), instant messaging, and also unified messaging (SMS, Voicemail, and Fax). Some examples of commonly used UC clients include Skype, Microsoft Lync, Mirial SoftClient, Vidyo, Avaya, Cisco IP Communicator, etc.
Many of these UC clients have a requirement that they must be usable with hardware devices that can be installed on a Windows Operating System without requiring any additional driver software to be installed. Where USB drivers are used, this means that audio devices must support the standard Windows USB audio driver. In addition, a limitation of the Windows Operating System is that UC clients are generally developed to use only a single audio device. This prevents a UC client from using multiple interface/output devices concurrently.
One limitation of conventional UC clients is that because there are no standards for telephony and UC client specific telephony controls (dial, hangup, mute, etc), each vendor has developed a proprietary method for implementing these types of commands. For example, Skype uses a methodology in which an API provides the control interface to the client, whereas Microsoft Lync interprets USB HID commands directly from the device. Thus, different UC clients use different interface methodologies for volume and call control functions (e.g.; dialpad, on'off hook, etc.). As a result, hardware interface supporting these UC clients require different firmware and/or software interfaces to support each unique client. The result is that audio device manufacturers must provide UC client specific firmware/software with their hardware devices to enable all of their features to work with each specific UC client.
In addition, if an end user wishes to easily create a multi-party bridged conference call between users registered on different UC clients (e.g. between a user on Lync and another user on Skype), there is no current facility to enable this type of functionality.

BRIEF SUMMARY OF THE INVENTION

The present disclosure includes embodiments that resolve many of the issues found in the art of Unified Communications (UC). Specifically, embodiments are described for implementing a UC bridging architecture wherein a virtual audio device driver interface routes audio streams to a mixer/router interface and also acts to translate vendor specific Human Interface Device (HID) commands to a common format. An HID command translator can be configured to translate commands from the common format to a device specific set of commands. By utilizing a unifying UC architecture, multiple different device firmware implementations are not required to support various UC clients. Furthermore, audio bridging/mixing/routing functionality can be incorporated to allow audio bridging between UC clients, thereby expanding the capability and flexibility of the UC platform and increasing the value of the audio peripherals attached to the system. The present disclosure additionally includes embodiments that allow UC clients to share common interface devices, such as USB audio peripherals, regardless of different HID command implementations.
Other embodiments of the invention include methods, systems, and apparatuses for bridging communications between unified communications (UC) clients. The apparatus may include a UC client driver module with a set of UC client drivers configured to translate UC client specific human interface device (HID) commands to a common format. A UC audio assistant module may be configured to receive the HID commands in the common format and to translate the HID commands from the common format into a device specific format. A device specific driver module with a set of device specific drivers can be configured to pass the HID commands in the device specific format to an output device.
In a further embodiment, the UC audio assistant module is further configured to perform a mix-minus methodology on a UC client audio stream. In one embodiment, the set of UC client drivers comprise virtual audio device drivers. In yet a further embodiment, the set of UC client drivers is configured to translate UC client specific human interface device commands from a plurality of types of UC clients.
In one embodiment, the method includes: receiving a set of HID commands from a UC client; translating the set of HID commands to a common format; translating the set of HID commands from the common format to an output device specific format; and passing the set of HID commands in the output device specific format to a corresponding output device driver.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, which illustrate what is currently considered to be representative embodiments for carrying out the invention:

FIG. 1 is a schematic block diagram of one embodiment of a system for bridging communications between unified communications (UC) clients in accordance with the present invention;

FIG. 2 is a schematic block diagram of one embodiment of a UC bridging tool for bridging communications between unified communications (UC) clients in accordance with the present invention;

FIG. 3 is a schematic block diagram of another embodiment of a system for bridging communications between unified communications (UC) clients in accordance with the present invention; and

FIG. 4 is a flow chart diagram of one embodiment of a method for bridging communications between unified communications (UC) clients in accordance with the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom VLSI circuits or gate arrays, off-the-shelf semiconductors, such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices, such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like.
Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.
Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices.
Reference throughout this specification to “one embodiment,” “an embodiment,” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
In the following detailed description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable a person of ordinary skill in the art to practice the invention. However, other embodiments may be utilized, and structural, logical, and electrical changes may be made without departing from the scope of the invention. The illustrations presented herein are not meant to be actual views of any particular device or system, but are merely idealized representations that are employed to describe embodiments of the present disclosure. The drawings presented herein are not necessarily drawn to scale. Additionally, elements common between drawings may retain the same or have similar numerical designations.
FIG. 1 depicts one embodiment of a system 100 for bridging communications between Unified Communications (UC) clients. The system 100 includes an electronic device 102 that includes a memory 104 and a processor 106. As will be recognized by one of skill in the art, the electronic device 102 may be a device, such as a personal computer, laptop, client, server, personal digital assistant (PDA), cell phone, smart phone, or the like. In various embodiments, the electronic device 102 may have a UC client 108 installed thereon. A UC client is an application that provides one or more of audio, video, collaboration (shared whiteboard, application sharing), instant messaging, unified messaging (SMS, Voicemail and Fax), or the like. Some examples of commonly used UC clients include Skype, Microsoft Lync, Mirial Softclient, Cisco IP Communicator, etc.
As depicted, the electronic device 102 includes a UC bridging tool 110 that is configured with the logic necessary to bridge communications between different types of UC clients 108. Generally, the UC bridging tool 110 implements a virtual audio device driver interface that routes audio/video/data streams to a mixer/router software interface. The virtual audio device driver interface may support a common set of Human Interface Device (HID) commands between different types of UC clients 108. For example, virtual audio device drivers may be used to translate UC client specific HID commands to a common format that can be handled by an HID translator. The mixer/router interface may be configured to translate the HID commands into device specific commands that can be handled by specific device drivers such as headset device drivers, chat device drivers, USB Mic device drivers, and other device drivers as recognized by one of skill in the art.
The UC bridging tool 110 may be configured to allow UC clients 108 to concurrently share common hardware. The UC bridging tool 110 may also be configured to bridge audio streams between UC clients 108 running on the same hardware, effectively creating a conferencing bridge between UC clients 108. In a further embodiment, the UC bridging tool 100 may be configured to enable audio to be routed to/from more than one audio device. This may, for example, allow a reference stream to be sent to an echo cancelling audio recording device and an audio output device concurrently. Furthermore, the UC bridging tool 110 may be configured to enable audio streams to be sent to multiple output devices concurrently. For example, a headset can be used concurrently with sound card speakers or other devices.
As depicted, the system 100 may also include a display 112 for displaying graphics, data, images, and the like to the user. The system 100 may also include a set of user interface devices 114 and/or output devices that allow a user to interact with the electronic device 102. Such user interface/output devices 114 may include, but are not limited to, a keyboard, a mouse, a touch screen, a joystick, a touchpad, a microphone, a speaker, a printer, webcam, a digital camera, a scanner, a headset, telephone, Bluetooth device, or the like. The system 100 enables the bridging of audio/data between different UC clients without using an external server to perform the bridging function. The audio/data may be shared between different UC clients 108 running concurrently on the same conferencing platform (e.g., audio from Skype, Lync, Mirial, and other IP phones). Furthermore, the system 100 enables a user to choose which UC client 108 to use without having to purchase multiple hardware platforms and without the need for extensive device firmware support for each UC client 108. In at least one embodiment, the bridging tool 110 is implemented on a single electronic device 102 without utilizing an external server for performing bridging operations.
FIG. 2 depicts one embodiment of the UC bridging tool 110 for bridging communications between different types of UC clients 108. In the depicted embodiment, the UC bridging tool 110 includes a UC client driver module 202, a UC audio assistant module 204, and a device specific driver module 206. Of course in various embodiments, the different modules may be combined, split, labeled differently, implemented across multiple electronic devices, or the like as will be recognized by one of skill in the art.
The UC client driver module 202, in one embodiment, comprises virtual audio device drivers that are configured to support a common set of HID commands specific to each UC client 108. Virtual audio device drivers typically include a multimedia driver that allows a user to transfer audio streams from one application to another. Thus, a first application is able to send an audio stream to the input side of a virtual audio device driver while a corresponding application can receive the stream from the output side. Since all transfers are typically made digitally, there is no loss of audio sound quality. In some embodiments, virtual audio device drivers may be used by more than one UC client or other application to send audio through an output virtual audio device and the virtual audio devices may be configured to mix all of the streams together or to create separate corresponding virtual input devices. Similarly, multiple UC clients or other applications may be configured to receive audio from a virtual audio device, whether it's sharing the same audio data with another target or receiving its own audio stream. In one embodiment, a virtual audio device driver may include Virtual Audio Cables (VAC) and/or may be integrated with a VAC.
In one embodiment, the UC client driver module 202 includes kernel mode drivers, including virtual audio device drivers, for routing audio/data streams to the UC audio assistant module 204. The virtual audio device drivers may also be configured to translate client specific HID commands to a common format and/or device agnostic format. The virtual audio device drivers may also be configured to pass the common format HID commands to an HID translator of the UC audio assistant module 204. The virtual audio device drivers may also receive common format HID commands back from the HID translator to pass them back to the UC client 108.
The UC audio assistant module 204 receives common format HID commands from the UC client driver module 202 and may be configured to route incoming UC client 108 audio streams to one or more specific interface/output devices 114. In one embodiment, the UC audio assistant module 204 may optionally mix audio streams from the UC clients 108 using mix technologies such as a mix-minus methodology. A mix-minus methodology is a methodology where the output to a certain device contains everything except the input from that device. This prevents echoes or feedback from reverberating or howling and squealing through a sound system. Other mixing methodologies are also contemplated herein as recognized by one of skill in the art.
In one embodiment, the UC audio assistant module 204 may be further configured to route incoming UC client audio/data streams to one or more interface/output devices 114. Routing the incoming UC client audio/data streams may include routing device audio/data streams to a conferencing client, or potentially multiple conferencing clients. In one embodiment, the UC audio assistant module 204 may include an HID translator that receives HID commands in the common format and translates the HID commands to a device specific format. HID commands in the device specific format may then be passed to specific interface/output devices 114 by way of repeaters associated with the output devices. A repeater is an electronic device that receives a signal and retransmits it at a different level and or different power, or that amplifies, reshapes, retimes, or performs a combination of operations on the signal. In a further embodiment, the UC audio assistant module 204 may be configured to access output device specific drivers that are used to pass HID commands in a device specific format to the corresponding output devices. The UC audio assistant module 204 may also pass commands in a reverse order from output devices back to a UC client 108. This may include translating output device specific formats back to the common format, and then translating the common format back to a UC client specific format.
The UC audio assistant module 204 may also be configured to re-direct incoming device specific HID commands to another device. For example, volume control may be re-directed from a first interface/output device 114 (e.g., headset) to second interface/output device 114 (e.g., sound card speaker). In one embodiment, a particular device may be designated by the UC audio assistant module 204 to act as a default device. For example, a particular audio device may be designated as a volume control master such that the volume controls associated with that particular device control the volume of multiple attached output devices.
In certain embodiments, some UC clients 108 may not accept certain HID commands for all functions. For example, Skype is not conventionally configured to accept HID commands for volume, mute and hangup events. In such embodiments, the UC audio assistant module 204 may intercept HID commands for these functions and translate them into UC client 108 specific application programming interface (API) commands (e.g. Skype API commands). Then, the UC audio assistant module 204 may interface with the UC client 108 directly using the translated API commands. Thus, the UC audio assistant module 204 may use various methods to interpret general device driver telephony commands and forward them to corresponding UC clients 108. Some of these methods may include, but are not limited to, translating HID commands and forwarding the translated commands to a virtual device driver (e.g. for Lync) and translating device driver or USB HID command translation to or from UC client specific API or messaging interfaces (e.g. for Skype). In such embodiments, the virtual device drives may still be utilized to interface with the UC clients 108 and bridge communications between them. However, there may be UC client specific virtual device drivers to support additional telephony command translation.
A graphical user interface (GUI), or other type of interface, may be provided to map the architecture between multiple output devices and multiple UC clients. The GUI may be configured to allow an active output device to be switched dynamically. For example, an audio output may be changed from a headset to a speaker during a call without accessing the UC client interface. If only one output device is available, then all applications may use that device by default. However, where multiple output devices are available, the GUI may be configured to enable more than one UC client to be active at the same time by utilizing the multiple output devices respectively. For example, a first UC client may utilize a head set device at the same time that a second UC client is utilizing a webcam device.
FIG. 3 depicts one embodiment of a system 300 for bridging communications between multiple UC clients and output devices. As depicted multiple UC clients 302 are implemented in an application layer of an electronic device 102. The depicted UC clients 302 include a Cisco Client, a Skype Client, and a Lync Client. However, other types of UC clients are contemplated herein. In the depicted embodiment, each of the UC clients 302 accesses a corresponding virtual audio device driver 304 at the kernel mode level. The virtual audio device drivers 304 may comprise the UC client driver module 202 as described above. In one embodiment, the Cisco Client accesses a Cisco virtual audio device driver, the Skype Client accesses a Skype virtual device driver, and the Lync Client accesses a Lync virtual device driver. In one embodiment, the corresponding virtual device drivers operate to translate HID commands from the UC clients 302 into a common format. Thus the Cisco virtual device driver translates Cisco specific HID commands into a common format, and the Skype virtual audio device driver translates Skype specific HID commands into the common format. Similarly, in a reverse operation, the Cisco virtual audio device driver may translate HID commands from the common format back into Cisco specific HID commands. In this manner, the virtual audio device drivers 304 operate to pass HID commands and other information between the UC clients 302 and the UC audio assistant 306.
The UC audio assistant 306 may comprise the UC audio assistant module 204 as described above. As depicted the UC audio assistant 306 may include an HID translator and an audio router/mixer. The HID translator may be configured to translate HID commands from the common format provided by the virtual audio device drivers 304 into device specific formats that can be provided to specific output devices. The audio router/mixer may be configured to route audio to specific output devices and to perform mixing methodologies on the audio streams where desirable. As noted above, the audio router/mixer may be configured to perform mixing methodologies such as mix minus for audio streams.
The UC audio assistant 306, in the depicted embodiment, includes repeaters 308 corresponding to each output device. This embodiment includes a headset repeater, a chat 50/50U repeater, a chat 150 mic repeater, and an interact AT/COM repeater. However, other repeaters may also be used depending on which output devices are available for use. The repeaters 308 operate to pass device specific HID commands to device specific drivers 310. As depicted, a device specific driver 310 is provided in the kernel mode layer for each available output device. The device specific drivers 310 facilitate communication between the UC audio assistant 306 and the specific output devices. In the depicted embodiment, a headset device driver, a chat 50/50U device driver, a chat 150/150 mic USB device driver, and an interact AT/COM device driver are provided with corresponding repeater device 308.
In this manner, each UC client 302 may be utilized with each output device without the need for different device firmware implementations to support each different UC client 302. Furthermore, the audio bridging/mixing/routing functionality of the audio assistant 306 allows bridging between audio/data streams associated with the UC clients 302.
FIG. 4 depicts one embodiment of a method 400 for bridging communications between UC clients. The method 400 substantially includes and relates the embodiments and implementations described above with regard to FIGS. 1-3.
The method 400 begins when a set of HID commands is received 402 from a UC client 102. The HID commands are typically in a format specific to the UC client 102. Next, a UC client driver module 202 translates 404 the set of HID commands into a common format. Thus, commands from different types of UC clients 102 may be translated into the same common format. Next, a UC audio assistant module 204 translates 406 the set of HID commands from the common format to an output device specific format. The set of HID commands in the output device specific format may be passed 408 to a corresponding output device driver of a device specific driver module 206. The device specific driver module 206 passes 410 the set of HID commands from the output device driver to the output device for output to a user. The method 400 may also operate in a reverse manner to pass HID commands from a specific output device back to a specific UC client 102.
These methods may be practiced in some embodiments with fewer steps or in a different order than are shown. Many additions, deletions, and modifications to the preferred embodiments may be made without departing from the scope of the invention as hereinafter claimed. Further, the present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

What is claimed is:

1. An apparatus for bridging communications between unified communications (UC) clients, the apparatus comprising:

a UC client driver module comprising a set of UC client drivers configured to translate UC client specific human interface device (HID) commands to a common format; and

a UC audio assistant module configured to receive the HID commands in the common format and translate the HID commands from the common format into a device specific format; and

a device specific driver module comprising a set of device specific drivers configured to pass the HID commands in the device specific format to an output device.

2. The apparatus of claim 1, wherein the UC audio assistant module is further configured to perform a mix-minus methodology on a UC client audio stream.

3. The apparatus of claim 1, wherein the set of UC client drivers comprise virtual audio device drivers.

4. The apparatus of claim 1, wherein the set of UC client drivers is configured to translate UC client specific human interface device (HID) commands from a plurality of types of UC clients.

5. A method for bridging communications between unified communications (UC) clients, the method comprising:

receiving a set of HID commands from a UC client;

translating the set of HID commands to a common format;

translating the set of HID commands from the common format to an output device specific format;

passing the set of HID commands in the output device specific format to a corresponding output device driver.