System and method for multi-radio control

This application claims priority to U.S. Provisional Patent Application No. 60/883,777, filed Jan. 6, 2007, and to U.S. Provisional Patent Application No. 60/802,595, filed May 23, 2006, the entire disclosures of which are incorporated herein by reference.

Not applicable.

Not applicable.

Not applicable.

1. Field of the Invention

The present invention relates to the control of multiple wireless radios of differing radio types contained in a single computing device, such as a desktop personal computer, a laptop personal computer, a personal digital assistant (PDA), or the like.

2. Description of Prior Art

As shown in FIG. 1 , a personal electronic device 10 , such as personal computer (PC), personal digital assistant (PDA), or cellular phone may have disparate radios 11 a - 11 e using disparate radio technologies and communication protocols in an environment having remote wireless devices 14 a - 14 p . The remote wireless devices 14 a - 14 p are accessible through the radios 11 a - 11 e using the disparate radio technologies.

For instance, as shown, the personal electronic device 10 may have a GSM/CDMA cellular radio 11 a , a Wi-Fi (IEEE 802.11) radio 11 b , a UWB (Ultra-wide Band) radio 11 c , a Bluetooth radio 11 d , and another radio 11 e that represents future radios having unforeseen but equivalent wireless communication technologies. The remote wireless devices may include: a cellular network 14 a ; a first access point 14 b and a second access point 14 c using Wi-Fi technology; a third access point 14 d , a fourth access point 14 e , a wireless USB hub 14 f , a PDA 14 g , a first printer 14 h , a first computer 14 i , an first input device 14 j , and a first audio device 14 k using UWB technology; a second computer 14 l , a second input device 14 m , and a second printer 14 n using Bluetooth technology; and a remote wireless device 14 p that represents future remote wireless devices using unforeseen but equivalent radio technology.

Each individual radio 11 a - 11 e has an individual utility that is used to manage and control the radio. This is largely a result of the local radio types having different physical (PHY) layers, different medium access control (MAC) portions of the data link layer (DLL), and, therefore, different device drivers and different utilities (user interface applications) on the personal electronic device for control of the local wireless radios. Users get confused because they don't know which utilities they are to use to manage and control which radio in order to use a remote wireless device. Thus, there is a need for a single utility that can be used with all of the local radios 11 a - 11 e , to eliminate the need for a user to know what radio technology is being used to access remote wireless devices 14 a - 14 p , and allow the user to identify the remote wireless device that they wish to use without regard to the radio or technology used to access the remote device or the utility used to control the radio.

Further, the software developer that is developing applications that utilize the local wireless radios to connect to remote wireless devices must currently use different command structures to perform similar generic functions (such as find devices, connect/disconnect devices, set security, etc.). Again, this condition is the result of the different radio types having fundamentally different interfaces on multiple levels. Thus, there is a need for a utility that allows developers to treat different wireless radio types generically, and to allow third-party applications to access the functionality of such a utility.

These needs and others are met by a system and method for multi-radio control described herein, which, advantageously, unifies disparate radio technologies and communication protocols and abstracts them such that a user of a personal electronic device having a plurality of disparate radios wishing to make use of a remote wireless device or service is not required to know or understand the radio technology needed to connect to the given device.

According to an aspect of the invention, a system for multi-radio control in a personal electronic device includes: a program interface module for receiving requests regarding the remote wireless devices and providing responses to the requests; a local hardware manager module for receiving requests from the program interface module, formatting generic hardware interface requests for each radio, receiving generic responses to the generic hardware interface requests, and providing the responses to the program interface module; and an adaptation layer module associated with each radio. Each adaptation layer module receives the generic hardware interface requests from the local hardware manager module, generates specific driver commands to the associated radio driver modules based on the generic hardware interface requests, sends the specific driver commands to the associated radio driver modules, receives specific responses from the radio driver modules, generates generic responses based on the specific responses, and provides the generic responses to the local hardware manager module.

The system may also include a remote device manager module and a user interface application module. The remote device manager module is for managing remote device objects for available remote wireless devices. The user interface application module is for: receiving a request from a user to change the connection status (i.e. connect/disconnect) of at least one of the available remote wireless devices; sending the request to change the connection status of the at least one of the available remote wireless devices to the program interface module; receiving a response to the request to change the connection status of the at least one of said remote wireless devices from the program interface module; and presenting the response to the user. Additionally, the user interface application module is also for receiving notifications of changes in connection status that were not initiated by the user (i.e. an unexpected disconnect event), and presenting those notifications to the user.

Correspondingly, according to another aspect of the invention, a method for multi-radio control in a personal electronic device includes: searching for remote wireless devices available to each radio of the plurality of radios in response to receiving an instruction from a user to search for available remote wireless devices; presenting information as to available remote wireless devices to the user in response to receiving information indicating the remote wireless devices that are available; and establishing a connection with at least one of the remote wireless devices in response to receiving a request from said user to establish a connection with the selected remote wireless devices.

The method may further include: formatting a generic hardware interface request to search for available remote wireless devices; generating specific driver commands to each radio to search for available remote wireless devices based on the generic hardware interface request; sending the specific driver commands to a radio driver module associated with each radio; and receiving information indicating available remote wireless devices to each radio from each radio driver module.

Additionally, the method may further include: receiving a disconnect request from the user and disconnecting a remote wireless device in response; receiving a notification of a change in state of the connection and presenting the notification to the user; and determining that security credentials are required to access a remote wireless device and requesting/receiving such security credentials from the user.

Better understanding may be had by referring to the following detailed description of exemplary embodiments and drawings.

FIG. 1 is block diagram of a personal electronic device having disparate radios using disparate radio technologies and communication protocols in an environment having remote wireless devices accessible through the radios using the disparate radio technologies.

FIG. 2 is a functional block diagram of an exemplary system for multi-radio control according to the invention.

FIG. 3 is a screen shot of an Initial screen of an exemplary User Interface application module of the exemplary system of FIG. 2 .

FIG. 4 is a screen shot of an Connection Wizard screen of an exemplary User Interface application module of the exemplary system of FIG. 2 .

FIG. 5A is a screen shot of an Console screen of an exemplary User Interface application module of the exemplary system of FIG. 2 .

FIG. 5B is a screen shot of the Console screen of FIG. 5A , with an exemplary security credential dialog window presented thereon.

FIG. 6 is a hierarchical constructs diagram of an intermediate layer module of the exemplary system of FIG. 2 .

FIG. 7 is a class diagram for an exemplary local hardware manager module defining an abstract class of the intermediate layer module of FIG. 6 .

FIG. 8 is a class diagram for an exemplary local hardware object of the intermediate layer module of FIG. 6 .

FIG. 9 is a class diagram class diagram for an exemplary local adapter object of the intermediate layer module of FIG. 6 .

FIG. 10 is a class diagram for an exemplary remote device manager module of the intermediate layer module of FIG. 6 .

FIG. 11 is a class diagram for exemplary remote device objects of the intermediate layer module of FIG. 6 .

FIG. 12 is an exemplary time-sequence diagram for an “enumerate available remote wireless devices” function of an exemplary system and method for multi-radio control according to the invention.

FIG. 13 is user connection flow chart for an exemplary method for multi-radio control according to the invention.

According to an exemplary embodiment of the invention, disparate radio and network technologies are unified and abstracted such that a user wishing to make use of a remote wireless device or service is not required to know or understand the radio technology needed to connect to the given device. This is achieved by replacing multiple individual utilities that were previously used to manage individual radios with a single utility that understands each of the underlying radios. This provides a singular user experience where the user can find, connect and access remote wireless devices and services on any radio using the same methods.

A. Logical Software Layers

FIG. 2 is a functional block diagram of an exemplary system 16 for multi-radio control according to the invention, including a User Interface (UI) application module 18 and an intermediate layer object or module (software development kit (SDK)) 20 . Also shown are: local radios 12 a - 12 e , radio driver modules 22 a - 22 g for each of the local radios 12 a - 12 e , and a third-party application 24 . The User Interface application module 18 provides a single, uniform interface to a user allowing the user to find and use remote wireless devices (e.g. FIG. 1 : 14 a - 14 p ). The intermediate layer module 20 serves to translate or adapt instructions and notifications between the user interface application module 18 and the radio driver modules 22 a - 22 g for each of the local radios 12 a - 12 e . Additionally, the intermediate layer module 20 allows applications, such as third party application 24 , to use the instruction and notification adaptation functions of the intermediate layer module 18 to communicate with and control the radio driver modules 22 a - 22 g.

It should be noted that the radio driver modules 22 a - 22 g represent software modules that control the operations specific to each radio 12 a - 12 e . These software modules may take the form of stacks, device drivers and operating system programming interfaces, and the use of the term “driver” in the radio driver modules 22 a - 22 g in not intended to be a limitation on the scope of the claimed invention. It should also be noted that the radio driver modules 22 a - 22 g are typically provided by the radio hardware manufacturer.

Additionally, it should be understood that the implementation of the exemplary embodiment of the invention described herein is through object-oriented software, and, therefore the components of the intermediate layer (SDK) object 20 , described below, are themselves objects. However, a skilled practitioner will recognize that the functions of the objects could be accomplished by alternate functional and structural implementations. Therefore, some of the “objects” of the exemplary implementation will be described as “modules,” and it should be understood that, for the purposes of this description and the claims that follow, the terms “objects” and “modules” refer to any structural and functional implementations of the software objects described herein.

B. User Interface Application

FIG. 3 through FIG. 5B are screen shots of screens from an exemplary User Interface (UI) application module. FIG. 3 is an Initial screen 30 . FIG. 4 is a Connection Wizard screen 40 . FIG. 5A is a Console screen 50 . FIG. 5B is a screen shot of the Console screen 50 with an exemplary security credential dialog window 58 presented thereon.

The Initial screen 30 ( FIG. 3 ) provides a user with a choice of using a connection wizard interface of the Connection Wizard screen ( FIG. 4 ) by selecting a Connect button 32 , or going directly to the Console screen 50 ( FIG. 5A ) by selecting a View Console button 34 .

The Connection Wizard screen 40 ( FIG. 4 ) provides the user with a set of device class icons 42 representing a number of remote wireless device classes to allow the user to narrow the available remote wireless devices to only devices of a certain class. Selection of one of the device class icons initiates a search across all local radios for remote wireless devices that are devices of the selected class, and takes the user to the Console Screen 50 ( FIG. 5A ) to display the available remote wireless devices of the selected class. Additionally, a “Choose All” button 44 will take user to the Console Screen 50 ( FIG. 5A ) where all available devices are presented without filtering the available devices by device class.

The Console screen 50 ( FIG. 5A ) is subdivided into an Available window 51 , a Connected window 52 , and a Display Control window 53 . The Available window 51 provides a display of icons representing the available remote wireless devices. If the Console screen 50 is displayed as a result of the user selecting the View Console button 34 of the Initial screen 30 ( FIG. 3 ), all available remote wireless devices are presented in the Available window 51 . However, if the Console screen 50 is displayed as a result of the user selecting a particular device class icon of the Connection Wizard screen 40 ( FIG. 4 ), only remote wireless devices of the selected device class will be displayed in the Available window 51 , and an icon corresponding to the selected device class is highlighted in the Display Control window 53 .

In the exemplary Console screen 50 , an “access point” device class has been selected. An “access point” icon 54 in the Display control window 53 is highlighted, and a single available remote access point device is indicated by an access point icon 55 in the Available window 51 . Advantageously, the single available remote access point device is identified and displayed without regard to the local radio or the local radio technology that is used to communicate with the available remote access point, so that the user does not need to know or be concerned with the details of the local radio or local radio technology.

To initiate a connection with an available remote wireless device, such as the single available remote access point device, using the exemplary User Interface (UI) application 18 , the user may: 1) drag and drop the access point icon 55 from the Available widow 51 to the Connected window 52 ; 2) double-click the access point icon 55 ; or 3) right-click on the access point icon 55 and click a “connect” menu item 56 on a pop-up menu 57 that opens as a result of the right-click action.

To disconnect from a connected device, the user may: 1) drag and drop the device icon from the Connected window 52 ; or 2) right-click on the device icon and click a “disconnect” menu item on a pop-up menu that opens as a result of the right-click action.

Changes in connection status are displayed by: 1) moving the device icon between the Connected window 52 and the Available window 51 ; and 2) displaying a message in the lower right-hand corner of the screen (especially useful when the display for the User Interface (UI) application 18 is minimized).

FIG. 5B is a screen shot of the Console screen 50 with an exemplary security credential dialog window 58 presented thereon. If the remote device, such as the available remote access point device, requires security credentials, or if a service offered by the device requires security credentials, a security credential dialog window, such as the exemplary security credential dialog window 58 of FIG. 5B is presented to allow the user to enter their security credentials.

C. Intermediate Layer (SDK) Hierarchical Constructs

FIG. 6 is a hierarchical constructs diagram of the intermediate layer (SDK) object or module 20 . As shown, the intermediate layer module 20 has a program interface (Application Program Interface (API)) module 60 , a local hardware manager module 61 , adaptation layer modules 62 a - 62 e , and a remote device manager module 63 . Each of the adaptation layer modules 62 a - 62 e is comprised of a local hardware object 64 a - 64 e for each radio (corresponding to each physical radio 12 a - 12 e ( FIG. 2 )) and a local adapter object 65 a - 65 h for each distinct communication protocol supported by each radio. Remote device objects 66 a - 66 p are instantiated for each available remote wireless device (e.g. corresponding to remote wireless devices 14 a - 14 p of FIG. 1 ).

The program interface (API) module 60 exposes the functionality of the intermediate layer (SDK) module 20 to the UI application module 18 and to third party applications 24 , which includes the basic functions of: enumerate available remote wireless devices, connect/disconnect remote devices, and notification (including connection events, disconnection events, security events and error/warning events). Other functions of the intermediate layer (SDK) module 20 as described below are also exposed through the program interface (API) module 60 .

The local hardware manager module 61 maintains a collection of objects representing the local radios (i.e. the radios 12 a - 12 e of FIG. 1 ) and provides collection-level services for operations that are to be performed over the entire collection (i.e. get remote devices, disconnect all remote devices, turn power off to all local radios (i.e. “flight mode”)). As such, the local hardware manager module receives requests from the program interface (API) module 60 , formats generic hardware interface requests for each radio, receives generic responses from in response to the generic hardware interface requests, and provides the responses to the program interface (API) module 60 .

FIG. 7 is a class diagram for an exemplary local hardware manager module (e.g. 61 , FIG. 6 ) which defines an abstract local hardware manager class 70 , including abstract operations. Exemplary attribute and operation descriptions for the local hardware manager class 70 are contained in Table 1.

Returning to FIG. 6 , the adaptation layer modules 62 a - 62 e receive the generic hardware interface requests from the local hardware manager module 61 and generate specific driver commands to their associated radio driver modules based on the generic hardware interface requests. The adaptation layer modules 62 a - 62 e then send the specific driver commands to the associated radio driver modules (e.g. 22 a - 22 g , FIG. 2 ), receive specific responses from the radio driver modules, and generate generic responses based on the specific responses. The adaptation layer modules 62 a - 62 e provide the generic responses to the local hardware manager module 61 .

As mentioned, each of the adaptation layer modules 62 a - 62 e is comprised of a local hardware object 64 a - 64 e for each radio (corresponding to a physical radio 12 a - 12 e ( FIG. 2 )) and a local adapter object 65 a - 65 h for each distinct communication protocol supported by each radio. For example, Ultra-wide Band (UWB) technology allows a single radio (e.g. 12 c , FIG. 2 ) to operate using a number of communication protocols (e.g. Bluetooth 3.0 (e.g. 22 d , FIG. 2 ), Wireless USB Host (e.g. 22 e , FIG. 2 ), Wireless USB Device (e.g. 22 e , FIG. 2 ), and WiNet (e.g. 22 f , FIG. 2 ) protocols). The local hardware objects 64 a - 64 e provide physical radio characteristics and functions, such as the MAC address and enable/disable. The local adapter objects 65 a - 65 h provide communication protocol characteristics and functions, such as device name, friendly name, get devices, and connect/disconnect remote device. Class attributes and operations for the adaptation layer modules 62 a - 62 e also provide a “handle” for the program interface (API) module 60 to call directly to the adaptation layer modules 62 a - 62 e.

FIG. 8 is a class diagram for local hardware objects (e.g. 64 a - 64 e , FIG. 6 ), including definitions of an abstract local hardware class 80 , an exemplary concrete local WiFi hardware class 82 , and an exemplary concrete local UWB hardware class 84 . Exemplary attribute and operation descriptions for the local hardware class 80 are contained in Table 2.

FIG. 9 is a class diagram for local adapter objects (e.g. 65 a - 65 h , FIG. 6 ), including definitions of an abstract local adapter class 90 , an exemplary concrete local WiFi adapter class 92 , and an exemplary concrete local UWB hardware class 94 . Exemplary attribute and operation descriptions for the abstract local adapter class 90 are contained in Table 3.

Exemplary attribute and operation descriptions for the concrete local WiFi adapter class 92 are contained in Table 4.

Returning again to FIG. 6 , the remote device manager module 63 is primarily a “container” for remote device objects 66 a - 66 p containing the attributes of the available remote wireless devices. Thus, operations such as filter remote device list by class, and add/delete remote device are exemplary operations of the remote device manager module 63 .

The remote device manager also prevents a single remote wireless device from being “seen” and presented multiple times in the available remote device presentation, by eliminating duplicate entries and implementing a predetermined preferred connection method logic. This situation might occur when a remote wireless device (e.g. 14 a - 14 p , FIG. 1 ) itself has disparate radios using disparate radio technologies, and each of the remote wireless device radios is “seen” by a different radio (e.g. 12 a - 12 e , FIG. 2 ).

FIG. 10 is a class diagram for an exemplary remote device manager module (e.g. 63 , FIG. 6 ), which defines an abstract remote device manager class 100 , including abstract operations. Exemplary attribute and operation descriptions for the remote device manager class 100 are contained in Table 5.

FIG. 11 is a class diagram for remote device objects (e.g. 66 a - 66 p ), including definitions of an exemplary abstract remote device class 110 , an exemplary concrete remote Access Point device class 112 , and an exemplary concrete remote Wireless USB device class 114 . Exemplary attribute and operation descriptions for the remote device object class 110 are contained in Table 6.

Exemplary attribute and operation descriptions for the concrete remote Access Point device object class 112 are contained in Table 7.

Exemplary attribute and operation descriptions for the concrete remote Wireless USB device object class 114 are contained in Table 9.

D. Enumerate Available Remote Wireless Devices

FIG. 12 is an exemplary time-sequence or call-flow diagram for an “enumerate available remote wireless devices” function of an exemplary method for multi-radio control, according to the invention. As shown, the user interface application module 18 (or a third party application 24 , FIG. 2 ) calls into the intermediate layer (SDK) module 20 via the program interface (API) module 60 . The program interface module 60 sends a request to the local hardware manager module 61 to search for available remote wireless devices. The local hardware manager module 61 receives the request and formats a generic hardware interface request, and sends the generic hardware interface request to each adaptation layer module 62 a - 62 e . Each adaptation layer module 62 a - 62 e asynchronously generates appropriate driver commands to its associated radio driver module ( 22 a - 22 g , FIG. 2 ). The radio driver modules then cause their associated radios to poll for available remote wireless devices, and return a list of the available remote wireless devices to the associated adaptation layer module 62 a - 62 e . Each adaptation layer module 62 a - 62 e then generates a generic response identifying the available remote wireless devices, and returns the generic response to the local hardware manager module 61 , which provides a remote device list to the user interface application module 18 (or a third party application 24 , FIG. 2 ) via the program interface (API) module 60 .

E. Connect to Remote Wireless Device

FIG. 13 is a user connection flow chart according to the invention, including the steps of: S 1302 user requesting a list of available remote wireless devices; S 1304 user selecting an available remote wireless device to which to connect; S 1306 determining whether the remote wireless device requires security credentials to connect; if so, S 1308 user entering security credentials; S 1310 setting security credential for the selected device; S 1312 requesting connection to remote device; S 1314 determining whether the connection requires security credentials; if so, S 1316 user entering security credentials; S 1318 sending security credentials to the intermediate layer module; S 1320 attempting to connect to the remote wireless device; S 1322 determining whether the connection process was completed; if not, S 1324 notifying the user and returning to step S 1302 , or, if so, returning to step S 1302 .

One of ordinary skill in the art will recognize that additional steps and configurations are possible without departing from the teachings of the invention. This detailed description, and particularly the specific details of the exemplary embodiment disclosed, is given primarily for clearness of understanding and no unnecessary limitations are to be understood therefrom, for modifications will become evident to those skilled in the art upon reading this disclosure and may be made without departing from the spirit or scope of the claimed invention.