Upgrading electronic files of a mobile device upgrade client

[0001] This application claims the benefit of U.S. patent application Ser. No. 60/511,048, filed Oct. 14, 2003. This application is also a continuation-in-part application of U.S. patent application Ser. No. 10/292,245, filed Nov. 12, 2002, now U.S. Pat. No. 6,836,657, both of which are currently pending.

[0002] This application is related to U.S. patent application Ser. No. 10/146,545, filed May 13, 2002, application Ser. No. 10/261,153, filed Sep. 30, 2002, application Ser. No. 10/298,458, filed Nov. 18, 2002, application Ser. No. 10/298,393, filed Nov. 18, 2002, application Ser. No. 10/616,615, filed Jul. 9, 2003, all of which are currently pending.

[0003] The disclosed embodiments relate to updating and maintaining electronic files.

[0004] Software is hosted or running on most electronic devices and includes one or more files in the form of human-readable American Standard Code for Information Interchange (“ASCII”) plain text files or binary code. The hosted software, which runs on a processor or central processing unit (“CPU”), provides functionality in a host device but often changes over time. The software changes may result from the need to correct bugs, or errors, in the software files, adapt to evolving technologies, or add new features and functions. In particular, embedded software components hosted on mobile wireless devices often include numerous software bugs that require correction.

[0005] The software of a device includes software files divided into smaller units that are often referred to as modules or components. In mobile wireless devices, a real-time operating system (“RTOS”) is typically used in which the hosted software modules or components of the device are linked as a single large file. This large software file is loaded, or embedded, into the device, and is typically stored in the read-only-memory (“ROM”) or flash ROM of the wireless device.

[0006] The hosted software files of a wireless device can be updated to correct errors or add new functions using a wireless communication link or over-the-air (“OTA”) link like a radio link. Because of bandwidth, memory and other constraints relating to the wireless device, updating the hosted software after the device has been commercially released requires special proprietary applications. An example of these proprietary applications includes the upgrade or update applications referred to as DeltaUpdate™ and DeltaRewrite™ available from InnoPath Software, Inc. of Alviso, Calif. These upgrade applications are also the subject of the Related Applications.

[0007] While the upgrade applications are designed to modify the software hosted on the device, the upgrade applications cannot be used to update themselves. Typical upgrade applications cannot self-upgrade because they control the upgrade process of the device and are required to be running in order for execution of the upgrade process. The typical upgrade methods however require that software not be running in order for it to be upgraded. As such, upgrades of the upgrade applications themselves require the device to be returned to the device manufacturer or service provider for upgrade. Returning the devices to the manufacturer or service provider is a time-consuming and costly process not highly regarded by consumers because of the consumer's increased reliance on these devices. Consequently, there is a need to provide self-upgrades of upgrade applications hosted on wireless devices like cellular telephones and other mobile communication devices, personal digital assistants (“PDAs”), and personal computers.

[0015] In the drawings, the same reference numbers identify identical or substantially similar elements or acts. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the Figure number in which that element is first introduced (e.g., element 126 is first introduced and discussed with respect to FIG. 1).

[0016] Systems and methods are described below that provide fail-safe self-upgrades of upgrade clients (also referred to as “upgrade applications”) in client devices including wireless and/or mobile devices. These systems and methods form a self-upgrading upgrade client that includes a dedicated self-upgrade sub-client. The self-upgrade sub-client allows an upgrade client hosted on a mobile device to self-upgrade software or applications of the upgrade client while running in order to correct errors in the software, update the software version, and update a communication protocol, to name a few. The self-upgrade sub-client therefore overcomes the need to return the client device to the device manufacturer or service provider for a required upgrade of the upgrade client. In the event of a failure during a software upgrade that prevents successful completion of the upgrade, the upgrade system of an embodiment recovers the client devices to a pre-grade state. The upgrade system subsequently either resumes or re-initiates the upgrade that was in progress at the time of the failure.

[0017] In the following description, numerous specific details are introduced to provide a thorough understanding of, and enabling description for, embodiments of the self-upgrading upgrade client. One skilled in the relevant art, however, will recognize that the self-upgrading upgrade client can be practiced without one or more of the specific details, or with other components, systems, etc. In other instances, well-known structures or operations are not shown, or are not described in detail, to avoid obscuring aspects of the self-upgrading upgrade client.

[0018] FIG. 1 is a block diagram of a file upgrade system 100, under an embodiment. Generally, the file upgrade system 100 includes a first computer system 102, or host system, and one or more second computer systems including client devices or computers 122. The host system 102 and the client devices 122 each include at least one processor 104 and 124, respectively, operating under program control, but are not so limited. The host system 102 and the client devices 122 communicate via a communication path 199. These computer systems 102 and 122 include any collection of computing devices operating together, as is known in the art. The computer systems 102 and 122 can also include components within a larger computer system.

[0019] The processor 104 of the host system 102 couples among a database 106 and a file differencing algorithm 114, under program control. Alternatively, various other components of the host system 102 can couple among the processor 104, the database 106, and the file differencing algorithm 114 and provide file updating functions under program control. While one processor 104, one database 106, and one file differencing algorithm 114 are shown, various alternative embodiments include any number and/or type of each of these components coupled in various configurations contemplated by one skilled in the art. Further, while the processor 104, database 106, and file differencing algorithm 114 are shown as separate blocks, some or all of these blocks can be monolithically integrated onto a single chip, distributed among a number of chips or components of a host system, and/or provided by some combination of algorithms. The file differencing algorithm 114 can be implemented in software algorithm(s), firmware, hardware, and any combination of software, firmware, and hardware. The term “processor” as generally used herein refers to any logic processing unit, such as one or more CPUs, digital signal processors (“DSPs”), application-specific integrated circuits (“ASIC”), etc.

[0020] Likewise, the client devices 122 of an embodiment include a processor 124 coupled among a device memory 130 and an upgrade client 126, under program control. Alternatively, various other components of the client devices 122 can couple among the processor 124, the device memory 130, and the upgrade client 126 and provide file updating functions under program control. While one processor 124, one device memory 130, and one upgrade client 126 are shown, various alternative embodiments include any number and/or type of each of these components coupled in various configurations contemplated by one skilled in the art. Further, while the processor 124, device memory 130, and upgrade client 126 are shown as separate blocks, some or all of these blocks can be monolithically integrated onto a single chip, distributed among a number of chips or components of a host system, and/or provided by some combination of algorithms. The algorithm or applications of the upgrade client 126 can be implemented in software algorithm(s), firmware, hardware, and any combination of software, firmware, and hardware. The device memory can include any number and/or combination or memory types including ROM and random access memory (“RAM”), but is not so limited.

[0021] The communication path 199 includes any medium for communicating or transferring files among the computer systems 102 and 122. Therefore, this path 199 includes wireless connections, wired connections, and hybrid wireless/wired connections. The communication path 199 also includes couplings or connections to networks including local area networks (“LANs”), metropolitan area networks (“MANs”), wide area networks (“WANs”), proprietary networks, interoffice or backend networks, and the Internet. Furthermore, the communication path 199 includes removable fixed mediums like floppy disks, hard disk drives, and CD-ROM disks, as well as flash memory, Universal Serial Bus (“USB”) connections, RS-232 connections, telephone lines, buses, and electronic mail messages.

[0022] The host system 102 and the client devices 122 each include an original version 110 of an electronic file, referred to herein as the original file 110 or the old file. The host system 102 stores the original file 110 in a database 106 or other memory area or combination of memory areas or devices, but is not so limited. The client devices 122 store the original file 110 in device memory for use in operation.

[0023] At such time as a software provider upgrades the original file 110, for example to provide additional functionality or to fix a software bug, a new version 112 of the electronic file is generated. The new version 112 of the electronic file is referred to herein as the new file 112. The new file 112 is generally an updated or revised version of the original file 110, but is not so limited. The software provider transfers the new file 112 to the host system 102.

[0024] The electronic files 110 and 112 include software files including dynamic link library files, shared object files, embedded software components (“EBSCs”), firmware files, executable files, data files including hex data files, system configuration files, and files including personal use data, but are not so limited. Since any type of file can be regarded as a byte stream, hereafter a file can be described as a byte stream.

[0025] Components of the host system 102 including at least one processor 104 receive and process the new file 112 in order to generate upgrade information for use in upgrading the hosted original files 110 of the client devices 122. In an embodiment, the processor 104 generates an upgrade file 118 for use in transferring information of the upgrades to the client devices 122. The upgrade file 118 can include a difference file that codes differences between the new file 112 and the original file 110 or, alternatively, can include any number and/or combination of components or modules of the new file 112. The host system 102 provides the upgrade information to the client devices 122 via transfer of the upgrade file 118 over the communication path 199.

[0026] In embodiments where the upgrade file 118 includes a difference file, components of the host system 102 including the processor 104 and the file differencing algorithm 114 process a comparison between the new file 112 and the corresponding original file 110, thereby calculating the differences between the new file 112 and the original file 110. The file differencing algorithm 114 generates the difference file during the comparison and writes the difference file to the upgrade file 118.

[0027] The upgrade file 118 is transferred or transmitted to the client devices 122 via the communication path 199. Prior to transfer, the upgrade file 118 may be compressed using any of a number of compression techniques known in the art, but is not so limited.

[0028] Components of the client devices 122 including the processor 124 and the upgrade client 126 receive the upgrade file 118 and control the upgrade of the original file using the upgrade file 118. The upgrade client 126 of the client device 122 includes at least one of a download sub-client (“SC”) (“download SC”) 126-1, an upgrade SC 126-2, and a self-upgrade SC 126-3. The download SC 126-1 functions to download or receive files transferred from the host system 102. The upgrade SC 126-2 uses information of the transferred files received from the host system 102 to perform upgrades to software of the client device 122. The self-upgrade SC 126-3 functions to upgrade software of the upgrade client 126. The self-upgrade SC 126-3 of an embodiment is stored in a different physical memory block or area than either of the download SC 126-1 or the upgrade SC 126-2. The software of the upgrade client 126 includes but is not limited to software of the download SC 126-1, the upgrade SC 126-2, and the self-upgrade SC 126-3.

[0029] In an embodiment, the upgrade client 126, including components of the download SC 126-1, the upgrade SC 126-2, and the self-upgrade SC 126-3, processes information of the upgrade file 118 along with the hosted original file 110 to generate a copy of the new file 152. This copy of the new file 152 is subsequently used by the upgrade client 126 to upgrade 154 the targeted original file 110 hosted on the client devices 122. The upgrade client 126 of an embodiment uses numerous methods to update EBSCs depending on the file type to be updated and the resources allocated by the client device manufacturer to support these updates, as described below and in the Related Applications. Upon completion of this update process, the original file 110 now stored on the client devices 122 is the same as the new file 112 received in the host system 102.

[0030] Alternative embodiments of the upgrade client 126 may host the self-update SC 126-3 with other components of the device operating system. As one example, the self-update SC 126-3 may be a component of the device boot code or stored in device memory adjacent the boot code. FIG. 2 is a block diagram of an upgrade client 126-A, under an alternative embodiment. The upgrade client 126-A of this alternative embodiment includes at least one of a download sub-client SC 126-1, an upgrade SC 126-2, and a self-upgrade SC 126-3. The self-upgrade SC 126-3 is a component of the device boot code 132 and/or stored in device memory 130 adjacent the boot code 132, but is not so limited. Various other alternative embodiments may locate the self-update SC 126-3 in any of a number and/or combination of areas of the device memory 130.

[0031] Those skilled in the relevant art will appreciate that those functions associated with the upgrade system 100 as well as the other functions and methods described herein with reference to the upgrade system 100 can be performed by components of the host system 102, components of the client devices 122, or distributed among any combination of components of the host system 102 and the client devices 122. Components of the host system 102 and client devices 122 can be implemented as ASICs, by DSP integrated circuits, and/or through conventional programmed logic arrays or circuit elements. The embodiments described herein can be implemented using any combination of hardware, firmware, and software running on one or more processors, where the software can be stored on any suitable computer-readable medium, such as microcode stored in a semiconductor chip, on a computer-readable disk, or downloaded from a server and stored locally at a client.

[0032] FIG. 3 is a block diagram of an example service provider infrastructure 300 including components of the file upgrade system 100 of an embodiment. In this embodiment the service provider infrastructure is described in the context of a cellular telephone network or infrastructure, but alternative embodiments are not so limited. The service provider infrastructure 300 includes, but is not limited to, a Software Component Distributor (“SCD”) 302, service provider upgrade components 303-305, and an upgrade client 126 hosted on the client devices 122. The service provider upgrade components 303-305 include an upgrade server 304 coupled among a software component certification server 303 and an upgrade manager 305.

[0033] With further reference to FIG. 1, the SCD 302 of an embodiment of the service provider infrastructure 300 includes components or functions of the host system 102. In alternative embodiments, the service provider upgrade components 303-305 host components or functions of the host system 102. In other alternative embodiments the components or functions of the host system 102 are distributed among components of the SCD 302 and the service provider upgrade components 303-305.

[0034] The service provider infrastructure 300 of an embodiment supports numerous types of software file or component upgrades on client devices 122 including mobile electronic devices, mobile communication devices, cellular telephones, personal digital assistants, computers, and other processor-based devices via the upgrade system components and various mechanisms of the service provider's wireless infrastructure. These systems function by receiving new and revised software from a software distributor, generating an upgrade file from the new software, and transferring the upgrade file to the client devices 122 via the service provider infrastructure. The upgrade client 126 of the client devices 122 uses the upgrade file to update the targeted software hosted on the client devices 122.

[0035] The SCD 302 of an embodiment provides a user interface by which software providers package and release new embedded device software components. Functions of the SCD 302 include registering device information and submitting device information to the software component certification server. Also, the SCD 302 receives new and original EBSCs, calculates or generates file differences using the new and original EBSCs, registers and packages embedded software, and submits embedded software packages to the software component certification server 303. The new or revised software, following release, is provided to the service provider upgrade components 303-305 via a wired, wireless, or hybrid wired/wireless network coupling or connection 320, but is not so limited.

[0036] The SCD 302 of an embodiment is hosted on processing systems of the client device manufacturers. In an alternative embodiment, the SCD 302 is hosted on processing systems of an application or system software provider. In another alternative embodiment, the SCD 302 is hosted on processing systems of the service carrier or provider, for example hosted on or distributed among the upgrade components 303-305.

[0037] The service provider upgrade components 303-305 are coupled among the software component distributor 302, the client devices 122, and the existing components of the service provider's infrastructure 310-318, including the existing gateway 310 and communication infrastructure 312, billing server 314, logging server 316, and authentication server 318.

[0038] The software component certification server 303 provides an interface to the manufacturers of client devices and, thus, receives new device information on embedded software packages from device manufacturers. The software component certification server 303 also repackages and distributes approved software packages to upgrade servers.

[0039] The upgrade manager 305, while functioning as an interface among the software component certification server 303 and the upgrade server 304, configures software and data packaging for optimal device management, schedules remote change notifications, and controls the update policy monitor system. Moreover, the upgrade manager 305 provides integration with the systems of the existing infrastructure.

[0040] The upgrade server 304 provides capabilities including authenticating, connecting, and communicating with mobile client devices 122 to perform embedded software component upgrades. Communication with client devices 122 can occur via couplings 312 with the client devices 122 that include wireless couplings, wired couplings, hybrid wired/wireless couplings, and other network coupling types, as appropriate to the corresponding service provider. In addition, the upgrade server 304 supports existing billing, data collection, and logging services of the service provider.

[0041] As an example of communications among the upgrade server 304 and client devices 122, when an upgrade file is available for transfer to a client device 122 from the upgrade server 304, the server 304 sends a user notification to notify the client device user that there are software components available for updating. The user notification can take the form of a text message via a Short Message Service (“SMS”) push protocol, Hypertext Transfer Protocol (“HTTP”), or Wireless Application Protocol (“WAP”), but is not so limited. Upon receiving confirmation from the handset users, the upgrade server 304 uses the original handset data communication protocol to send the upgrade file to the requesting device.

[0042] In response to receipt of the confirmation from the device, the upgrade server 304 authenticates and authorizes the user and/or requesting device, and verifies prerequisite capabilities and limitations of the requesting device. Following authentication the upgrade server 304, as the manager of client device configuration data, identifies the current versions of embedded software components of the requesting device, identifies and transfers appropriate delta files to the requesting device, logs the status of the upgrade transaction, and reports the results to the upgrade manager 305. In addition, the upgrade server 304 activates/deactivates the software upgrade service over the air, and notifies remote users of software changes.

[0043] With reference to FIG. 1, the upgrade client 126 is embedded in the client devices 122, but is not so limited. The upgrade client 126 stores and maintains configuration data of the client devices 122, and provides for the maintenance and upgrading of embedded device software components. The upgrade client 126 supports a simple user interface and is incorporated into mobile device software. Upon execution, the upgrade client 126 automatically detects the remote change of any embedded software components, notifies users of an embedded software component upgrade, and upgrades a software component based on the carriers and/or users control, as appropriate for a particular service provider.

[0044] The upgrade system 100 and service provider infrastructure 300 of an embodiment support numerous types of software file or component update, including updates to executable files, byte stream files, and data files, but are not so limited. The executable files, or image files, include software files used in the client device to execute tasks, for example the operating system (“OS”), hardware device drivers, and K Virtual Machine (“KVM”) files. The byte stream files include files used by other executable files, for example, icon files, logo files, and MP3 files. Data files include files containing personal use data, and handset reference data, for example the calibration configuration files, the Protocol Independent Multicast (“PIM”) files, and system configuration files.

[0045] The upgrade client 126 of an embodiment uses numerous methods to update EBSCs depending on the file type to be updated and the resources allocated by the client device manufacturer to support these updates, as described in the Related Applications. These update methods of an embodiment include non-critical component updates, critical component updates, and update client component updates, where these categories are based on the functions provided by the software components targeted for update.

[0046] Non-critical components include embedded software components (EBSCs) that are easily recovered over the air following a failure during the update process. Examples of non-critical components include browsers and KVM files, but are not so limited. Critical components include software components used in the update procedure or the EBSCs critical to device operation. Further, critical components include EBSCs that are not easily recovered over the air following a failure during the update process. Examples of critical components include the operating system files, protocol stacks, the upgrade client files, communication libraries, and display or LCD driver files, but are not so limited. Update client component updates include EBSCs of the update client 126.

[0047] The client devices 122 determine the status of numerous device parameters prior to participating in an update procedure. This is done in order to pre-qualify the device for the update procedure, or verify that the condition of the client device is such that the update procedure can be completed once begun. The client device pre-qualification includes, but is not limited to, determining if the client device is in a cradle or charging mode, if the client device is connected to a serial cable, if the state of battery charge is sufficient to perform the updating process, if the Received Signal Strength Indication (“RSSI”) or signal strength is sufficient for the data transfer, and if the targeted EBSC is currently in use.

[0048] In spite of pre-qualifying the client devices 122 for the update procedure, failures in the update can occur as a result of hardware failures, power (battery) failures, and failures of the network connection, to name a few. The upgrade system 100 of an embodiment provides fail-safe software file updates by recovering the client devices 122 to a pre-update state and either resuming or re-initiating the update that was in progress at the time of the failure. Components of the upgrade server 304 and the upgrade client 126 include an automatic failure recovery mechanism that provides the fail-safe updates, as described below.

[0049] The client device of an embodiment stores data of the relationship among the EBSCs of the client device software, referred to herein as file configuration data, in a module-based memory management (“MBMM”) EBSC. The MBMM EBSC is referred to herein as a configuration file. The configuration data also includes upgrade status information. The upgrade status information includes detailed information relating to the status of upgrades to client device software including, for example, information as to where a failure or error occurred during an attempted upgrade. Because of the importance of the configuration data to the operation of the client device, the upgrade client provides access to accurate configuration data as well as maintains the configuration data through file upgrades, as follows.

[0050] The upgrade client of an embodiment automatically upgrades EBSCs of the non-critical, critical, and upgrade client components hosted on the client device, as described herein and in the Related Applications. In performing the upgrades of these various software components, as an example, FIG. 4 is a flow diagram 400 for performing file upgrades that include upgrades to upgrade client components, under an embodiment. At such time as the client device is powered up or reset, at block 402, the upgrade client 126 of an embodiment evaluates the content of a mode register, at block 404. When the mode register content indicates that an upgrade file is available for download, the upgrade client 126 transitions to an RTOS mode and in response activates the download SC of the upgrade client 126, at block 406. The download SC functions to receive or download the available upgrade file into one or more areas of client device memory as described below. The upgrade client 126 initiates a reset 416 following receipt of the upgrade file, and operation returns to block 404 (via block 402) where the upgrade client 126 further evaluates the mode register content.

[0051] The content of the mode register is manipulated by the upgrade client 126 of an embodiment in response to information of the upgrade file that indicates the type of upgrade information included in the upgrade file. The information of the upgrade file that indicates the type of upgrade information included in the upgrade file may be found in a header section of the upgrade file, but alternative embodiments can include this information in other parts of the upgrade file. As an example, the upgrade client 126 sets a first pre-specified value in the mode register in response to an upgrade file that includes upgrades of non-critical or critical components. Further, the upgrade client 126 sets a second pre-specified value in the mode register in response to an upgrade file that includes upgrades of upgrade client components.

[0052] Upon evaluation of the mode register, at block 404, the upgrade client 126 transitions to an initial program load (“IPL”) mode, at block 408, when the mode register content indicates that a received upgrade file includes information for use in upgrading non-critical components and/or critical components of the client device. In the IPL mode the upgrade client 126 activates the upgrade SC of the upgrade client. The upgrade SC functions to upgrade the non-critical components and/or critical components using contents of the upgrade file as described in the Related Applications. The upgrade client 126 of an embodiment initiates a reset 418 upon completion of the upgrades, and operation returns to block 404 where the upgrade client 126 further evaluates the status of the mode register. However, the upgrade client 126 of an alternative embodiment, instead of initiating the reset 418, may branch 428 directly to a boot mode 410 when information of the upgrade file indicates the upgrade file includes information for upgrading upgrade client components, but the embodiment is not so limited.

[0053] In response to the upgrade client reset 418 following completion of upgrades to non-critical and/or critical components of the client device, the upgrade client 126 again evaluates the mode register, at block 404. The upgrade client 126 transitions to the boot mode, at block 410, when the mode register content indicates that a received upgrade file includes information for use in upgrading upgrade client components. In the boot mode the upgrade client 126 activates the self-upgrade SC of the upgrade client, at block 410. The self-upgrade SC functions to upgrade the upgrade client components using contents of the upgrade file as described below with reference to FIG. 5 and FIG. 6. The upgrade client 126 of an embodiment initiates a reset 420 upon completion of the upgrade client component upgrades, and operation returns to block 404 where the upgrade client 126 further evaluates the mode register.

[0054] The performance of file upgrades in an embodiment includes self-upgrades of the upgrade client of a client device, as described above. The self-upgrading upgrade client includes a dedicated self-upgrade sub-client along with corresponding APIs and drivers that allows the upgrade client to self-upgrade its software while running. FIG. 5 is a flow diagram 500 for upgrading software components of an upgrade client, under an embodiment. This self-upgrading process 500 is provided as one example of operations of a self-upgrading upgrade client as many alternative embodiments are possible.

[0055] Self-upgrading of the upgrade client begins with the availability of an upgrade file that includes information for use in upgrading upgrade client components of the client device. As described above with reference to FIG. 4, the upgrade client transitions to an RTOS mode in which it activates the download SC. The download SC receives the available upgrade file via an OTA coupling, at block 502, and stores the received upgrade file in one or more areas of client device memory. The received upgrade file includes a difference file for use in upgrading an original EBSC of the upgrade client where the upgrade client includes the download SC, the upgrade SC, the self-upgrade SC.

[0056] In response to receipt of the upgrade file, the download SC also verifies the accuracy of the upgrade file contents using a verification algorithm. While the embodiments described herein include the use of verification processes or algorithms that use, for example, checksum values or Cyclic Redundancy Codes (“CRCs”), the embodiments may use any verification process or algorithm contemplated by one skilled in the art. The verification calculation or algorithm recalculates the checksum or CRC, as appropriate, and compares it to a corresponding value stored in the client device with the original configuration data. If the verification shows the upgrade file contents to be free of errors, then the download SC proceeds with upgrading the original upgrade client EBSC by copying a backup version of the upgrade file to one or more areas of client device ROM, at block 504.

[0057] The upgrade client initiates a reset following receipt of the upgrade file, at block 506. Following this reset, as described above, the upgrade client transitions to an IPL mode during which non-critical and/or critical component upgrades are performed by the upgrade SC when it is determined that a received upgrade file includes information for use in upgrading non-critical components and/or critical components. Following completion of non-critical and/or critical component upgrades, or when it is determined that a received upgrade file only includes information for use in upgrading upgrade client components, the upgrade SC proceeds with upgrades of the upgrade client components, as described above with reference to FIG. 4.

[0058] Continuing with self-upgrading of the upgrade client components, the upgrade SC copies the backup version of the upgrade file from ROM to RAM, at block 508. The upgrade SC copies the original upgrade client EBSC targeted for upgrade from ROM to RAM, at block 510. The upgrade SC generates the new upgrade client EBSC using the original upgrade client EBSC and the corresponding information of the upgrade file stored in client device RAM, at block 512. The upgrade SC also performs verification calculations on the new upgrade client EBSC, but is not so limited. The upgrade SC copies the new upgrade client EBSC of the upgrade client to ROM for use as a backup to the new upgrade client EBSC, at block 514.

[0059] The upgrade SC determines whether additional upgrade files are available for use in upgrading additional EBSCs of the upgrade client, at block 516. When additional upgrade files are available, operation of the upgrade SC returns to block 510 to process the additional files as described above with reference to blocks 510, 512, and 514. Upon completing processing of all upgrade files, the upgrade SC deletes or erases the original upgrade client EBSC of the upgrade client from ROM, at block 518, and resets the client device to a boot mode, at block 520.

[0060] Following this reset, the upgrade client transitions to the boot mode during which the upgrade client activates the self-upgrade SC as described above with reference to FIG. 4. In the boot mode, the self-upgrade SC copies the new upgrade client EBSC backup from ROM into the area of ROM previously occupied by the original upgrade client EBSC (erased) and verifies the accuracy of the new upgrade client EBSC as copied, at block 522. The self-upgrade SC deletes or erases the backup copy of the new upgrade client EBSC from ROM, at block 524.

[0061] The self-upgrade SC determines whether additional upgrade files are available for use in upgrading additional upgrade client EBSCs, at block 526. When additional upgrade files are available, operation of the self-upgrade SC returns to block 522 to process the additional files as described above with reference to blocks 522 and 524. Upon completing processing of all upgrade files corresponding to the upgrade client, the self-upgrade SC resets the client device to the RTOS mode, at block 528.

[0062] FIG. 6 is a block diagram 600 depiction of upgrade client software component upgrades using difference files, under the embodiment of FIG. 5 and FIG. 6. The upgrade process of this example uses storage locations in both ROM 602 and RAM 604 areas of the client device memory 130 (FIG. 1), but alternative embodiments can use any combination of areas in the client device memory 130 or any number of different segments of the same memory area.

[0063] The upgrade process begins when the upgrade client receives an upgrade file 610 for use in upgrading an original EBSC 612 corresponding to the upgrade file 610. The update client of an embodiment receives the upgrade file 610 via an OTA coupling or connection but is not so limited. For purposes of this example, the upgrade file 610 includes a difference file for use in upgrading an original EBSC of the upgrade client but, alternatively, the upgrade file 610 can include difference files and entire new files or new EBSCs. The upgrade client stores or writes 630 the upgrade file 610 to RAM 604 and verifies the accuracy of the upgrade file contents using a verification algorithm. If the upgrade file 610 is free of errors, the upgrade client proceeds with upgrading the original EBSC 612-O by generating and storing 632 a backup version of the upgrade file 610-B to one or more areas of client device ROM 602.

[0064] Following a reset to an IPL mode, as described above, the upgrade client copies or writes 634 the backup version of the upgrade file 610-B from ROM 602 to RAM 604. The upgrade client then copies 636 the original upgrade client EBSC 612-O targeted for upgrade from ROM 602 to RAM 604 as copy 612-C. The upgrade client generates 650 the new upgrade client EBSC 612-N using the copy 612-C of the original upgrade client EBSC and the corresponding information of the upgrade file 610 stored in client device RAM 604. The upgrade client also performs verification calculations on the new upgrade client EBSC 612-N, but is not so limited. The upgrade client copies 638 the new upgrade client EBSC 612-N to ROM 602 as copy 612-NC for use as a backup to the new upgrade client EBSC 612-N.

[0065] Upon completing processing of all upgrade files, the upgrade client deletes or erases the original upgrade client EBSC 612-O from ROM 602, and resets the client device to a boot mode, as described above. Following this reset, the upgrade client copies 640 the new upgrade client EBSC backup 612-NC into the area of ROM 602 previously occupied by the original upgrade client EBSC 612-O (erased) and verifies the accuracy of the new upgrade client EBSC as copied. The upgrade client then deletes or erases the backup copy of the new upgrade client EBSC 612-NC from ROM 602.

[0066] The upgrade client determines whether additional upgrade files are available for use in upgrading additional upgrade client EBSCs. When additional upgrade files are available, operation of the upgrade client continues to process the additional files as described above. Upon completing processing of all upgrade files corresponding to the upgrade client, the upgrade client again resets the client device.

[0067] As described above, the client device of an embodiment is recoverable from errors occurring during software upgrades. FIG. 7 is a flow diagram 700 for recovering a client device from errors occurring during software component upgrades of an upgrade client, under an embodiment. In performing file upgrades, the upgrade client begins by determining whether the file upgrades are being performed for the first time in response to the availability of new files, or whether the client device is being recovered from errors that occurred during previous upgrade attempts, at block 702.

[0068] When performing file upgrades for the first time, the upgrade client receives an upgrade file in the form of a difference file for use in upgrading an original EBSC corresponding to the upgrade file, at block 704. In response to receipt of the difference file, the upgrade client uses the checksum value of the difference file to determine whether the difference file contents are free from errors, at block 706. This process of receiving the difference file and evaluating the accuracy of the file contents is repeated until either an error-free difference file is received, or until the process has been repeated a pre-specified number of times, N. Upon repeating the process the pre-specified number of times N without success, at block 730, the upgrade client uses resources of the client device to report the error to the client device user and the service provider's upgrade server, at block 740, and terminates the upgrade process, at block 726.

[0069] In response to the receipt of an accurate difference file, at block 704, the upgrade client verifies the accuracy of the original EBSC contents, at block 708. If the checksum value of the original EBSC is determined to be incorrect, at block 710, the process of calculating the checksum of the original EBSC is repeated until a correct checksum value is calculated, or until the process has been repeated a pre-specified number of times, N. Upon repeating the process the pre-specified number of times N without success, at block 732, the upgrade client uses resources of the client device to report the error to the client device user and the service provider's upgrade server, at block 780, and terminates the upgrade process, at block 726.

[0070] When the original EBSC contents are determined to be accurate, at block 710, the upgrade client generates the new EBSC using the original EBSC and the difference file, at block 712. The upgrade client also performs verification calculations on the contents of the new EBSC. If the checksum value of the new EBSC is determined to be incorrect, at block 714, the process of generating the new EBSC and calculating the checksum is repeated until a correct checksum value is calculated, or until the process has been repeated a pre-specified number of times, N. Upon repeating the process the pre-specified number of times N without success, at block 734, the upgrade client uses resources of the client device to report the error to the client device user and the service provider's upgrade server, at block 780, and terminates the upgrade process, at block 726.

[0071] When the upgrade client determines that the contents of new EBSC are accurate, at block 714, a backup version of the new EBSC is generated and written to device memory, at block 716. The accuracy of the backup version of the new EBSC is also verified using checksum values. If the checksum value of the backup version of the new EBSC block is determined to be incorrect, at block 718, the process of generating the backup version of the new EBSC and calculating the checksum is repeated until a correct checksum value is calculated, or until the process has been repeated a pre-specified number of times, N. Upon repeating the process the pre-specified number of times N without success, at block 736, the upgrade client uses resources of the client device to report the error to the client device user and the service provider's upgrade server, at block 780, and terminates the upgrade process, at block 726.

[0072] Upon verifying the accuracy of the backup version of the new EBSC, at block 718, the upgrade client replaces the original EBSC in the device ROM with the new EBSC, at block 720. Checksum calculations are performed on the new EBSC as written to the device ROM to verify the accuracy of the file. If the checksum value of the new EBSC is determined to be incorrect, at block 722, the process of writing the new EBSC to device ROM and calculating the checksum is repeated until a correct checksum value is calculated, indicating that the new EBSC was properly written to device ROM, or until the process has been repeated a pre-specified number of times, N. Upon repeating the process the pre-specified number of times N without success, at block 738, the upgrade client uses resources of the client device to report the error to the client device user and the service provider's upgrade server, at block 780, and terminates the upgrade process, at block 726.

[0073] Upon verifying the accuracy of the new EBSC as written to the device ROM, at block 722, the upgrade client determines whether additional difference files are available for use in upgrading corresponding original EBSCs, at block 724. Operation returns to block 706 to process any additional difference files; otherwise the upgrade process ends, at block 726.

[0074] When the upgrade client determines, at block 702, that the device is being recovered from errors that occurred during previous upgrade attempts, the upgrade client initiates recovery by determining whether a backup configuration file is available in the client device, at block 740. The backup configuration file includes backup configuration data. When backup configuration data is available, the upgrade client determines whether the backup configuration data is accurate by evaluating the associated checksum value, at block 742. If backup configuration data is not available in the client device, at block 740, or if backup configuration data is available and the checksum value indicates the data is in error, at block 742, the upgrade client uses resources of the client device to report the error to the client device user and the service provider's upgrade server, at block 760. The upgrade client then terminates the upgrade process, at block 762.

[0075] When error-free backup configuration data is available in the client device, the upgrade client writes the backup configuration data over the original configuration data in the original configuration file, at block 744. The upgrade client then determines the availability of a backup version of the new EBSC in the client device, at block 746.

[0076] If a backup version of the new EBSC is available in the client device, the upgrade client upgrades the original EBSC by writing the backup version of the new EBSC over the corresponding original EBSC in device memory, at block 748; the configuration data is subsequently upgraded in accordance with the new EBSC, at block 750. The upgrade client then determines whether additional difference files are available for use in upgrading other original EBSCs, at block 752. Operation returns to block 706 to process any additional difference files; otherwise the upgrade process ends, at block 726.

[0077] If a backup version of the new EBSC is found not to be available in the client device, at block 746, then the upgrade client retrieves the corresponding original EBSC from the upgrade server, at block 764. Upon receiving the original EBSC, the upgrade client proceeds with re-generating a new EBSC, at block 710, as described above.

[0078] Referring to FIGS. 4, 5, and 7, the operations of the flow diagrams are under control of at least one processor, but are not so limited. Each of the blocks depicted in these flow diagrams is of a type well known in the art, and can itself include a sequence of operations that need not be described herein. Those skilled in the relevant art can create source code, microcode, program logic arrays or otherwise implement the invention based on these flow diagrams and the detailed description provided herein. The algorithm or routine operating according to these flow diagrams is stored in non-volatile memory that forms part of the associated processors, in the associated memory areas, in removable media, such as disks, or hardwired or preprogrammed in chips, such as electronically erasable programmable ROM (“EEPROM”) semiconductor chips, or in any combination of these components, but is not so limited.

[0079] The components of the upgrade client described above include any collection of computing components and devices operating together. The components of the upgrade client can also be components or subsystems within a larger computer system or network. The upgrade client components can also be coupled among any number of components (not shown), for example other buses, controllers, memory devices, and data input/output (I/O) devices, in any number of combinations. Functions of the upgrade client components can be distributed among any number/combination of other processor-based components. The memory systems described above include, for example, various memory systems known in the art.

[0080] The self-upgrading upgrade client of an embodiment includes a portable communication device comprising an upgrade client coupled to a processor, the upgrade client including an upgrade sub-client and a self-upgrade sub-client, wherein the upgrade client receives upgrade files over a wireless coupling, wherein the upgrade sub-client automatically upgrades electronic applications of the device using contents of the upgrade files, wherein the self-upgrade sub-client automatically upgrades electronic applications of the upgrade client using contents of the upgrade files.

[0081] The electronic applications of the upgrade client of an embodiment include electronic applications of the upgrade sub-client and the self-upgrade sub-client.

[0082] The upgrade client of an embodiment further comprises a download sub-client that controls receipt of the upgrade files, wherein the electronic applications of the upgrade client include electronic applications of the download sub-client.

[0083] The upgrades of an embodiment include at least one of repairing errors in the electronic files and providing additional electronic files.

[0084] The processor of an embodiment automatically recovers the portable communication device to at least one operational state in response to a failure during the automatic upgrades.

[0085] The portable communication device of an embodiment is at least one of a cellular telephone, a portable computing device, and a personal digital assistant.

[0086] The upgrade client of an embodiment includes one or more operating modes that include at least one of a real-time operating system (RTOS) mode, an initial program load (IPL) mode, and a boot mode. The upgrade sub-client of an embodiment automatically upgrades electronic applications of the device during the IPL mode. The self-upgrade sub-client of an embodiment automatically upgrades electronic applications of the upgrade client during the boot mode. The download sub-client of an embodiment automatically controls at least one of downloading and storing of the upgrade files during the RTOS mode.

[0087] The upgrade sub-client of an embodiment is in a first memory area of the device and the self-upgrade sub-client is in a second memory area of the device.

[0088] The self-upgrading upgrade client of an embodiment includes a method comprising at least one of receiving an upgrade file at an upgrade client of a portable device, wherein contents of the upgrade file include at least one of information to repair errors in software applications and information to upgrade functions provided by the software applications, automatically upgrading software applications of the portable device when the contents are targeted for the portable device software applications, and automatically upgrading software applications of the upgrade client when the contents are targeted for the upgrade client software applications.

[0089] The method of an embodiment further comprises selecting an operating mode of the upgrade client in response to at least one of availability of the upgrade file and the contents of the upgrade file. The operating modes of an embodiment include at least one of a real-time operating system (RTOS) mode, an initial program load (IPL) mode, and a boot mode. The RTOS mode of an embodiment includes downloading of the upgrade file by a download sub-client of the upgrade client. The IPL mode of an embodiment includes automatically upgrading the portable device software applications. The boot mode of an embodiment includes automatically upgrading the upgrade client software applications.

[0090] The receiving of a method of an embodiment further comprises at least one of storing the upgrade file in a first memory area of the portable device, and generating a backup version of the upgrade file in a second memory area. The first memory area of an embodiment is one or more regions of a random access memory, and the second memory area is one or more regions of a read-only memory.

[0091] The receiving of a method of an embodiment further comprises verifying the contents of the upgrade file by applying at least one error checking and correction process to the contents, the at least one error checking and correction process including use of at least one of cyclic redundancy codes (CRC) and checksum values.

[0092] Automatically upgrading the upgrade client software applications of an embodiment further comprises at least one of generating a backup upgrade client by copying the upgrade client software applications from an operating location in a second memory area to a first memory area, generating a backup upgrade file by copying the contents of the upgrade file from the second memory area to the first memory area, and generating a new upgrade client by upgrading the upgrade client software applications using information of the backup upgrade client and the backup upgrade file. The method of an embodiment further comprises storing the new upgrade client in the first memory area. The automatic upgrading of the upgrade client software applications of an embodiment further comprises generating a backup new upgrade client by copying the new upgrade client to the second memory area. The automatic upgrading of software applications of the upgrade client of an embodiment further comprises at least one of deleting the upgrade client from the operating location, and copying the backup new upgrade client to the operating location.

[0093] The method of an embodiment further comprises automatically recovering the portable device to at least one operational state in response to a failure during the automatic upgrading of at least one of the portable device software applications and the upgrade client software applications.

[0094] The upgrade file contents of an embodiment include at least one of difference files and embedded software components.

[0095] The self-upgrading upgrade client of an embodiment includes a system for upgrading electronic files, comprising a first device including a first upgrade component that generates upgrade files, wherein the upgrade files include at least one of information to repair errors in electronic files and information to add functionality to the electronic files, and a mobile communication device comprising a second upgrade component that includes an upgrade sub-client and a self-upgrade sub-client, the second upgrade component receiving the upgrade files via a wireless coupling with the first device, the upgrade sub-client automatically upgrading electronic applications of the device using contents of the upgrade files, and the self-upgrade sub-client automatically upgrading electronic applications of the upgrade client using contents of the upgrade files.

[0096] The first device of an embodiment is a processor-based device accessible by at least one provider of software components hosted on the second device.

[0097] The mobile communication device of an embodiment includes at least one of cellular telephones, portable computing devices, and personal digital assistants.

[0098] The electronic files of an embodiment comprise software files including dynamic link library files, shared object files, embedded software components (EBSCs), firmware files, executable files, data files including hex data files, system configuration files, and files including personal use data.

[0099] The self-upgrading upgrade client of an embodiment includes a method comprising at least one of receiving an upgrade file at an upgrade client of a portable device, wherein contents of the upgrade file include at least one of information to repair errors in software applications and information to upgrade functions provided by the software applications, verifying the contents using at least one error checking and correction process, selecting an operating mode of the upgrade client in response to the contents, automatically upgrading software applications of the portable device when the contents are targeted for the portable device software applications, automatically upgrading software applications of the upgrade client when the contents are targeted for the upgrade client software applications, and automatically recovering the portable device to at least one operational state in response to a failure during the automatic upgrading of at least one of the portable device software applications and the upgrade client software applications.

[0100] The self-upgrading upgrade client of an embodiment includes a mobile communication device comprising at least one of means for receiving an upgrade file at an upgrade client of the device, wherein contents of the upgrade file include at least one of information to repair errors in software applications and information to upgrade functions provided by the software applications, means for automatically upgrading software applications of the device when the contents are targeted for the device software applications, and means for automatically upgrading software applications of the upgrade client when the contents are targeted for the upgrade client software applications.

[0101] The mobile communication device of an embodiment further comprises means for selecting an operating mode of the upgrade client in response to at least one of availability of the upgrade file and the contents of the upgrade file, wherein the operating modes include at least one of a real-time operating system (RTOS) mode, an initial program load (IPL) mode, and a boot mode.

[0102] The means for receiving of an embodiment further comprises at least one of means for storing the upgrade file in a first memory area of the portable device and means for generating a backup version of the upgrade file in a second memory area.

[0103] The means for automatically upgrading the upgrade client software applications of an embodiment further comprises at least one of means for generating a backup upgrade client by copying the upgrade client software applications from an operating location in a second memory area to a first memory area, means for generating a backup upgrade file by copying the contents of the upgrade file from the second memory area to the first memory area, and means for generating a new upgrade client by upgrading the upgrade client software applications using information of the backup upgrade client and the backup upgrade file.

[0104] The means for automatically upgrading the upgrade client software applications of an embodiment further comprises means for generating a backup new upgrade client by copying the new upgrade client to the second memory area.

[0105] The means for automatically upgrading software applications of the upgrade client of an embodiment further comprises at least one of means for deleting the upgrade client from the operating location and means for copying the backup new upgrade client to the operating location.

[0106] The mobile communication device of an embodiment further comprises means for automatically recovering the portable device to at least one operational state in response to a failure during the automatic upgrading of at least one of the portable device software applications and the upgrade client software applications.

[0107] The self-upgrading upgrade client of an embodiment includes a machine-readable medium including executable instructions which, when executed in a processing system, upgrade software in a portable device by at least one of receiving an upgrade file at an upgrade client of a portable device, wherein contents of the upgrade file include at least one of information to repair errors in software applications and information to upgrade functions provided by the software applications, automatically upgrading software applications of the portable device when the contents are targeted for the portable device software applications, and automatically upgrading software applications of the upgrade client when the contents are targeted for the upgrade client software applications.

[0108] Aspects of the upgrade client described herein may be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices (“PLDs”), such as field programmable gate arrays (“FPGAs”), programmable array logic (“PAL”) devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits. Some other possibilities for implementing aspects of the upgrade client include: microcontrollers with memory (such as EEPROM), embedded microprocessors, firmware, software, etc. Furthermore, aspects of the upgrade client may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. Of course the underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (“MOSFET”) technologies like complementary metal-oxide semiconductor (“CMOS”), bipolar technologies like emitter-coupled logic (“ECL”), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital; etc.

[0109] It should be noted that the various functions disclosed herein may be described using any number of combinations of hardware, firmware, and/or as data and/or instructions embodied in various machine-readable or computer-readable media, in terms of their behavioral, register transfer, logic component, and/or other characteristics. Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) and carrier waves that may be used to transfer such formatted data and/or instructions through wireless, optical, or wired signaling media or any combination thereof. Examples of transfers of such formatted data and/or instructions by carrier waves include, but are not limited to, transfers (uploads, downloads, e-mail, etc.) over the Internet and/or other computer networks via one or more data transfer protocols (e.g., HTTP, FTP, SMTP, etc.).

[0110] Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above,” “below,” and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word “or” is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.

[0111] The above description of illustrated embodiments of the upgrade client is not intended to be exhaustive or to limit the upgrade client to the precise form disclosed. While specific embodiments of, and examples for, the upgrade client are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the upgrade client, as those skilled in the relevant art will recognize. The teachings of the upgrade client provided herein can be applied to other processing systems and methods, not only for the memory systems and methods described above.

[0112] The elements and acts of the various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the upgrade client in light of the above detailed description.

[0113] In general, in the following claims, the terms used should not be construed to limit the upgrade client to the specific embodiments disclosed in the specification and the claims, but should be construed to include all processing systems that operate under the claims. Accordingly, the upgrade client is not limited by the disclosure, but instead the scope of the upgrade client is to be determined entirely by the claims.

[0114] While certain aspects of the upgrade client are presented below in certain claim forms, the inventor contemplates the various aspects of the upgrade client in any number of claim forms. For example, while only one aspect of the upgrade client is recited as embodied in computer-readable medium, other aspects may likewise be embodied in computer-readable medium. Accordingly, the inventor reserves the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the upgrade client.