1. Field of the Invention
The present invention relates to the field of establishing computing communication between computing devices and available communication networks (including dedicated connections) at different locations. In particular, the present invention applies to computing devices such as mobile devices (e.g. laptops, cellular telephones, and personal digital assistants (PDAs) and other client devices having limitations in terms of processing power and/or display screen size.
2. Introduction
As processor, memory and other computing components have become ever smaller and less costly, newer generations of computing devices have become available beyond conventional desktop systems. The newer generations of computing devices include mobile computing units such as personal digital assistants and smart cell phones, but also include a wide range of additional devices and appliances having embedded processing and data communication capability.
These computing devices are generally designed to be able to communicate with a data network, via one or more wired or wireless communication links. It is not uncommon for a single user to have an computing device connectable to one or more other computer systems and/or servers, such as by wireless connections (Bluetooth, IrDA), local area networks (LAN, direct or wireless (WIFI—802.11 and GPRS (General Packet Radio Service) and traditional dial-up modems (e.g. PPP (Point-to-Point protocol), USB, GSM (Global System for Mobile Communication) etc.). A number of different communications protocols exist for connecting computing devices to one another. Typically, most devices are configured to facilitate only a particular type of connection selectable manually by the user.
What is needed in the art are improved connection schemes and a mobile device configured that is configured to automatically connect it to a best available network at a particular location.
Additional features and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth herein.
In a first aspect, the present invention provides a method of enabling an execution thread of an application running on a computing system having communication capability and a plurality of communication software modules to access a communication service that enables data communication between the computing system and a network. In one or more embodiments, the method includes selecting a connection profile including a sequence of references to one or more of the plurality of communication software modules for setting up a connection that uses the communication service and attaching the execution thread to a data channel associated with the connection profile, wherein the selected connection profile defines steps for setting up the connection that uses the communication service.
In a second aspect, the present invention provides a computing system or device having processing capability for running an application having one or more execution threads and communication capability. In one or more embodiments, the computing device comprises connection management logic including i) a database for storing a plurality of connection profiles and ii) server logic adapted to receive a request from the application for a communication service, select a connection profile from the database that supports the requested communication service, and attach one of the one or more execution thread of the application to a data channel associated with the connection profile. The computing device further includes a user interface enabling user input for modifying the plurality of connection profiles.
In order to describe the manner in which the above-recited and other advantages and features of the invention can be obtained, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments thereof, which are illustrated in the appended drawings. The present invention will be described and explained with additional specificity and detail through the use of the following drawings.
Various embodiments of the invention are described in detail below. While specific implementations involving computing mobile devices (e.g., portable computers) are described, it should be understood that the description here is merely illustrative and not intended to limit the scope of the various aspects of the invention. A person skilled in the relevant art will recognize that other components and configurations may be easily used or substituted than those that are described here without parting from the spirit and scope of the invention.
The computing device may be configured to execute instructions, such as program modules, which may include routine programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types or functions. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
With continued reference to
The computing device 100 also includes a basic input device 152, such as a keyboard or a touch screen that is used to receive data from a user. The computing device 100 further includes a basic output device 154, such as a display screen, to display user interfaces (UI) and other information to the user. A storage device 160 such as a hard drive may also be included.
Lastly, the computing device 100 includes a communication interface 180 to communicate with a communication network. Examples of a communication interface 180 include wireless communications hardware (e.g., GPRS (General Packet Radio Service), WiFi, etc.) and direct communications hardware (e.g., dial-up modem and direct LAN connection).
In the example where the computer system 100 comprises a mobile device, a communication link may be coupled to a cradle or cable dock (not shown) associated with the mobile device for receiving and initiating communication with computer system 100 over a communication line. The cradle provides an electrical and mechanical communication interface or link between the computing device 100 and a network for two-way communications. In one exemplary embodiment, the communication link including the cradle and the line may comprise a serial communication link or a USB link. The computing device 100 may also contain a wireless infrared communication mechanism for sending and receiving information to or from other devices with which communication is desired.
In one embodiment of the present invention, the communication link may be a serial communication port, but may also be any of a number of well-known communication standards and protocols, e.g., parallel, SCSI, Firewire (IEEE 1394), Ethernet, etc. The computing device 100 may also include one or more other wireless communication mechanisms, e.g., cellular phone, Bluetooth and/or wireless LAN (e.g., IEEE 802.11), for instance, all of which may be used to establish the communication link between the portable computer system 100 and the host computer or with the Internet directly.
The ROM 140 may store operating system and application code that defines an Input/Output system based on a framework for establishing communication. In some embodiments, the STREAMS framework is employed which is an established framework for building modular communication protocols. Alternatively, other network architectures known to those skilled in the art may be used instead of a STREAMS framework. In accordance with the embodiment disclosed here, when an application that is running on the computing device issues a request to initiate a connection, STREAMS drivers and modules known to those skilled in the art are opened and linked together. For example, communication may be initiated by opening a serial port, which is opened by opening a STREAMS driver. A connection to the Internet may be established by opening and linking several drivers or modules, depending on the technologies that are used to access the Internet. The STREAMS framework and the IOS (Input/Output System) do not necessarily define a service or library that assists the applications and the system to build STREAMS stacks, and therefore, in some embodiments, the applications and system do not directly interact with STREAMS drivers and modules.
Moreover, in some embodiments of the present invention, useful connection information (for example: serial port baud rates, PPP passwords, dial-up phone number, etc) is stored. To establish connections effectively, this information is stored such that it may be readily accessed. This information may also be stored such that it may be easily edited by the user.
Referring to
In some embodiments, the connection manager 200 includes a connection manager server 202 and a connection database 204 and a group of plug-in modules 206. In alternative embodiments, the connection database 204 may be a separate component. The connection manager 200 may be based on a Linux operating system platform.
The connection manager server 202 manages connections and communicates between the application layer and lower level components including Linux communication protocols and system hardware. The connection manager server 202 is communicatively coupled to the connection manager database 204 which includes a plurality of connection profiles that the connection manager server 202 employs to establish a network connection. The connection manager server also performs write operations to the connection manager database 204 including the creation and/or deletion of connection profiles in the connection manager database 204. In some embodiments, the connection manager server also monitors and controls currently-utilized (‘connected’) profiles, and is adapted to disconnect designated connected connection profiles as needed. The connection manager server 202 may also manage security information.
When connecting, disconnecting or controlling connection profiles, the connection manager server 202 may call the plug-in modules 206 comprise program code for implementing specific processes used in configuring, establishing and/or controlling a connection. For example, an IP (Internet Protocol) plug-in may be used to assign an IP address to interfaces and to create default routes while a PPP (Point-to-Point Protocol) plug-in may be used to run execute a point-to-point protocol connection process. Plug-in modules 206 may reside in standard directories and may make use of standard Linux commands such as pppd (Point-to-Point Protocol Daemon) and udhcpc (Very Small Dynamic Host Configuration Protocol), or may directly call shell scripts containing a series of commands. A shell script or command called by a plug-in 206 may be invoked to retrieve information (‘results’) which are then delivered back to the connection manager server 202. For example, a shell script associated with the udhcpc command may be invoked to retrieve a local IP (Internet Protocol) address given by the DHCP server.
The connection manager server 202 may run as a privileged user (root) so as to be able to configure network and other communication components, and may commence at Linux boot time, by the init program. Upon execution, the connection manager server 202 first enumerates and then dynamically loads plug-in modules 206.
The connection manager database 204 stores a number of different records including plug-ins, interfaces, edges, connection profiles, templates and links. Each plug-in in the plug-in modules 206 has an associated record in the connection manager database 204. Each of the plug-ins, in turn, may define anchors or interfaces where connection profiles may be attached. For example, network connection profiles may be attached under a “!NetOut” plug-in. Interface records include the anchors of the plug-ins but may also be used to group several plug-ins/interfaces under a single identifier. Edges are records that are used to form a connection between plug-ins and interfaces. The connection profiles themselves include a sequence of references to the plug-ins and interfaces defining how to connect a device or a network interface. The connection profiles may include parameters for each reference and may be implemented in the form of a string. Templates are records used to create new profiles and links are objects that are used to reference other objects.
The connection manager database 204 may be implemented as a Linux regular file which may be protected by Linux rights (e.g., readable and writable by root). In some embodiments, the connection manager 200 is configured to ensure that the connection manager server 202 is the only process that accesses the connection manager database 204. Sensitive information in connection profiles such as passwords may be handled by a security vault. In addition, to accelerate searches, the connection manager server 202 may keep in memory a cache of the system names and IDs of all connection profiles.
The connection manager also includes a library 208 that provides facilities to application and services via an application program interface (API), a Linux command ‘cnc’ 210 that is used by scripts to communicate with the connection manager server 202 (e.g., to send parameters of a connection such as a local IP address), and a connection hook 212 that allows users to override automatic connection and sharing mechanisms.
The plug-in modules 206 contain code related to managing one or more communication devices or protocols and may define several individual plug-ins. For example, the plug-in modules 206 may define a TCP/IP plug-in, a PPP plug-in, a Bluetooth plug-in, etc. Plug-in modules 206 may be identified by a file name, an internal name, a version, an entry point, a list of plug-ins contained in the module and UI (User Interface) objects common to all the plug-ins in the module. The plug-ins modules may be implemented in the form of Linux shared-code modules or libraries.
An individual plug-in, e.g., Plug-in 1, Plug-in 2 may be defined by a (1) system-unique name and an ‘internationalized’ name (e.g., Bluetooth), (2) a connection call back that cooperates with Linux functions to start services or protocols and open devices, (3) a control call back for managing disconnection, dynamic availability, priority, modification requests, and (4) additional optional configuration parameters.
The connection manager server 204 may enumerate the plug-ins in each plug-in module (e.g., plug-in 1 in module 1, plug-in 2 in module 2) upon initialization (boot time) and may load the plug-in modules 206 in an arbitrary order. In addition, the connection manager server 204 may issue ‘requests’ to the plug-in modules 206 to register by calling the plug-in module entry points. Plug-ins modules 206 may delay the registration process to resolve problems caused by plug-in dependencies. For example, when multiple plug-in modules 206 have the same identification, the newest version may be used, allowing for updating of plug-in modules 206 residing in ROM with updated version in RAM.
After a plug-in module (e.g., module 1) has been loaded in a process, the connection manager server 202 calls the module entry point with commands to initialize and register. If the module is unable to complete registration, a “registration_done” flag is set to false. In this manner, the connection manager server 202 is made aware that the plug-in module did not successfully register so that the connection manager server knows to call the module entry point again if the plug-ins within the module are called upon. Once a plug-in module is registered, each plug-in of the module has an associated record in the connection manager database 204 and a unique database ID.
In general, when an application issues requests to establish a connection with a network or device, the application selects a suitable connection profile, routes network traffic to the selected profile and uses DNS servers associated with the selected connection profile (all performed whether or not another connection is active). According to the present invention, data channels enable applications and services to take advantage of the suitable connection profiles. An application program interface is provided which allows application to access the connection manager 202. Each application thread being executed can open a data channel or ‘bind’ to an already open data channel. At any given time, a thread can be bound to either one data channel or not bound to any data channel. A thread can also switch from one data channel to another data channel at any time. This is facilitated by the use of a profile tag that records the services supported by a given connection profile. Applications requiring specific services may be thereby directed to use a suitable connection profile. If no suitable profile exists to specifically facilitate the service, the application may fallback on general connection profiles (i.e., profiles with no tags).
To tag network connection profiles with one or more services, a licensee or carrier may add a ‘srv0’ parameter to the NetOut? plug-ins of the connection profiles. In one embodiment this can be performed when the connection profile is created with ‘cnc’ commands alp_cnc_profile_decode( ), or later with alp_cnc_profile_set_parameters( ). The ‘srv0’ parameter value may be a 32-bit integer where each bit represents a service. A connection profile having a tag value of zero or no tag at all may be presumed to be a general connection profile. The list of supported services and links can be extended. For example, if more than 32 kinds of services are requested, the list can be extended by adding other parameters (e.g., ‘srv1’, ‘srv2’).
The connection profiles may be ordered in terms of priority according to the link they use. In one embodiment of the present invention, the connection profiles may be numerically ranked as follows:
However, it is noted that the priority of a connection profile can be modified by the user through the connection manager 200. A separate list is made of connections profiles to be followed in trying to establish connections. This list takes into profile priority as well as data received from plug-ins such as link status. An example of adjustment to priority would be according a wireless or cellular connection profile a higher priority than Ethernet connection (usually the reverse) if mobility is a more important consideration than power consumption.
Data traffic routing is another major function of the connection manager 200. When a thread is connected to a data channel, a plug-in may create a sub-table in a main routing table that defines a subnet rule for delivering traffic through an interface and a default gateway for the connected interface. The threads are automatically bound to the channel which they open. A plug-in can also configure a rule in the main routing table to associate traffic explicitly to use the sub-table associated with the interface. This allows applications to bind their sockets to the interface and to use the correct default gateway. A thread can be bound to an established data channel. This causes future socket calls in the thread to bind to the interface associated with the bound data channel. This will allow for all the traffic of the thread to be routed through the correct interface and gateway. Applications that run multiple threads can bind each thread to a different data channel. An application may request a specific channel for well-known servers; this may be accomplished by adding a rule in the main routing table that indicates that a particular channel interface is to be used when contacting a specific host.
The connection manager server monitors the DNS servers associated with the various data channels that are in use. At the time a data channel is connected, a plug-in may bind each DNS server to the data channel. This ensures that DNS requests to specific DNS servers are routed to the proper interface using the correct gateway. When a thread is bound to a data channel, a standard resolver in the thread may use the DNS servers and domains associated with the data channel. This is accomplished by changing, after initialization, a _res thread variable used by the standard resolver.
Referring again to
The connection manager hook 212 may also be used to implement new mechanisms (such as automatic connection switching) and/or customized algorithms (like a custom carrier/licensee fallback mechanism), to do this the connection manager 200 may be configured so that the built-in connection algorithm is ‘hook-able’. The connection algorithm may call the connection manager hook 212 (hook function) in distinct situations. In the event of a connection request, the connection manager hook 212 may selected a connection profile to connect to and can additionally disconnect an already active connection, for example, if a carrier does not support multiple connections at a time. The connection manager hook 212 may also be called if a fallback occurs the hook function can choose the next profile to attempt connection with, overriding the default fallback mechanism, when the connection state of a connection profile changes, to maintain connectivity or establish a connection with a connection profile with higher priority. When a connection profile is connected or an error condition is reached, this allows the hook connection variables to be freed. Other situations in which the connection manager hook 212 may be called include when a connection that was not shared is made to be shared, if a connection that is shared is to be unshared. The entry point of the connection manager hook 212 may be called with a command number and parameters according to the particular situation. The function may return a hook Boolean representing the condition (hooked or not hooked) and additional parameters depending on the situation. If the condition is “not hooked”, then default built-in code may be executed.
The application level of the connection manager 202 may include a connections preferences panel 214 and a network status bar sliplet 216. The connections network panel is a user interface to the connection manager server 202, enabling the user to create, change or delete connection profiles as well as various administrative functions for the program. The network status bar sliplet 216 provides the user with the status of connections and enables the user to specify connection profiles to be connected. Although the above description may contain specific details, they should not be construed as limiting the claims in any way. Other configurations of the described embodiments of the invention are part of the scope of this invention. Accordingly, the appended claims and their legal equivalents should only define the invention, rather than any specific examples given.
The present invention claims the benefit under 35 U.S.C. § 119(e) of U.S. Provisional Patent Application No. 60/888,534 filed on Feb. 6, 2007, the contents of which are incorporated herein by reference and are relied upon here. In addition, the present application is a continuation-in-part of U.S. patent application Ser. No. 11/055,491 (Attorney Docket No. 4004.Palm.PSI), entitled “A System and Method of Managing Connection Between a Mobile Device and an Available Network”, filed on Feb. 9, 2005, which is incorporated by reference in its entirety.
Number | Date | Country | |
---|---|---|---|
60888534 | Feb 2007 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 11055491 | Feb 2005 | US |
Child | 12025054 | US |