Interpreter

System with required enhancements to syncML DM environment to support firmware updates

6978453

Abstract

A system for employing SyncML DM for updating firmware in mobile handsets and other devices. The system employs enhancements to SyncML DM specifications. A SyncML management client employs new commands, specified by the present invention, for retrieving update packages for firmware updates, for the verification of a received update package, the command for saving the update package in an appropriate management object, the command for initiating an update process by an update agent and the command for the subsequent notification of the results of processing by the update agent (success, failure, etc.). More specifically, the SyncML DM management client employs new commands, specified by the present invention, for retrieving update packages for firmware updates and for updating the firmware selectively based on appropriateness, security and authentication, employing fault tolerant means.


Claims

1. A system employing Synchronization Markup Language (SyncML) device management specifications, recorded in memory and capable of being processed by an electronic device, to facilitate firmware updates in the electronic device, the system comprising:

at least one electronic device having a memory, at least a portion of the memory comprising non-volatile memory containing firmware;

a SyncML server communicatively coupled to the electronic device, the server comprising an enhanced SyncML DM server software; and

a SyncML DM client resident in the electronic device, wherein the SyncML DM client is capable of interpreting enhancements to the SyncML DM specifications for updating the firmware.

2. The system according to claim 1 wherein the electronic device comprises:

communication software that supports at least one data transport protocol;

a security module; and

at least one software function that provides access to proprietary parameters in the electronic device.

3. The system according to claim 2 wherein the electronic device further comprises a security device.

4. The system according to claim 2 wherein the electronic device further comprises a security device reader.

5. The system according to claim 2 wherein the SyncML DM client comprises:

message processing software that facilitates processing and executing of SyncML messages, commands, alerts, and notifications;

a SyncML manager;

a download software that facilitates the downloading of at least one firmware update package from the SyncML server; and

an update software that facilitates the updating of firmware using the at least one firmware update package.

6. The system according to claim 5 wherein the message processing software comprises:

a first software that parses SyncML messages to retrieve data;

a second software that assembles SyncML messages; and

a third software that sends the data retrieved from the SyncML messages for execution.

7. The system according to claim 1 wherein the SyncML server comprises a SyncML engine.

8. The system according to claim 7 wherein the SyncML server further comprises an interface to at least one external service provisioning system.

9. The system according to claim 7 wherein the SyncML server further comprises a manager that facilitates notification of the electronic device.

10. The system according to claim 7 wherein the SyncML engine facilitates the creation and communication of SyncML messages and notifications to the electronic device.

11. The system according to claim 7 wherein the SyncML engine facilitates the creation and communication of update packages to the electronic device.

12. The system according to claim 7 wherein the SyncML engine supports parsing and executing at least one enhancement of SyncML requests such as the enhancements to SyncML device management specifications.

13. The system according to claim 7 wherein the SyncML server further comprises a database that provides access to copies of the firmware in the electronic device.

14. The system according to claim 13 wherein the content is firmware update packages.

15. A method for updating firmware in an electronic device in a system employing enhancements to SyncML DM specifications, recorded in memory and capable of being processed by an electronic device, the system comprising the electronic device and a SyncML server, the method comprising:

receiving, by a SyncML DM client resident in the electronic device, a SyncML based notification from the SyncML server;

parsing the notification; and

sending the notification for user review and subsequent user input.

16. The method according to claim 15 wherein the notification indicates availability of a firmware update package.

17. The method according to claim 15 wherein the method further comprises:

initiating a firmware update based on an input by the user;

sending the firmware update to a download agent in the electronic device;

communicating an appropriate SyncML message to initiate download of an update package from the SyncML server; and

facilitating and analyzing a response from the SyncML server.

18. The method according to claim 17 further comprising:

verifying validity and authentication of the update package, if an update package is received as part of the response; and

dispatching commands in the response to appropriate modules.

19. The method according to claim 18 wherein the commands comprise a command for verification of the received update package.

20. The method according to claim 18 wherein the commands comprise a command for saving the update package in an appropriate management object.

21. The method according to claim 18 wherein the commands comprise a command for retrieving update packages.

22. The method according to claim 18 wherein the commands comprise a command for updating the firmware based on appropriateness, security, and authentication.

23. The method according to claim 18 wherein the commands comprise a command for initiating an update process by the update agent.

24. The method according to claim 23 wherein the commands comprise a command for subsequent notification of the result of the update agent processing.

25. The method according to claim 17 wherein the SyncML message is assembled in the electronic device.

26. A mobile electronic device comprising: machine-readable storage containing SyncML DM interpreter code executable by the mobile electronic device; and

Wherein the SyncML DM interpreter code supports updates and downloads of software and firmware in the mobile electronic device.


Description

The complete subject matter of the above-referenced United States Patent Application is hereby incorporated herein by reference, in its entirety. In addition, this application makes reference to U.S. Provisional Patent Application Ser. No. 60/249,606, entitled "System and Method for Updating and Distributing Information", filed Nov. 17, 2000, and International Patent Application Publication No. WO 02/41147 A1, entitled "Systems And Methods For Updating And Distributing Information," publication date Mar. 23, 2002, the complete subject matter of each of which is hereby incorporated herein by reference, in its entirety.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates a block diagram of an exemplary system with SyncML DM environment, in accordance with an embodiment of the present invention.

FIG. 2 illustrates an exemplary end-to-end architecture, in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 illustrates a block diagram of an exemplary system 105 with SyncML DM environment, in accordance with an embodiment of the present invention. The system 105 comprises a mobile handset 107 and a SyncML server 109. The mobile handset 107 and the SyncML server 109 may be connected via a communications link 145. The system 105 may employ enhancements to SyncML DM specifications to facilitate firmware updates on the mobile handset 107. The mobile handset 107 may comprise a SyncML management client 111, and a communication layer 113 that may provide one or more data transport protocols. In addition, the mobile handset 107 may comprise a security module 133, and device wrappers 135 that may provide access to configuration parameters, hardware elements, memory elements and User Interface (UI) modules. In an embodiment of the present invention, the mobile handset 107 may also comprise a SIM card reader 131 and a SIM card 129.

The SyncML server 109 may comprise a SyncML engine 137. In an embodiment of the present invention, the SyncML server 109 may also comprise a provisioning interface 139, which may provide an interface to one or more external service provisioning systems, a content database 141, which may provide access to content such as firmware update packages, and a notification manager 143, which may provide notification support to facilitate notification of mobile handset 107. The SyncML engine 137 may facilitate the creation and communication of SyncML based messages, notifications, update packages, etc. to the mobile handset 107. The SyncML engine 137 may also support parsing and execution of SyncML requests including the enhancements to SyncML DM introduced by the present invention.

The SyncML management client 111 may comprise a SyncML engine 115, a SyncML manager 123, a download agent 125 and an update agent 127.

The SyncML engine 115 may facilitate the processing and execution of SyncML messages, commands, alerts, notifications, etc. The SyncML engine 115 may comprise a parser 117 that may be used to parse incoming SyncML messages to retrieve commands and data, a command builder 119 that may be used to assemble SyncML messages, requests, notifications, alerts, etc., and a dispatcher 121 that may dispatch commands received in SyncML based messages, alerts, etc. for execution by the SyncML management client 111 or other modules or applications in the mobile handset 107.

The SyncML manager 123 may provide support for managing the life-cycle of management objects, managing SyncML command execution, facilitating user interactions, etc. The download agent 125 may facilitate the download of update packages for software/firmware from the SyncML server 109 employing one or more data transport protocols supported by the communication layer 113. The update agent 127 may facilitate the update of the firmware/software of the mobile handset by employing one or more downloaded update packages.

In an embodiment of the present invention, the SyncML server 109 may send a SyncML-based notification, to the mobile handset 107, employing an external notification manager 143. The notification may indicate the availability of a firmware update package. The communication layer 113 may facilitate the communication between the mobile handset 107 and the SyncML server 109. The SyncML management client 111 may receive the notification message from the SyncML server 109. The SyncML management client 111 may employ the parser 117 in the SyncML engine 115 to parse the received SyncML message. The dispatcher 121 may dispatch the notification for user review and subsequent user input, employing device wrappers 135. The device wrappers 135 may be functions utilized to indirectly access proprietary information or code stored in hardware device (e.g., registers).

The dispatcher 121 may dispatch subsequent user-initiated update of firmware to the download agent 125. The download agent 125 may communicate an appropriate SyncML message assembled by the command builder 119, to initiate download of an update package from the SyncML server 109. The download agent 125 may also facilitate the download of a response from the SyncML server 109, the response subsequently being parsed by the parser 117 and analyzed by the SyncML manager 123 and the SyncML engine 115. If an update package is received from the SyncML server 109 as part of the response, the SyncML manager 123 may ensure validity and authentication of the update package, by employing the security module 133 and the device wrappers 135. The dispatcher 121 may dispatch the commands in the SyncML-based response to appropriate modules via device wrappers 135 or via the SyncML manager 123. The commands may comprise commands such as, for example, a command for the verification of a received update package, a command for saving the update package in an appropriate management object, a command for initiating an update process by the update agent 127 and a command for subsequent notification of the result of update agent processing (success, failure, etc.).

In an embodiment of the present invention, the SyncML management client 111 may employ new commands for retrieving update packages for firmware updates and for updating the firmware based on appropriateness, security and authentication, employing fault tolerant update mechanism. The SyncML engine 137 in the SyncML server109 may be capable of processing the new enhancement commands sent to it by the mobile handset 107.

The update packages may be accompanied by a header that contains, among other entries, a cyclic redundancy check (CRC) value employed in the verification of the authenticity of the received update packages. The verification of received update packages may involve computing CRC values and comparing them to reference CRC values provided in a header that accompanies the update packages. Other forms of verification and authentication based on specific entries in the header are also contemplated.

In an embodiment of the present invention, a command to communicate the change of SIM card 129 detected by the mobile handset 107 may be supported by the mobile handset 107. The SyncML engine 137 in the SyncML server 109 may be capable of processing such a command and acting upon it.

In an embodiment of the present invention, a client-side device such as, for example, a mobile handset 107, may incorporate a management client 111 that may comprise an update agent 127, a download agent 125 (simplified to ride on top of/employ one or more data transport protocols), a SyncML engine 115, and a SyncML manager 123. The SyncML engine 115 may comprise a SyncML dispatcher 121, a SyncML parser 117, and a SyncML command builder 119.

In an embodiment of the present invention, a communication layer 113 may be utilized for the download agent 125 to interact with a management server such as, for example, the SyncML server 109. The communication layer 113 may support such function as, for example, protocolInitialization, openConnection( ), closeConnection( ), sendData( ), and receiveData( ), on which the download agent may depend.

In an embodiment of the present invention a security layer may be utilized. The security layer may be considered to be external to the management client.

Aspects of the present invention retain differentiation in the creation of the update package and the process of applying the update fault tolerantly, as allowed by the SyncML standard. An embodiment of the present invention may utilize a newly defined, extensible, XML-based Agent-to-Server meta-data protocol that adapts more easily to the SyncML DM "software download" standard, when it is ratified. A package query protocol associated with an embodiment of the present invention may follow the same extensibility and meta-data management principles seen in current SyncML standards. As a result, various embodiments of the present invention may easily comply with the SyncML standard.

SyncML DM provides a management client that is responsible for providing access to management objects. The management objects may be arranged in a management tree. The management client may be capable of manipulating the management objects and the management tree. In addition, a management tree may be comprised of management objects where each management object is a unit of code/data/application that may be accessed and/or manipulated.

The management client proposed by the SyncML standards is responsible for client-side support for SyncML based communications with management servers. Some of the duties associated with the management clients, include, for example, processing SyncML data, parsing, dispatching, and command building. A management client in an embodiment of the present invention may support dispatching and/or executing of SyncML DM commands such as, for example, alert, replace, status, add, copy, delete, exec, get, sequence, etc. The management client may also interact with a management server employing SyncML commands and structure using a communication toolkit. In addition, the management client proposed by the SyncML standards may support session initiation and termination.

The Alert command may be used to convey notifications, such as device management session requests, to the recipient. Such device management session requests may be client initiated or server initiated. In addition, wireless applications protocol(WAP) push-based notification may be a required feature in SyncML DM servers and clients, in an embodiment of the present invention.

SyncML DM clients may have to support security features such as hash message authentication code (HMAC), including basic authentication, challenge/responses, etc.

In an embodiment of the present invention, on the server-side, a device server may have its own SyncML engine to process user requests as well as to provide requested data to the mobile handsets in SyncML format. The device server may also be responsible for implementing the required security services, inserting security challenges in SyncML communications if necessary.

In an embodiment of the present invention, to be SyncML-compliant, an engine that executes SyncML DM commands may be provided. A tree of management objects may be created and maintained by the management client.

An embodiment of the present invention may comprise a SyncML management client. As a result, in addition to the download agent and the update agent, an embodiment of the present invention may employ XML parsers, encryption libraries, etc. in a mobile handset in order to assemble XML data/requests to be sent as SyncML DM commands/Alerts/Requests, parse any received XML data if data is returned as XML by the management server, and incorporate security mechanisms that may be used (Message Digest 5 (MD5), HMAC, etc.).

An embodiment of the present invention may enhance its set of device wrapper functions to be able to retrieve all the XML elements sent to the management server. The management client in such an embodiment may comprise its own download agent.

In accordance with the present invention, mobile handsets, which provide support for XML, may be multi-threaded. In a multi-threaded environment, it may not be appropriate to assume that an update process can immediately follow a download of an update package, because other applications may be running concurrently. As a result, an embodiment of the present invention may provide separate download and update processes.

An embodiment of the present invention may support reboot commands, reset commands, and power cycling by providing a location for storing downloaded update packages. An embodiment of the present invention may provide such a location by specifying a managed object for firmware updates.

An embodiment of the present invention may also provide an update package in a firmware updating service that comes up automatically during a power cycle/reboot. A SyncML DM command set enhancement that initiates a power cycling/reboot may be provided in an embodiment of the present invention. Another command enhancement may store a downloaded firmware update into an associated managed object. Yet another command enhancement may verify the authenticity of the firmware update package based on configurations and user profiles.

An embodiment of the present invention may utilize enhancement commands such as, for example, GetFirmwareUpdate, VerifyFirmwareUpdate, SaveFirmwareUpdate, ApplyFirmwareUpdate, ConfirmFirmwareUpdate, and SIMCardChange, explained below. An embodiment of the present invention may add these enhancement commands to the set of SyncML DM Protocol Command Elements as enhancements.

In an embodiment of the present invention, the SyncML DM protocol allows the enhancement commands to be executed on nodes of the management tree in the mobile device 107. The SyncML device management may be the means by which the management tree is manipulated by the SyncML DM server. In an embodiment of the present invention, each node is addressed by a unique uniform resource identifier (URI). In SyncML DM protocol, the target and source of a command are identified by the target and source elements.

In an embodiment of the present invention, the SyncML management server may employ the exec command to invoke the enhancement commands associated with the firmware updates in the mobile handset. The exec command may launch a process that initiates the firmware update download in accordance with the parameters provided in the exec command. The implementation of the exec command may ensure that the entire firmware update file download is completed prior to starting any code rewrites on the device.

The command GetFirmwareUpdate may create a new management object that refers to an update package of the firmware. This command may specify an item element to be retrieved; the item element may be also specified with an associated target element. The firmware update retrieved may be saved as a management object.

The GetFirmwareUpdate command, in an embodiment of the present invention, may verify whether an update package already exists in the mobile handset before initiating a new download, in order to avoid an unnecessary download.

In an embodiment of the present invention, the GetFirmwareUpdate command may provide the functionality of the SyncML DM GET command, in addition to providing the support to verify whether the retrieval is necessary before conducting it.

In an embodiment of the present invention, the SyncML DM server may employ the GetFirmwareUpdate command to download the firmware update package from a given location such as a uniform resource locator (URL). The GetFirmwareUpdate command may be executed by the SyncML DM protocol using the exemplary XML code shown below:

<GetFirmwareUpdate>
<CmdID>3</CmdID>
<Item>
<Target>
<LocURI> 'Managed Object where update package stored is specified
here' </LocURI>
</Target>
<Source>
<LocURI>'URL of update package is specified here' </LocURI>
</Source>
<Data>DLURL=AnyURL</Data>
<Data>DLPrompt=[0|1]</Data> <!-- 0 is no prompting, 1 is with prompting -->
</Item>
</GetFirmwareUpdate>


The Target element of the GetFirmwareUpdate command specifies where in the management tree the downloaded update package gets inserted. The Data element DLURL specifies the source URL for the download of the firmware update package. In an embodiment of the present invention, the command may be executed with a user prompt, in which case an appropriate value is employed in the Data element for DLPrompt value. Other Data and/or Target elements may be also used.

In an embodiment of the present invention, other forms of download of the firmware update package may be utilized. For example, the following Download command, which may be a generic form of the GetFirmwareUpdate command, may be used with firmware as well as software and other forms of generic downloads:
<Download>
<CmdID>3</CmdID>
<Item>
<Target>
<LocURI> 'URI of a node for the storage of update package is
specified here, or a node that represents the target of the update' </LocURI>
<Target>
<Source>
<LocURI> 'URL of update package is specified here' </LocURI>
</Source>
<Data>DLURL=AnyURL</Data>
<Data>DLPrompt=[0|1]</Data> <!-- 0 is no prompting, 1 is with prompting -->
</Item>
</Download>


An embodiment of the present invention may support a VerifyFirmwareUpdate command to verify the authenticity and appropriateness of a downloaded firmware update. Appropriate results/errors may be communicated to the SyncML management client when appropriate. The VerifyFirmwareUpdate command may be executed by the SyncML DM protocol using the exemplary XML code shown below:
<VerifyFirmwareUpdate>
<CmdID>3</CmdID>
<Item>
<Target>
<LocURI>./FWUpdate/x/PkgStatus</LocURI>
</Target>
<Source>
<LocURI>./FWUpdate/x/PkgURL</LocURI>
</Source>
</Item>
</VerifyFirmwareUpdate>


The VerifyFirmwareUpdate command may verify the specified update package. The update package may be specified using the Source element, and the result of such verification may be populated into a Target URI. Other Target and/or Source elements may also be used.

An embodiment of the present invention may support a SaveFirmwareUpdate command to save the firmware update in an appropriate management object and/or FLASH segments in memory. The SaveFirmwareUpdate command, in an embodiment of the present invention, may provide support for the functionality of the SyncML DM Replace or Add commands. The SaveFirnwareUpdate command may be used to ensure that an update agent sets an "update" bit in FLASH for a subsequent update process. The SaveFirmwareUpdate command may be executed by the SyncML DM protocol using the exemplary XML code shown below:
<SaveFirmwareUpdate>
<CmdID>3</CmdID>
<Item>
<Source>
<LocURI>./FWUpdate/x/PkgData</LocURI>
</Source>
<Data>Address=0×00089F</Data> <!—Address specified as hex value-->
</Item>
</SaveFirmwareUpdate>


The SaveFirmwareUpdate command facilitates saving of the update package in specific address locations that may be implementation-dependent. In the above example, binary data from the management tree located in the mobile handset at the location ./FWUpdate/x/PkgData is saved at the address specified in the Data element for 'Address' parameter. Other Source and/or Data elements may also be used.

An embodiment of the present invention may support an ApplyFirmwareUpdate command to take a target firmware update management object and launch an update process. The update process may involve power cycling the mobile handset. The result of taking a target firmware update management object and launching an update process may be communicated only after the power cycling step has been executed. The ApplyFirmwareUpdate command may be executed by the SyncML DM protocol using the exemplary XML code shown below:
<ApplyFirmwareUpdate>
<CmdID>3</CmdID>
<Item>
<Source>
<LocURI>./FwUpdate/x/PkgURL</LocURI>
</Source>
<Data>argument1</Data>
<Data>argument2</Data>
<Data>argument3</Data>
</Item>
</ApplyFirmwareUpdate>


The ApplyFirmwareUpdate command facilitates the invocation of an update agent. The ApplyFirmwareUpdate command specifies the Source element as a URI in the management tree, and specifies optional prompts. Other Source and/or Data elements may also be used.

In an embodiment of the present invention, other Update commands may be utilized for updating firmware with a firmware update package. For example, the following Update command, which may be a generic form of the ApplyFirmwareUpdate command, may be used:
<Update>
<CmdID>3</CmdID>
<Item>
<Target>
<LocURI>./.../Application/ ApplicationXXX</LocURI>
</Target>
<Source>
<LocURI>./FwUpdate/x/PkgURL</LocURI>
</Source>
<Data>argument1</Data>
<Data>argument2</Data>
<Data>argument3</Data>
</Item>
</Update>


In the Update command, Target specifies the node in the management tree that represents the Application or component to be updated. The Source specifies the URL from which the update package(s) are to be downloaded or retrieved. A node that provides an update package that may have been previously downloaded, or may be part of the management tree, may also be employed.

An embodiment of the present invention may support a ConfirmFirmwareUpdate command to confirm the status of the previously executed firmware update event. The ability to confirm successful completion of a firmware update may be used to initiate billing activities on the carrier-side. The ConfirmFirmwareUpdate command, in an embodiment of the present invention, may support the functionality of a SyncML DM generic update confirmation command/notification, which may be utilized to indicate a successful completion of update events, specifically to initiate possible billing activities.

When a SIM card changes on the mobile handset side, the nature of the service may change on the carrier-side. An embodiment of the present invention may support a SIMCardChange command to facilitate the notification of service-level changes with possible changes to billing events.

FIG. 2 illustrates an exemplary end-to-end architecture, in accordance with an embodiment of the present invention. The solution depicted in FIG. 2 is compliant with SyncML specifications.

A mobile handset 219 may comprise firmware. The mobile handset 219 may be communicatively coupled with a SyncML DM server 209 via a communication link 213. The communication link between the SyncML DM server 209 and the mobile handset 219 may utilize a SyncML protocol 213. The SyncML DM server 209 may receive a firmware update package 207 from the generator 205 that generated the update package 207 utilizing an old (original) version of the firmware 201 and a new (target) version of the firmware 203.

In an embodiment of the present invention, the SyncML DM server 209 may be used to store the update packages 207, to manage delivery of the update packages 207, and to maintain system security. The enhancement commands described hereinabove enable an enhanced SyncML DM server 209 to provide the firmware updating service, which is not supported by the commands available using a server compliant only with the existing SyncML DM standards.

In an embodiment of the present invention, the mobile handset 219 may comprise a SyncML DM download agent 215, and an update agent 217. The SyncML DM download agent 215 may be responsible for initializing, transferring, and checking the update package 207 sent by the SyncML DM server 209. The update agent 217 may then apply the updates to the firmware in a fault tolerant manner in accordance with an embodiment of the present invention.

While the present invention has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the present invention without departing from its scope. Therefore, it is intended that the present invention not be limited to the particular embodiment disclosed, but that the present invention will include all embodiments falling within the scope of the appended claims.