Patent Application
20050102662
This invention is related to communication systems and more particularly to performing updates, including software and configuration, in the context of wired and wireless networks.
In a typical communication system that includes a wireless communication device updating the device is a time consuming and inefficient process. The device will typically be taken back to the original point of purchase in order to have the update or upgrade installed. Some devices can not be updated or upgraded and, hence, a new device must be purchased.
Furthermore, in situations relating to correction of errors or a “bug-fix” in a software program, the process of replacing the software or altering the phone configuration will be costly and inefficient. Additionally, current systems are not able to track and provide updates information to the device relating to the location of hot-spots and changes relating to hot-spots.
Therefore, what is needed is a system and method for updating a device with current information that allows for the capability for over-the-air downloading of information independent of the location of the device.
A system and method are disclosed that allow information to be transmitted to a device in order to update or upgrade the device. Thus, a client can be updated from a central location in real-time after the client has been deployed. The system and method disclosed in accordance with the present invention also allows for an automated or user initiated updates to software or device configuration.
The method for updating a device includes the steps of initiating communication from the client to a parent server; determining if the client has the most recent update by comparing the time stamp information of at the client with the time stamp information of the current update available at the server; and if necessary, then downloading the necessary information to the client.
The system includes a device that includes at least one updatable component and is capable of transmitting authentication information to a server that is in communication with the device, wherein the server is capable of downloading updates to the device when the device has been authenticated by the server.
Referring now to
In one embodiment, communication is via XML between the client 12 and the server 14 over the Internet 16. A secure communications channel may be desired in at least some instance, such as one exemplary embodiment wherein communications are carried using HTTPS. Such a secure communication can be used in instances wherein the client is providing authentication information required in order to gain access to information controlled by the server 14.
Referring now to
In one embodiment the updater is a part of the server and in an alternative embodiment the updater is in communication with the server but positioned in a remote location, both of which are discussed in detail below.
In an alternative implementation, the CCS handles actual communications traffic (implemented in hardware and/or as a software functionality) as well as sending the update information.
In accordance with the teaching of the present invention the client can be automatically updated the client or the user can initiate and update from the client. Both of these processes are discussed in detail below.
Referring now to
The updater 32 and the DLL relating to the updater 32 is configured to also send key information about the parent server. In some embodiments, it may be desirable to keep to user interface (UI) separate from the updater core. This is not required in all embodiments, and in such embodiments the UI can be retained within the DLL. The parent server is the server that the device initially contacts when the device is turned on or activated for the first time. The URL of the parent server is stored in the client and the parent server has the information about the device stored for authentication reasons. Once the client contacts that parent server, then the client is able to obtain and download updates as determined by the information stored in the device relative to the most current information maintained by the updater.
Once the initial contact has been established between the client and the parent server, thereafter the client will first contact the parent server in order to obtain updates through the updater. In alternative embodiments, the URL for the parent server may also be the same at the URL for the updater when the parent server and the updater are one and the same device. The parent server, in future update sessions, can provide a new URL for the client to contact during that specific update session; at the next update session the client would again contact the same parent server. However, at any time following an update session, the parent server has the ability to provide a new URL to the client and assign the server at the new and different URL to be the parent server for the client for future update communication sessions. Thereafter, the client would contact the new parent server and not the old parent server.
In operation, the updater 32 sends notifications to the correct technology element whenever the updater 32 obtains at least one downloaded file, and the downloaded file is maintained available by the updater 32 until needed for an update session. If an update with more than one file is created on the CCS, the updater 32 can be instructed to download all files within a single transaction. The updater 32 will recognize the update as successful if all files within a transaction were downloaded correctly.
In an alternative embodiment, the updater 32 is configured to send notifications when the updater 32 learns that an update is available on the server or CCS. In such an arrangement, the updated file may be maintained in a repository until the element of the CCS notifies the updater 32 that the element is ready to receive the updated file, at which time the updater 32 facilitates the transfer of the file to the element requesting the update. For example, if a WiFi partner update is received from a carrier, the updater 32 informs the WiFi DLL that there is a new update. The WiFi element can then reload the new update rather than using the old data or information that was previously loaded. Thus, the new update will be available the next time the client initiates an update session and check for updates.
Any component application of the client will be able to register with the updater 32 for the files that it requires and the client manager 34 will be able to register its own components. It will be appreciated that the client manager includes a plurality of software components configured according to the needs of a particular implementation. In one arrangement, the CCS may be configured to tell the appropriate other components of the system what files go to what DLL. In addition, certain statistics may be passed back to the CCS, although alternatively such statistics may be part of the client to infrastructure API, discussed hereinafter. In each instance, the data for registration typically includes a string that represents the type of technology associated with the code, such as WiFi, GPRS, CDMA, location finder, and so on. Version, update or other information can also be provided during this update session.
In each instance, the data for registration typically includes an identification string that represents the type of update the component is requesting, such as WiFi, GPRS or CDMA networks configurations, Location Finder data, and so on. The server generated timestamp of the last successfully downloaded update has to be provided, while software version and other client information is optional.
In one embodiment, there are two interfaces between the client and the network or the Internet in order to reach or contact the server. First, the client talks to the local hotspot for local communication and authentication. Second, a link is established between the client and the service provider for status information, customer provisioning and other push type services that the provider may require to be implemented. With regard to the first interface, there are several different hotspot Application Program Interfaces (APIs) that exist in today's market, including
As indicated above, in addition to the interface between the client and the local hotspot there is the secure link between the client and its service provider. This communication interface enables the client to inform the provider of its current status in its operating environment and allows for the provider to push instructions to the client. The decision on what instructions should be sent to the client is determined based on the client's current status and other information identifying the client as an entity. The service provider can change the logic on what instructions should be sent to the client as often as necessary as the client shall always ask for the most up-to-date decision. The communication link is, at least in some embodiments, via HTTPS. The messages from the client typically contain information about the current state of the device, such as the time-stamp for the latest update. The following UI elements are needed:
In at least some embodiments, the updater 32 is not aware of the client's parent server 30 network connection status or the type of bandwidth that a connection permits. Thus, the updater 32 is not in a position of being able to drive communication with the server. In such embodiments, a control interface is provided which allows for the updater 32 to be told when it can try to check for an update. This interface, which may be in the form of a message, may also inform the updater of the type of connection. Additionally, the control interface allows for a user to initiate a ‘check updates now’ process, which is essentially a manual start to the automated process described above.
Referring now to
The following sets forth examples of the communications between the Updater 50 and the CCS 52; Updater 50 POSTs client information to CCS 52 at path 501:
CCS 52 responds by returning a well formatted XML response specifying the file(s) that are available for download at path 504:
If there are no files available for download, CCS returns an empty files list.
The updater 50 starts downloading file(s) from the specified remote location(s) at path 506 and 508. In addition, a system which incorporates the foregoing invention may also include an API to facilitate communications between the central server and remote devices. The API, which can be used independently, is provided to permit a diverse universe of devices to communicate successfully with the system of the present invention. The following exemplary information is representative of a typical API in accordance with the present invention.
More particularly, this aspect of the invention is directed to the client to infrastructure API for a client capable of seamless roaming among wireless networks, sometimes referred to hereinafter as a “Smart Client” or “Roaming Client”. This interface is designed to allow both pre and post authentication communications between a Smart Client and a carrier's infrastructure.
The majority of providers of paid Wi-Fi services are looking to rapidly augment their native networks through the addition of Wi-Fi roaming partners. The Roaming Client and the CCS provide the ability for a carrier to continually add network authentication and connection logic for each roaming partner and to deploy that logic to users in the field. In addition, a separate provisioning API allows carriers to continue to use their existing self service provisioning and account maintenance website while integrating this capability into the Roaming Client itself. Thus, the present invention permits providers to integrate the Smart Client solution with their network offerings.
Interface Design: States
The interface supports the client sending various connection states to the infrastructure. For example, when the client first connects and is in the pre-authentication state a pre-authentication message is sent. This message will contain the state as given in Table 1 entitled Smart Client STATES and the information from the Info state defined in Table 2 entitled INFO.
Table 2 is merely an example of the types of information that can be send and is not intended as a limitation; various other types of information can be sent such as:
Actions
The Application Carrier interface consists of various actions that can be performed. These actions are passed to the client from the infrastructure after the client sends a status message. These messages can either be embedded inside standard HTML or can be raw XML. These communications are done using HTTPS format though unsecured HTTP format can also be supported. The following is a sample list of the action and in not intended to be an exclusive or complete list of the action:
The CCS allows for a centrally managed interface for the client. The CCS is designed to function as a centralized management point for the connectivity logic of the Roaming Client and allow population of the location finder directory in deployed Roaming Clients. The CCS provides a management console for the administration of this data, or it can be configured to point to third party locations for this type of data. These configuration options of the CCS permit providers to easily incorporate new roaming partner networks into their service offering.
The CCS is able to create new Wi-Fi Roaming partner networks and to distribute this new connection logic to deployed Roaming Clients. The CCS has the functionality to add/remove roaming partners for a Wi-Fi service provider. An exemplary template for achieving this is as follows:
The client can “see” Wi-Fi networks in a manner determined by the CCS; that is, the client sees such networks in the way the CCS “tells” it to. In at least some embodiments, the client is aware of all available Wi-Fi networks, but the configuration information entered through and served by the CCS creates a network information abstraction layer, so the client's users can see information defined by the carrier/provider to which the user subscribes. Each Wi-Fi network is defined by its SSID information, as shown in the template, above. However, the CCS creates configuration files that alias this information and provide additional information presented to the users. Such information includes more detailed network description, starting URL, connection options (Automatic/Prompt/Manual), and so on.
Hotspot API Settings
In one embodiment, the CCS includes the functionality to add/remove hotspot settings for roaming partners for a Wi-Fi service provider. In an exemplary arrangement, hotspots information is maintained through a user-friendly CCS user interface (UI). Typically, although not necessarily in all embodiments, all information is stored in relational database format to provide fast and flexible data search and modification. Further, in a typical arrangement, the update files for hotspots settings are provided in a scalable XML format that allows simple and flexible manipulation on the Client. A template reflecting how a table of hotspots is maintained is show below:
In addition, an exemplary template for adding a hotspot is shown in the table below:
Exemplary code for such a hotspot is show below:
Carrier API Settings
The basic CCS functionality for adding or removing carrier interface settings for roaming partners for a Wi-Fi service provider is described below in an exemplary format.
The CCS provides a convenient and flexible way to define carrier and/or roaming partner specific procedures for authentication and logging into Wi-Fi networks. In an exemplary arrangement, each network can have any number of API settings defined for it. The API settings are expressed in the form of Authenticator objects and associated parameters. Each Authenticator can have any number of parameters. Using this mechanism, CCS provides a mean to dynamically change the way the client operates in different network environments. Flexible configuration files (see below) allow defining any number of Authenticator objects which are executed in the order of significance. If the Authenticator object with higher priority fails, the Client automatically instantiates the next Authenticator from the list. Exemplary code for such an Authenticator is illustrated below:
Sign Up Procedure
Referring now to
At step 1 of
At step 2, the application parses HTTP response and stores provider, location, error and other provided information (the implementation of this step is provider/NAS specific).
At step 3, the application POSTs information to the Web Portal about the current status, location, etc.
At step 4, the Web Portal determines a set of actions that should be performed by the application (a standard set of actions is presented Table 1.). In this case, the carrier Web Portal sends ‘launchMiniBrowser’ action and defines URL that should be used to initiate new user sign up procedure.
At step 5, the ‘IlaunchMiniBrowser’ action accepts three parameters: url, width and height. Width and height values are specified in pixels. The application will typically, though not necessarily, position branded Mini Browser window in the center of the user's screen. If width and height values are not provided or contain illegal values, Mini Browser window size defaults to 640×480 pixels.
At steps at 5a-5d, the portal provides one or more steps for setting up a new user account. The user has a freedom to navigate and select different options by interacting with the presented HTML pages. Branded Mini Browser is “listening” for a new set of actions that will end the sign up procedure.
At steps 6 the Web Portal returns one or more actions as part of the embedded XML. In HTTP response, ‘ApplicationActions’ custom HTTP header is set to ‘yes’—therefore, Application Client parses and executes embedded list of actions.
At step 7, the APPLICATION Client attempts the login procedure after prompting the user to confirm password.
At step 9, the system indicated if the login procedure succeeded.
At step 9, the APPLICATION Client POSTs new status information and all relevant data to carrier Web Portal.
*)POST information is formatted with CR/LF for clarity
At step 10, the Web Portal parses APPLICATION information and determines if further actions should be performed by the authenticator. This is also a moment when customized advertisement content could be pushed back to the user.
Returning User
In an example wherein the user is and already has an account, then the client will start the connection with a status update of loggedIn. This message will pass appropriate information to the central system in a manner analogous to the new user described above.
Referring now to
At step 632, it is determined by the system if the parent server will not longer act as the first point of contact. If a new parent server is to be designated, then at step 636, the current parent server will provide a new URL to replace the pre-programmed URL and the client will, thereafter, initiate update communication sessions with the new parent server located at the new URL. On the other hand, if a new parent server is not needed or designated, then the current URL that is pre-programmed in the client remains unchanged at the process ends at step 640. It is worth noting that in alternative embodiments the parent server provides a new URL during the authentication step, which is at step 608, because a new parent server at a new URL has been designated since the last communication session or since the client was pre-programmed, if the first communication session has not been initiated. In this case, the server can either authenticate the client and pass the remaining portion of the communication session to the new parent server at the new URL or, in the alternative, the parent server can update the client with the new URL and instruct the client to initiated a new communication session with the new parent server.
Having fully described various embodiment and various alternatives, those skilled in the art will recognize, given the teachings herein that numerous alternatives and variations exist that do not depart from the invention. It is therefore intended that the invention not be limited by the forgoing description and only by the following claims.
This application claims the benefit of and incorporates by reference U.S. Provisional Patent Application Ser. No. 60/504,152; entitled “Automated Updating System for Wireless Networks”.
| Number | Date | Country | |
|---|---|---|---|
| 60504152 | Sep 2003 | US |
