Title of Invention

"A RADIO COMMUNICATION NETWORK SOFTWARE DOWNLOADING MEHTOD"

Abstract Radio communication network software downloading methods wherein terminal unique information pertaining to the downloading transaction is communicated on corresponding dedicated communication channels, for example, download initiation (300), capability exchange (320), digital signature (332) and activation and billing (360) communications, among others. Software content, or data, is transmitted (334) from the network to the plurality of terminals on a shared communication channel. In some applications, the software content includes multiple files multiplexed on the shared communication channel, wherein the content may be adjusted dynamically to optimize spectral efficiency.
Full Text The present invention relates to a radio communication network software downloading method.
FIELD OF THE INVENTIONS
The present inventions relate generally to comrnunications between radio access networks and mobile terminals therein, and more particularly to methods for downloading software to multiple terminals in wireless communication networks, for example in cellular communication networks.
BACKGROUND OF THE INVENTIONS
The emergence of many new wireless technologies, including Wireless Application Protocol (WAP), Java 2 micro-edition programs (J2ME), mobile execution environment (MexE) software, Software Definable Radio (SDR), Terminal Management, among many others, require over-the-air downloading of terminal software to multiple terminals in wireless communication networks. It will soon be desirable to download software files as large as several Mbytes, and the trend is toward the transfer of even larger files.
The over-the-air downloading of substantial software content in wireless communication networks, however, will likely impose significant burdens on the radio frequency spectrum resources allocated to network operators. In the future, as the code size of terminal software increases, network operators may be compelled to compensate users for software download air-time, for example with free air-time minutes, which is undesirable cost overhead for the network operators.
The Various aspects, features and advantages of the present inventions will become more fully apparent to those having ordinary skill in the
art upon careful consideration of the following Detailed Description of the Invention with the accompanying drawings, which are described below.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is an exemplary schematic of a basic software download process flow diagram.
FIG. 2 is an exemplary schematic of a wireless communication link block diagram corresponding to the basic software download process flow diagram of FIG. 1.
FIG. 3 is a more particular exemplary schematic of a software download process flow diagram.
FIG. 4 is an exemplary schematic of a wireless communication link block diagram corresponding to the more particular software download flow diagram of FIG. 3.
FIG. 5 is an exemplary wireless communication network in which the software download processes of the present invention may be practiced.
DETAILED DESCRIPTION OF THE INVENTIONS
The present inventions provide spectrally efficient means for over-the-air (OTA) downloading of software objects, or content, to multiple terminals in wireless communication networks, especially in networks where the population of terminals exceeds the number of unique software objects to be downloaded, for example, when all or several terminals in the network are to receive a software revision or upgrade. The invention is not limited to applications where only a
single, common software object is transmitted to multiple users or terminals.
The invention provides more generally for efficient simultaneous, or at least virtually simultaneous, downloading of multiple software objects to a plurality of terminals in wireless communication networks. Some terminals may receive some software content, and other terrninals may receive other content. In some embodiments, the dynamics of the software content transmitted by the network and received by the terminals changes dynamically as downloads are completed and new terminals enter into the network, as discussed further below.
Generally, the invention makes use of both shared (common) channels and dedicated (traffic) channels in hybrid, over-the-air software downloading schemes. The processes of the present inventions are implemented generally in several phases, otherwise referred to as communication exchanges between the terminals and network. For each phase, the communications between the network and terminals therein are allocated most efficiently to either a common channel or to a dedicated channel, depending upon the nature of the communication or exchange.
The communication phases involving the exchange of terminal unique informatipn are generally assigned to dedicated communicajion channels. Terminal unique information includes, for example, download initiation information exchanges, capability and non-repudiation information exchanges, activation and billing information exchanges, and other communications that inherently involve the transmission of relative small quantities of data. These small data content exchanges are only exemplary. There could be other information exchanges not listed, and not all of the exemplary exchanges are required. These and other communications are well suited for point-to-point or dedicated channels, since the volume of data exchanged is relatively small and the spectral inefficiency of dedicated channels is insignificant, at least relative to that associated with the transmission of software content having file sizes on the order
of 1 Mbyte or more.
Other communications occurring on dedicated channels include those for which optimum error protection is required, for example the transmission of digital signatures and other error sensitive information. In some applications, the desire for providing error protection may outweigh the benefits provided by reduced bandwidth associated with transmission of broadcast information over common channels.
The communication phases involving the transmission, or downloading, of substantial amounts of software objects or content from the network to one and preferably to multiple terminals in the network are assigned to common channels, which continuously stream downloadable content from the network to the terminals. In this way, the spectral requirement for the bandwidth intensive part of the download process is minimized. The data transfer typically involves relatively large quantities of data, e.g., terminal software content, sent primarily in the downlink direction to multiple terminals.
An example of a common channel is the Packet Broadcast Control Channel (PBCCH) of a GPRS network. An example of a dedicated channel is the Packet Data Traffic Channel (PDTCH) of a GPRS network. In the exemplary GPRS network implementation the invention, one or more PBOCHs could be allocated for purposes of broadcast software downloading.
The present inventions are not limited to applications in GPRS networks, but may be applied instead to any wireless communication standard employing some type of over-the-air (OTA) software download. The initial commercial opportunities for application of the present inventions will likely be in higher tier and smart terminal product markets, but in the not too distant future the transfer of substantial amounts of software content to mobile terminals will be commonplace at many if not most wireless communication network service levels.
In FIG. 1, the downloading of software from the network to a
terminal is initiated at block 100 on a dedicated channel. The initiation may be prompted by the network ox by the terminal. FIG. 2 generally characterizes the download initiation communications between the terminal 200 and the network 210 as a relatively small bi-directional data flow, which is allocated to a dedicated channel. The preliminary initiation exchanges, at least initially, will likely be transparent to the terminal user, although for some applications it could be user initiated and may require user input or response.
In FIG. 1, at block 120, download capability exchange information is exchanged between the network and the terrninal, and in FIG. 2 the information exchange is characterized generally as a relatively small bi-directional data flow, which as noted is also allocated to a dedicated channel.
In FIG. 1, the data content download occurs at block 130. FIG. 2 illustrates this data transfer as a large asymmetrical data transfer from the network 210 to the terminal 200, preferably to multiple terminals, which are not illustrated.
FIG. 1 illustrates, at block 140, a software installation step, which is a local process occurring at the terminal, as illustrated in FIG. 2. Generally, upon receipt of software download, or after installation thereof by or at the terminal, the terminal transmits a software receipt confirmation notification to the network. This low data content confirmation communication preferably occurs on a dedicated channel.
FIG. 1, at block 150, also illustrates the communication of non-repudiation information, and at block 160 activation and billing information, which are both characterized by small bi-directional data flows, preferably allocated to dedicated communication channels.
The process flow diagram of FIG. 3 illustrates some of the same information communicated between the network and terminal as illustrated in FIG. 1. Particularly, in FIG. 3, the download initiation 300 and capability exchange 320, installation 340, and the non-repudiation exchange 350, and activation and
billing exchange 360, which are not all essential, though typical in one form or another of a software content download transaction. Other exchanges, not illustrated, may also be included.
FIG. 3 also illustrates, in the data transfer block 330, the communication or transmission of a digital signature 332 generally during the data transfer phase 330 from the network to the plurality of terminals on the dedicated communication channel. FIG. 4 illustrates, with spatial correspondence relative to FIG. 3, whether the various exchanges in FIG. 3 are allocated to dedicated or common channels in the network.
In the well-known Public Key Infrastructure (PKI), a digital signature is produced and transmitted by the sender, which is the network in most embodiments of the present inventions. More particularly, the file or data to be transferred is initially converted to a "message digest" with a hashing function. The "message digest" is subsequently encrypted with the sender's private key, thus producing the digital signature. The PKI encryption application is only exemplary and the invention is not intended to be limited to any particular encryption scheme.
In the present invention, generally, the digital signature may be transmitted to the terminals from the network on either dedicated channels or on a shared channel, since the digital signature is common information. Transmission over a dedicated channel will, by virtue of its bi-directional nature, provide far superior error protection for the digital signature compared to transmission over a common channel. Therefore, in a preferred application, the digital signature 332 is transmitted on a dedicated channel, as illustrated in FIGS. 3 and 4.
The sender's public key can be installed in the terminal, for example in phone software, in a number of ways. The public key may be programmed in the handset by the manufacturer, for example by installing a ROM chip. An alternative is for the network operator to program the public key into the terminal
prior to selling the phone to a subscriber. Yet another alternative is to transmit the public key to the terminal, preferably via a dedicated channel. In this case, the \ public key could originate from a server controlled by either the equipment j manufacturer, or from the network operator, or from a Certificate Authority (CA). [
In FIG. 3, upon receipt of the data transmitted during the data transfer 334, the public key, a copy of which resides on the terminal, enables the authentication or verification 336 of the digital signature 332 in a local process occurring at the terminal. The integrity of the data may also be verified.
In some software download applications, the software content transmitted by the network comprises a plurality of different software files multiplexed on a shared communication channel for receipt by multiple terminals, thus providing different software content, which may be downloaded concurrently by different terminals.
In applications where two or more software files are multiplexed on the shared communication channel, the software content may be dynamically adjusted on the shared communication channel, for example to more efficiently accommodate the requirements of the terminals receiving the software.
In one application, the software content multiplexed on the shared communication channel is adjusted dynamically by adjusting a transmission time of each of the plurality of software files. Assume, for example, that the software download process is being managed for 1000 terminals in the network: 600 terminals require software object A; 300 terminals require software object B; and 100 terminals require software object C.
In one embodiment, software object A will be transmitted on the shared channel 60 percent of the time, and software objects B and C will be transmitted 30 percent and 10 percent of the time, respectively. The exemplary temporal proportions can be adjusted dynamically to accommodate changes in the number of terminals requiring the different software objects, for example as active
download processes are completed and new downloads are initiated as indicated upon completion of activation and billing exchanges and new initiation exchanges discussed above.
In another embodiment, the software content multiplexed on the/
shared communication channel is adjusted dynamically by adjusting the number!
of times each of the plurality of software files is transmitted. ,
In another embodiment, the software content multiplexed on the , shared communication channel is prioritized, for example, by giving higher priority to the transmission of content that generates greater amounts of revenue relative to the transmission of that which generates lesser amounts of revenue.
In another embodiment, the software content multiplexed on the shared communication channel is prioritized by giving higher priority to the transmission of software content that is more essential over that which is less essential, for example, operating system updates may be prioritized over application or optional software updates. The software content multiplexed on the shared communication channel may also be adjusted dynamically based upon file
i
size or content.
In the exemplary network architecture 500 of FIG. 5, a radio device management server 510 manages the download process for all terminals 520 in the radio access network 530. In some implementations, the server 510 generates a continuous software download stream, which is mapped to the physical shared channel. The Radio Device Management Server may thus dynamically adjust the proportionality and/ or priority of multiple software objects multiplexed onto the shared channel. The software download may be managed alternatively by means other than a dedicated management server.
The time multiplexed software download payloads can be fragmented using conventional packet transmissions. Packet protocols generally include headers having software checksums for positive identification of the
encapsulated payload, fragment index counters for identifying the current fragment in the overall payload, a next transmission field that informs the terminal when the next fragment will be transmitted, as is known generally by those having ordinary skill in the art.
The exemplary architecture of FIG. 5 includes a configuration management server 540 that contains a database that defines approved and, disapproved hardware and software configurations. The configuration management server 540 is may be managed for example by an equipment1 manufacturer, and made accessible by the Radio Device Management Server 510. The database on the configuration server 540 contains, for example, a unique identifier of the software ("type"), the software version indicator (software "revision"), and a cryptographic checksum ("checksum"), which collectively identify the software uniquely and allow verifying that it has been fetched correctly. This information can be presented to the Manufacturer's Software Download Server to fetch a copy of the designated software.
In other embodiments, the exemplary architecture of FIG. 5 also includes a configuration management server 550 containing new software releases, including core software. Content from the server can be electronically signed by the manufacturer, thus allowing the terminal device to process the content according to security protocols running in the terminal device (e.g. MExE). The configuration management server 550 is accessible by the radio device management server 510.
While the present inventions and what is considered presently to be the best modes thereof have been described in a manner that establishes possession thereof by the inventors and that enables those of ordinary skill in the art to make and use the inventions, it will be understood and appreciated that there are many equivalents to the exemplary embodiments disclosed herein and that myriad modifications and variations may be made thereto without departing
from the scope and spirit of the inventions, which are to be limited not by the exemplary embodiments but by the appended claims.





WE CLAIM:
1 A radio communication network software downloading method,
comprising:
communicating terminal unique information for the downloading of common software content from the network to a plurality of terminals in the network on corresponding dedicated communication channels for each terminal;
sending a message to a plurality of terminals on corresponding dedicated communication channels to receive the common software content on a shared channel;
transmitting the common software content from the network to the plurality of terminals on the shared communication channel after sending the message.
2. The method as claimed in claim 1, wherein it comprises receiving
a request for the common software content from a plurality of terminals
on corresponding dedicated communication channels for each terminal,
transmitting the common software content from the network to the plurality of terminals making the request on the shared communication channel after receiving the request;
receiving confirmation from each of the plurality of terminals that received the software content on corresponding dedicated communication channels for each terminal after transmitting.
3. The method as claimed in claim 1, wherein it comprises receiving
confirmation from each of the plurality of terminals that received the
common software content on corresponding dedicated communication
channels for each terminal after transmitting.
4. The method as claimed in claim 1, wherein it comprises
transmitting a digital signature from the network to a plurality of
terminals over corresponding dedicated communication channels for
each terminal;
transmitting the common software content from the network to the plurality of terminals on the shared communication channel after transmitting the digital signature.
5. The method as claimed in claim 1, wherein it comprises multiplexing a plurality of different common software content on the shared communication channel, dynamically adjusting the plurality of different common software content multiplexed on the shared communication channel.
6. The method as claimed in claim 5, wherein it comprises dynamically adjusting the plurality of different common software content in proportion to a changing number of the plurality of terminals receiving the plurality of different common software content.
7. The method as claimed in claim 5, wherein it comprises dynamically adjusting the plurality of different common software content based on a priority factor.

Documents:

2002-delnp-2004-abstract.pdf

2002-DELNP-2004-Assignment-(23-12-2011).pdf

2002-delnp-2004-assignment.pdf

2002-delnp-2004-claims.pdf

2002-delnp-2004-complete specifiation (granted).pdf

2002-DELNP-2004-Correspondence Others-(01-02-2012).pdf

2002-DELNP-2004-Correspondence Others-(23-12-2011).pdf

2002-delnp-2004-correspondence-others.pdf

2002-delnp-2004-correspondence-po.pdf

2002-delnp-2004-description (complete).pdf

2002-delnp-2004-form-1.pdf

2002-DELNP-2004-Form-16-(23-12-2011).pdf

2002-delnp-2004-form-19.pdf

2002-delnp-2004-form-2.pdf

2002-delnp-2004-form-24.pdf

2002-delnp-2004-form-3.pdf

2002-delnp-2004-form-4.pdf

2002-delnp-2004-form-5.pdf

2002-DELNP-2004-GPA-(01-02-2012).pdf

2002-DELNP-2004-GPA-(23-12-2011).pdf

2002-delnp-2004-gpa.pdf

2002-delnp-2004-pct-101.pdf

2002-delnp-2004-pct-102.pdf

2002-delnp-2004-pct-105.pdf

2002-delnp-2004-pct-202.pdf

2002-delnp-2004-pct-301.pdf

2002-delnp-2004-pct-308.pdf

2002-delnp-2004-pct-332.pdf

2002-delnp-2004-pct-401.pdf

2002-delnp-2004-pct-402.pdf

2002-delnp-2004-pct-409.pdf

2002-delnp-2004-pct-416.pdf

2002-delnp-2004-petition-137.pdf

2002-delnp-2004-petition-138.pdf


Patent Number 230360
Indian Patent Application Number 2002/DELNP/2004
PG Journal Number 13/2009
Publication Date 27-Mar-2009
Grant Date 26-Feb-2009
Date of Filing 12-Jul-2004
Name of Patentee MOTOROLA INC.
Applicant Address 1303 EAST ALGONQUIN ROAD, SCHAUMBURG, ILLINOIS 60196 U.S.A.
Inventors:
# Inventor's Name Inventor's Address
1 KENNETH RIORDAN 7223 PIERCESHIRE ROAD, SPRING GROVE, IL 60081 U.S.A.
PCT International Classification Number G06F 15/16
PCT International Application Number PCT/US2003/003347
PCT International Filing date 2003-02-04
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 10/083,876 2002-02-27 U.S.A.