Firmware upgrade system and method in a device management architecture

In one embodiment, a device firmware upgrade scheme is disclosed for upgrading a device image of a mobile communications device. A device management session is established between the mobile communications device and a first server using a first protocol. Upon obtaining identity information of a second server operable to compute or otherwise determine a customized upgrade process, a device inventory is transmitted to the second server using a second protocol. Upon receiving the customized upgrade process, the mobile communications device downloads one or more upgrade files from one or more resources. Thereafter, the mobile communications device is operable to provide a status indication to the first server using the first protocol.

FIELD OF THE DISCLOSURE

The present patent disclosure generally relates to device management techniques. More particularly, and not by way of any limitation, the present patent disclosure is directed to a firmware upgrade system and method operable in a device management architecture.

BACKGROUND

Many carrier network operators are deploying Open Mobile Alliance (OMA) Device Management (DM) (OMA DM) compliant implementations of Firmware Upgrade Over The Air (FOTA), a standards-based approach to upgrading core device software wirelessly. However, there are some aspects of the OMA DM FOTA model that limit its effectiveness for certain handheld devices such as, e.g., smart phones or any handset with a complex firmware definition.

DETAILED DESCRIPTION OF THE DRAWINGS

The present patent disclosure is broadly directed to a device firmware upgrade scheme that facilitates integration of third party upgrade service logic within existing industry-standard OMA DM platforms. Additionally, the embodiments herein allow for handing complex device image information in computing customized device upgrade patches, including upgrading of full size executable files. Broadly, a device management session is established between a mobile communications device and a first server using a first protocol, whereupon identity information (including such as, e.g., location, address, resource name/path, URI/URL information, etc.) of a second server adapted to compute customized upgrade processes is obtained by the mobile communications device. Device inventory information is then transmitted to the second server using a second protocol. Upon receiving the customized upgrade process, which includes identity information of one or more resource locations having appropriate content servers, the mobile communications device downloads one or more upgrade files from the identified resource locations as needed. Thereafter, the mobile communications device is operable to provide a status indication to the first server using the first protocol.

In one aspect, an embodiment of a device firmware upgrade method practiced by a mobile communications device is disclosed. The claimed mobile communications device obtains from a first server, using a first protocol, identity information of a second server adapted to compute, calculate or otherwise determine a customized upgrade process with respect to a device image of the mobile communications device. The mobile communications device transmits device image information relating to the device image to the second server using a second protocol. Thereafter, the mobile communications device receives an upgrade process from the second server, wherein the upgrade process is customized relative to the mobile communications device and includes identity information of one or more resources. The mobile communications device downloads one or more upgrade files from one or more resources based on the upgrade process. Upon completion of upgrading at least a portion the device image, the mobile communications device may provide a status indication to the first server using the first protocol.

In another aspect, an embodiment of a mobile communications device is disclosed. The claimed embodiment of the mobile communications device includes, among others, a processor and one or more subsystems and associated software/firmware, which may be configured as components adapted to perform the following functions: engaging in a device management session with a first server using a first protocol and to obtain from the first server identity information of a second server adapted to compute, calculate or otherwise determine a customized upgrade process with respect to the mobile communications device; transmitting device image information relating to a device image associated with the mobile communications device to a second server using a second protocol; processing information defining an upgrade process received from the second server, wherein the upgrade process is customized relative to the mobile communications device and includes identity information of one or more resources; downloading one or more upgrade files from one or more resources based on the upgrade process; and upon completion of upgrading at least a portion the device image based on the one or more upgrade files, providing a status indication to the first server using the first protocol.

In a still further aspect, an embodiment of a device firmware upgrade server is disclosed. The claimed embodiment of the device firmware upgrade server includes, among others, a processor and one or more subsystems and associated software/firmware, which may be configured as components adapted to perform the following functions: processing device inventory information received from a mobile communications device; determining or computing a customized upgrade process with respect to the mobile communications device based on the device inventory information; and transmitting the customized upgrade process to the mobile communications device, wherein the customized upgrade process includes identity information of one or more resources having one or more downloadable upgrade files for the mobile communications device.

A system and method, as well as associated device, computer-accessible media, and network node, of the present patent disclosure will now be described with reference to various examples of how the embodiments can be made and used. Like reference numerals are used throughout the description and several views of the drawings to indicate like or corresponding parts, wherein the various elements are not necessarily drawn to scale. Referring now to the drawings, and more particularly toFIG. 1, depicted therein is an exemplary network environment100wherein an embodiment of the present patent application may be practiced for purposes of device firmware upgrade and management, inter alia. Network environment100comprises, inter alia, a network infrastructure110and at least one client device102such as, e.g., a mobile communications device (MCD), in communication with the network infrastructure110via a communications link103. The principal task of network infrastructure110for purposes of the present disclosure is to provide one or more communication paths between a client device102, that requires device management/upgrading, and one or more nodes or entities that operate as servers with respect to one or more aspects of device upgrading and management as will be set forth in detail hereinbelow. Network infrastructure110may comprise one or more networks which may be implemented using any known or heretofore unknown technologies and architectures, and may for example include any combination of wired networks, wireless networks, short-range or long-range radio frequency (RF) networks, carrier networks, access networks, core networks, enterprise networks, circuit-switched networks, or packet-switched networks. Any of these may span one or more geographic sites and be organized as a local area network (LAN), wide area network (WAN), metropolitan area network (MAN), or Wireless LAN (WLAN), alone or in any combination, and may include elements of intranets, the Internet, and any other suitable private, carrier, leased, or virtual private network (VPN) facilities, alone or in any combination. Where a wireless network is included, it may for instance be comprised of a General Packet Radio Service (GPRS) network that provides a packet radio access for mobile devices using the cellular infrastructure of a Global System for Mobile Communications (GSM)-based carrier network. In other implementations, the wireless network may comprise an Enhanced Data Rates for GSM Evolution (EDGE) network, a Long Term Evolution (LTE) network, an Integrated Digital Enhanced Network (IDEN), a Code Division Multiple Access (CDMA) network, a Universal Mobile Telecommunications System (UMTS) network, any 2nd- 2.5- 3rd- or subsequent Generation networks, a WLAN network employing WIFI or WIMAX technologies, or any other suitable wireless network. Communications link103may be realized as any suitable wireless network connection. Communications link103could also be realized via suitable wired means in some implementations.

The network environment100may include one or more Device Management (DM) servers, e.g., servers104-1and104-2, as well as one or more content servers (which may also be referred to as download servers), e.g., servers106-1and106-2, that host one or more device upgrade files that can be downloaded to the client device102pursuant to an appropriate set of procedures and techniques. In an embodiment, DM servers104-1and104-2are compliant with OMA Device Management procedures and techniques, and files are downloaded to the client device102pursuant thereto. Accordingly, communications relative to device management and firmware upgrading involving the client device102and one or more DM servers104-1,104-2and one or more content servers106-1,106-2are effectuated using a first protocol, e.g., the OMA DM protocol. In one arrangement, the DM servers104-1,104-2and the content servers106-1,106-2may be deployed as part of a carrier network implementation.

Further, the network environment100may also include one or more enhanced device upgrade servers adapted to execute device upgrade procedures that can manage complex device images, wherein the complex device images may include but is not limited to exhaustive device inventories such as software/firmware versions of various pieces of software (e.g., application programs, non-application programs, operating systems, kernels, drivers, protocol stacks, et cetera), user preferences, device status (e.g., as to what is installed), as well as other device- and/or manufacturer-specific information, for purposes of computing or otherwise determining one or more customized upgrade recipes or processes for a client device. In one implementation, the customized upgrade process may also include appropriate information for identifying or locating a resource from which the device upgrade files may be obtained (i.e., one or more download servers that actually host the downloadable device upgrade files). For example such information may include but is not limited to information relating to addresses or locations, Uniform Resource Locators (URLs), Uniform Resource Names (URNs), Uniform Resource Identifiers (URIs), or other resource paths, et cetera; collectively referred to as “identity information” herein. One or more implementations of how an “upgrade process” provides the identity information to a client device will be set forth in detail below. By way of illustration, enhanced upgrade servers108-1,108-2exemplify the servers having the service logic necessary for computing or determining customized upgrade recipes based on complex device image data according to an embodiment of the present disclosure. Likewise, reference numerals109-1and109-2refer to illustrative enhanced content servers operating as download servers that host appropriate content (e.g., one or more device upgrade files) for purposes of upgrading at least a portion of the device image of a client device such as MCD102.

Although the content servers109-1,109-2are shown inFIG. 1as separate entities, at least part of their functionality may be co-located with functionality of one or more of the enhanced device upgrade servers108-1,108-2in certain implementations. Further, any of enhanced upgrade servers108-1,108-2may also include service logic to compute or determine a customized upgrade recipe that may involve downloading of an upgrade file from a content server such as106-1which is compliant with the first protocol (e.g. an OMA-compliant protocol). Additionally, communications involving the client device102and one or more enhanced upgrade servers108-1,108-2and one or more enhanced content servers109-1,109-2may be effectuated using a second protocol that is different than the first protocol used with respect to the DM servers104-1,104-2. In one arrangement, the enhanced device upgrade servers108-1,108-2and/or the enhanced content servers109-1,109-2may be deployed as part of a vendor-specific or manufacturer-specific server implementation that is seamlessly interoperable within an existing arrangement that is compliant with the first protocol (e.g., OMA DM).

As is well known, device management pertains to, inter alia, configuration, provisioning client applications, and detecting problems of handheld communications devices from servers. In general, device management aims to encompass at least the following functionalities: (i) bootstrap provisioning, remote maintenance, and reporting of configuration data to a device; (ii) device diagnostics and fault management; and (iii) application and non-application software/firmware installation, update/upgrade, and management.

By way of example, an OMA-complaint DM methodology is set forth below although the teachings herein are equally applicable to other DM protocols and methodologies, mutatis mutandis. Each device that supports OMA DM contains a management tree, a structure that includes and organizes all the available management objects in a nodal arrangement such that each node can be directly accessed through a unique identifier such as a URI, wherein the nodes are entities that may be manipulated through the OMA DM protocol. Typically, two protocol phases are effectuated: a setup phase and a management phase. In the setup phase, an Alert (Packet 0) may be sent by a DM server to the device, whereupon the device client initializes (Packet 1) with the server using its credentials as well as device information. Thereafter, a server initialization process may take place using the server credentials, followed by initial management operations or user interaction commands from the server (Packet 2). In the management phase, the device client may generate one or more responses towards the server with respect to the management operations (Packet 3). In subsequent packets (e.g., Packet 4), more user interactions or management operations may take place if the DM session continues.

With respect to device firmware upgrading, the process may be initiated by a device client, a DM server, or by way of a user-initiated procedure. A companion management object in accord with the Firmware Update Management Object (FUMO) specification is provided that includes certain commands operable to be executed within the OMA DM protocol sessions for effectuating firmware upgrading. In a typical implementation, the DM server may use the FUMO protocol to first determine if an update is possible, using the identity information of the device, and then sets the FUMO object properties to define the update and the location of the download descriptor. Once the FUMO object properties are set, OMA DM requires that the server issue an EXEC command on the FUMO object (e.g., using a Synchronization Markup Language or SyncML based protocol). Upon receipt of the EXEC command, the device client is operable to retrieve the download descriptor and then proceed to download the actual upgrade/patch files listed in the descriptor from a download server (i.e., a content server). Once the files are downloaded, the device client can utilize other on-device facilities to apply the upgrades/patches to the software on the device. Typically, at various points in the update process, the device client may issue one or more status reports back to the DM server.

A number of potential scenarios for running an OMA DM firmware upgrade process using FUMO are set forth below.

Scenario I: Out-of-band download and immediate update: An EXEC command is issued to the device client by the DM server to operate on a specific node (DownloadAndUpdate node) within a FUMO tree portion (or sub-tree, as the case may be) of the management tree. This causes a download agent to be executed. After the download agent has completed its execution, an update agent is invoked. Upon the completion of the update agent, an Alert may be sent back to the DM server.

Scenario II: In-band download and immediate update: The upgrade package data is sent to the device in-band (i.e., during the management phase) and then an EXEC command is issued to the device client to operate on a specific node (Update node) in the FUMO tree. This action causes only the update agent to be invoked. After the update is complete, an Alert may be sent back to the DM server.

In the “out-of-band” Scenario I, a file describing the update is downloaded first, and it is passed on to the update agent of the device to handle at some later time (possibly chosen by the user, or otherwise, for example). Once the update agent is ready to proceed, it then downloads the upgrade/patch data or package and begins to process it. In the “in-band” Scenario II, the actual upgrade/patch data is downloaded and the update agent begins processing the data directly without the need for a descriptor file.

Scenario III: Out-of-band download, followed by an eventual update: This scenario requires two EXEC commands to be run. The first EXEC command is run on a Download node in the FUMO tree of the device, which causes the download agent on the device to download the upgrade package data. After the download is complete, an Alert may be sent back to the DM server. Thereafter, at some future time, the DM server issues another EXEC command to the device for execution on the Update node of the FUMO tree. This action causes the update agent to be executed. After the update is complete, an Alert may again be sent back to the DM server.

The package data may include a meta package definition file that contains properties operable to affect the entire software package including all application packages to be upgraded. Typically, the meta package definition file has information relating to each application package which identifies the application properties such as, e.g., the name of the application, the application URL, a version for the application package, etc.

An illustrative device upgrade process is described hereinbelow. A client device such as MCD102may be initially configured with DM bootstrapping information during the provisioning process. The bootstrap information may include, for example, the identity of the DM server (e.g., DM server104-1) and identity of the device, respective authorization/credential information, and security bootstrapping parameters such as cryptographic keys. Such information may be recorded on or installed in the client device using any appropriate technology and in any appropriate manner. For example, it can be manually entered, embedded at the point of manufacture, loaded into storage of the device using other software and configuration update techniques (e.g., from a computer via a cable or network connection by a technician at a service facility or by the user), or loaded via a smart card or a removable Subscriber Identity Module (SIM). The DM server104-1is operable to control future interactions with the DM client software running on MCD102through the preparation of appropriate Markup Language (ML) documents (e.g., Extensible Markup Language or XML, Synchronization Markup Language or SyncML documents, etc.) and their transmission to the client device102either through a “Push” server (which can use Wireless Application Protocol (WAP), Short Messaging Service (SMS) or other transports), or in response to a device/client-initiated session (typically using a secure protocol such as secure HyperText Transfer Protocol (HTTP) or HTTPS). Using a SyncML channel (i.e., an HTTP connection over TCP/IP that is used for exchanging SyncML documents) or any other Markup Language channel, the server can query and set various properties of the management objects on the device. In particular, these objects allow the server to obtain the handset model, manufacturer, hardware identifier and software version, inter alia. Once an update is loaded into the OMA DM infrastructure, the management server can also use the SyncML channel to set parameters of the FUMO object controlling a possible update, including descriptive information, priority and the identity of the location of a “download descriptor” that defines where the device can obtain the files needed for an update.

A simplified progression of the steps in updating a device according to one embodiment which generally corresponds to Scenario I above may be set forth as follows:1. DM bootstrap information including server ID and credentials is injected on the device (i.e., the handset), e.g., at the point of manufacture.2. The DM server uses a Push server to push a request to the handset client that it initiate a session with the DM server.3. The handset client opens an HTTPS session with the DM server.4. The DM server uses the session to request device identity and version information from the handset.5. The session is closed.6. At some later point in time, the OEM provides an update package to the carrier DM server.7. The carrier operator requests the DM server to initiate an upgrade of the device.8. Steps 2-4 may be repeated to open a DM session and verify that the device identity and version information has not changed (as an optional sanity check).9. The DM server uses the session to set the URL for the download descriptor in the device FUMO object.10. The DM server issues an EXEC on the FUMO update.11. The device client uses an HTTPS session to retrieve the download descriptor from the download server. It should be noted that the use of a download descriptor is optional and the URL can point directly to the patch data.12. The device client uses further HTTPS sessions to retrieve the patch data from the download server.13. The device client uses the downloaded patch data to allow the handset to perform the upgrade.14. The device client uses HTTPS to notify the DM server that the upgrade is complete.

One skilled in the art will recognize that although only HTTP(S) over TCP/IP transactions have been illustrated in the foregoing, other transport mechanisms may also be implemented in certain embodiments. Further, the foregoing upgrade process, which may be compliant with OMA DM, SyncML or other device management protocols, may involve additional steps as well, and some of the illustrated steps have been simplified for purposes of the present patent application. Additionally, not all steps may be put into operation in a particular implementation.

Referring now toFIG. 2, depicted therein is a message flow diagram200relating to a conventional device firmware upgrade process in accordance with OMA DM that captures at least a subset of the steps described above. By way of example, an information request202(which could be an SMS message in one embodiment) from a first server (e.g., DM server104-1) and a device response204including a device type and version from a device (e.g., MCD102) are illustrative of a setup phase prior to establishing a device upgrade session therebetween. Another SMS message206from server104-1commences a session, whereupon an upgrade URL and other information may be transmitted (message path208) to the client device102, wherein the upgrade URL is indicative of the address location of a download descriptor file (DDF). A suitable FUMO EXEC command210is then issued to the client device102, responsive to which appropriate download/update agents may be invoked. A Fetch command212may be issued by the client device102towards a server, which may in one implementation be the same as the first server104-1, in order to obtain (message path214) the URL(s) relating to one or more upgrade/patch files. Depending on the address information obtained, the client device102issues a File Fetch message216to one or more content servers (e.g., server106-1). Responsive thereto, patch files or full size upgrade files are downloaded (message path218) from appropriate servers, whereupon the applicable software/firmware code on the device is upgraded accordingly. Thereafter, a status message220may be issued to the first server104-1. Optionally, a status message222may also be issued to the content server(s)106-1from which the patch files have been downloaded.

As one skilled in the art will recognize, patch files describe differences or “deltas” between two versions of a file, and in some embodiments contain a concisely-expressed list of directives in text form or some binary form, that can be used to convert one version of a file into another version. On the other hand, an upgrade file may be a full size version of a file. Accordingly, an upgrade file or package may comprise just a patch file or a full size file for purposes of the present patent disclosure.

The foregoing upgrade process is OMA DM compliant, in the sense that the OMA DM protocol is utilized throughout for the transactions involving one or more management servers and one or more content servers. However, as alluded to in the Background section of the present patent application, the foregoing upgrade scenario can be problematic with respect to handling complex device image information, integration with third party solutions, et cetera.

FIG. 3depicts a message flow diagram300relating to an example device firmware upgrade process according to an embodiment of the present patent application that is operable within a known DM architecture (e.g., OMA DM) while allowing for integration with third party FOTA solutions that can include the capability of handling complex device image information for purposes of customizing upgrade recipes. Accordingly, by way of example, OMA DM transactions are illustrated here for transactions in the first protocol as shown inFIG. 2. Therefore, the information request202from a management server (i.e., first server104-1) and the device response204including the device type and version from client device102) are illustrative of a setup phase prior to establishing a device upgrade session therebetween. Additionally, in one implementation, the process flow involving message paths204-210is also similar to the process flow of the upgrade process illustrated inFIG. 2with respect to the interactions between the client device102and the management server104-1.

An artificial “Upgrade Details Document” is inserted after the FUMO EXEC command210and before the actual upgrade/patch file download in order to allow the device client102to supply extra device image information to a server for facilitating a more intelligent computation of a customized device download process. The delivery of the Upgrade Details Document (UDD) or some other document with the equivalent functionality (having upgrade information) that may be referenced via a DDF allows the client device102to be involved in the decision-making process of what needs to be updated, rather than forcing the client device to download upgrade files that might not be strictly required. Further, by placing the “Upgrade Details Document” on the DM server104-1, the message flow for the server may be left unchanged, with the extra transactions (with respect to one or more enhanced upgrade servers such as108-1,108-2) being transparent to the DM server104-1. In other words, even though transactions in addition to those defined in OMA-DM protocols may be used to complete an upgrade process, an existing OMA-DM-compliant DownLoad (DL) facility may continue to be used to download the “Upgrade Details Document” which in turn carries the identity of one or more services that carry out the upgrade process computations for the client device102. In some embodiments, one or more of enhanced upgrade servers108-1,108-2may be adapted to carry out the upgrade process computations for a particular class of client devices, for non-limiting example, devices of a particular vendor, of a particular Original Equipment Manufacturer (OEM), of a particular model, or devices employing a particular operating system or exhibiting other particular characteristics, or any groups or combinations of these. In addition, one or more of enhanced upgrade servers108-1,108-2may be operated by a party other than the party that operates DM servers104-1,104-2, such as the device manufacturer, another OEM, another service provider, or the like. In this way, enhanced upgrade servers108-1,108-2may be “third-party-specific” servers, and the services provided by enhanced upgrade servers108-1,108-2may be “third-party-specific” services.

The foregoing operations relative to the Upgrade Details Document are illustrated by way of message flow paths303and305inFIG. 3, whereupon the identity information (e.g., URL(s)) of the enhanced upgrade servers are provided to the client device102. Specifically, a DDF is requested in message flow303by the client device102and the DDF obtained by the client device (in message flow305) is operable to reference a suitable UDD. Message flow path302refers to a transaction by the client device102issued to a server such as an enhanced upgrade server108-1that is identified via the identity information (e.g., the URL), using the UDD as an element of the communication. Further, the transaction302is operable to supply complex device image information, i.e., device inventory including software/firmware/hardware version data, user preferences and their status, device status information (as to what is installed, whether active, etc.) and the like, to the enhanced upgrade server108-1. In composing the complex device image information of transaction302, the client device102operates pursuant to program logic and configuration information contained in or available to the device. Appropriate service logic312at the server108-1is configured to process the complex device image information accordingly. Additional service logic314that may also be co-located with the server108-1is configured to perform customized upgrade recipe/process computations, including identifying one or more suitable URLs for the actual patch/upgrade files. Where service logic312is co-located with service logic314(i.e., they are in the same executable environment on a server, e.g., server108-1), input302from the client device102has a direct effect on the output from service logic314. However, if service logic312and service logic314are configured in a distributed server environment, appropriate inter-server communication may also take place as needed. Message flow path304is illustrative of a transaction issued from the server108-1to the client device102including the upgrade recipes and identity information relating to one or more servers hosting the upgrade/patch files. Using the identity information obtained from the server108-1, the client device102is operable to issue a download transaction306to a content server, e.g., enhanced content server109-1, whereupon one or more customized upgrade files are downloaded (message flow path307) to the client device102. It should be appreciated that although a single download transaction306is illustrated, there can be several such transactions (e.g., from about 50 or so to over several hundred transactions per upgrade process) that may be directed to respective content servers109-X. Thereafter, similar to the process flow inFIG. 2, the client device102may engage in issuing one or more status reports to the management server104-1and, optionally, to the enhanced upgrade server108-1, as illustrated by the message flow paths308and310.

It should be realized that the message flow paths relative to the transactions with the enhanced upgrade servers and enhanced content servers may be effectuated using a protocol that is different than the OMA DM protocol used for effectuating transactions with the management server104-1. By rendering such third party transactions transparent to an existing OMA DM platform, a variety of third party-specific upgrade processes may be seamlessly integrated therewith. Additionally, although only one third party upgrade server108-1and associated content server109-1are illustrated inFIG. 3, there may be more than one third party upgrade server and one enhanced content server in some implementations. In a further variation, the message flow path208relating to the transaction between the first server104-1and the client device102may include an in-band transmission (i.e., using the same communication channel as the rest of the information, as opposed to getting the information in a different way, such as via email, or a file on an SD card, for example) of an Update Details Document information as “other information”, whereby transactions303and305may be skipped. In a still further variation, instead of fetching the download descriptor file (i.e., DDF) directly from server104-1as illustrated, the URL set in transaction208may point to another destination for the DDF. The EXEC command on this URL is operable to parse the DDF and follow the URL contained within it. That will in turn download the file from a Download Over the Air (DLOTA) server that transaction303downloads. It should be appreciated that the DDF file may be hosted on an OMA-DM server, DLOTA server, or any other compatible server as long as it contains information about how to obtain an Upgrade Details Document.

FIG. 4depicts a flow chart relating to an example device firmware upgrade process400according to an embodiment of the present patent application. At block402, a device management session is commenced between a device client and a first server using a first protocol. Thereafter, a second server is contacted using a second protocol to transmit information relating to an enhanced device image, wherein the second server's identity information (e.g., address, location, resource name/path, or identity, etc.) is obtained from the first server (block404). Based on a customized device upgrade recipe or process obtained from the second server, one or more upgrade/patch files are downloaded from one or more resources (e.g., content servers) (block406). Thereafter, a status indication may be provided to the first server using the first protocol (block408).

Within the foregoing generalized framework, a sequence of events can be as follows: (i) the client device communicates with a carrier's infrastructure to obtain a DDF which references a UDD; (ii) the client device then communicates with another infrastructure (e.g., a third-party provider) using the UDD as an element of that communication to obtain information as to where the upgrade/patch files are located; and (iii) the client device then downloads the upgrade/patch files in one or more transactions and applies them for upgrading the device image, either immediately/automatically and/or based on user's command.

Additional and/or alternative aspects of the foregoing upgrade process are illustrated inFIG. 5by way of another embodiment500. As before, a device management session is commenced between a device client and a first server (OMA DM server) using a first protocol (block502). A download file descriptor is obtained from an address location or a resource identity responsive to a FUMO EXEC command issued from the first server (block504), whereupon the device client parses the descriptor to obtain another address location or identity (e.g., a URL), of a second server having device-specific or vendor-specific or architecture-specific upgrade computation logic (block506). The device client then transmits information relating to an enhanced/complex device image or device inventory associated with the client device, which may include software/firmware/hardware versions, versions of application and non-application programs, user preferences and their status, device status, installation status, etc., (i.e., device image or inventory information) to the second server using a second protocol (block508). The second protocol may comprise HTTP or secure HTTP or any other appropriate protocol. The client device subsequently receives information from the second server defining a customized upgrade recipe including one or more address locations or identities (e.g., URLs) of the servers hosting the actual upgrade files (block510). Customization may be specific based on a number of factors, such as e.g., device type, identity, its current location, etc. Using the identity information, the device thereafter obtains one or more upgrade files from one or more resources/locations and upgrades the device image based thereon, either immediately, automatically, after a delay, or based on some user command/input (block512). Thereafter, a status indication may be provided to the first server using the first protocol. As a further option, a status indication may also be provided to the second server using the second protocol. These transactions are illustrated at block514.

FIG. 6depicts a block diagram of an example handheld device (e.g., MCD102) according to one embodiment that includes appropriate functionality to engage in upgrade process transactions with DM servers operable in one protocol as well as third party-specific servers operable in another protocol as described hereinabove. A microprocessor602providing for the overall control of an embodiment of MCD102is operably coupled to a communication subsystem604which includes a receiver608and transmitter614as well as associated components such as one or more local oscillator (LO) modules610and a processing module such as a digital signal processor (DSP)612. As will be apparent to those skilled in the field of communications, the particular design of the communication module604may be dependent upon the communications network with which the mobile device is intended to operate. In one embodiment, the communication module604is operable with both voice and data communications. Regardless of the particular design, however, signals received by antenna606from a base station607are provided to receiver608, which may perform such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection, analog-to-digital (A/D) conversion, and the like. Similarly, signals to be transmitted are processed, including modulation and encoding, for example, by DSP612, and provided to transmitter614for digital-to-analog (D/A) conversion, frequency up conversion, filtering, amplification and transmission over the air-radio interface via antenna616.

Microprocessor602also interfaces with further device subsystems such as auxiliary input/output (I/O)618, serial port620, display622, keyboard624, speaker626, microphone628, random access memory (RAM)630, other communications facilities632, which may include for example a short-range communications subsystem, and any other device subsystems generally labeled as reference numeral633. To control access as well as supply the initial DM configuration, a Subscriber Identity Module (SIM) or Removable user Identity Module (RUIM) interface634is also provided in communication with the microprocessor602. In one implementation, SIM/RUIM interface634is operable with a SIM/RUIM card having a number of key configurations644and other information646such as identification, DM configuration and subscriber-related data.

Operating system software and transport stack software may be embodied in a persistent storage module635(i.e., non-volatile storage) which may be implemented using Flash memory or another appropriate memory. In one implementation, persistent storage module635may be segregated into different areas, e.g., storage area for computer programs636(which may include operation system software) and transport stack638, as well as data storage regions such as device state637, address book639, other personal information manager (PIM) data641, and other data storage areas generally labeled as reference numeral643. Additionally, a DM client module648is provided for effectuating upgrade transactions in accordance with OMA DM protocols as well as other protocols, which may comprise standard protocols and/or third party-specific proprietary protocols according to the teachings set forth hereinabove. The DM client module648may also include suitable functionality associated with operations on a management tree or a portion thereof that is provided with the device.

Various processes, structures, components and functions set forth above in detail, associated with an upgrade server, enhanced content server or a mobile communications device, may be embodied in software, firmware, hardware, or in any combination thereof, and may accordingly comprise suitable computer-implemented methods or systems for purposes of the present disclosure. Where the processes are embodied in software, such software may comprise program instructions that form a computer program product, instructions on a computer-accessible media, uploadable service application software, or software downloadable from a remote station, and the like. Further, where the processes, data structures, or both, are stored in computer accessible storage, such storage may include semiconductor memory, internal and external computer storage media and encompasses, but is not limited to, nonvolatile media, volatile media, and transmission media. Nonvolatile media may include CD-ROMs, magnetic tapes, PROMs, Flash memory, or optical media. Volatile media may include dynamic memory, caches, RAMs, etc. Transmission media may include carrier waves or other signal-bearing media. As used herein, the phrase “computer-accessible medium” encompasses “computer-readable medium” as well as “computer executable medium.”

Furthermore, it will be recognized by those skilled in the art upon reference hereto that the arrangements set forth in the Figures of the present application may comprise a number of variations and modifications, in hardware, software, firmware, or in any combination, usually in association with a processing system where needed, as components configured to perform specific functions. Accordingly, the arrangements of the Figures should be taken as illustrative rather than limiting with respect to the embodiments of the present patent application.

It is believed that the operation and construction of the embodiments of the present patent application will be apparent from the Detailed Description set forth above. While example embodiments have been shown and described, it should be readily understood that various changes and modifications could be made therein without departing from the scope of the present disclosure as set forth in the following claims.