Title of Invention

"A DATA COMPRESSION TRANSMITTER SYSTEM FOR OPTIMALLY COMPRESSING A SOFTWARE SPECIFICATION"

Abstract A system and method for optimally compressing a software specification software language (100) includes supplying the software specification that is compressed (103) using a custom process. The customized software specification is then again compressed (105) using a standard compression techniques where it is converted to a optimized format that is a substantially smaller in size than the first format. This permits a optimally compressed format of the software specification to be distributed (105) to one or more electronic devices using limited bandwidth. The electronic device is then able to decompress (107, 109) the optimally compressed format using a corresponding decompression process where it can be submitted (109) for automatic code generation and processing.
Full Text This invention relates in general to a data manipulation and more specifically to electronic data compression.
A software specification provides a means to deliver functionality to an electronic device. With the addition of new software, the electronic device can have the capability to perform different tasks or be used in different environments. This is particularly true with cellular telephone devices, but also applies to other types of devices.
Since different mobile telecommunication networks throughout the world use different protocols, one cellular telephone does not have the capability to operate everywhere. With the ability to deliver a software specification to the cellular telephone, it is possible to modify the functionality of the cellular telephone such that is able to access different mobile telecommunication networks. This would then allow the cellular telephone to operate in any location. With this capability, the user would not need to buy a different cellular telephone for each different mobile telecommunications network he wishes to access.
Languages such as specification and description language (SDL) can provide an electronic device, such as the cellular telephone, with a new software specification allowing it to utilize a specific mobile telecommunication device protocol for one or more regions of the world. It is also possible to automatically generate executable software from a high level software specification language, such as SDL [Ref: SDL-92, S. Olsen et al, Pub: North Holland, 1994], In addition to SDL, many other software specification languages, such as ESTELLE™, LOTOS™, ADA™, C™, etc. can be used for the same purpose.
In order to transmit and deliver the software specification to a mobile radio or cellular telephone in an expeditious manner, it is often necessary to compress the software code to efficiently use mobile telecommunication network bandwidth resources. This is shown in FIG. 1, where the software code can be transmitted from the mobile radio infrastructure 10 to one or more stations 11. Additionally, the software code can also be transmitted from a station 11 to the mobile radio infrastructure 10 where the infrastructure can be informed of various station requirements.
Commercially available software tools such as SDT™ produced by TELELOGIC can provide automatic code generation capability for specific software specification languages. This automatic code generation capability permits a change in the functionality of the electronic device by delivering a software specification file to the device rather than an executable file. Upon receiving the software specification file, the device, such as a cellular telephone, can perform an automatic code generation process. As a result of this automatic code generation process, the device can then obtain the required executable file.
There are a number of advantages in using a high level software language, such as SDL, as the means for delivering new functionality to an electronic device. One of the major advantages is that SDL allows the high level language to be written such that the software language description, of the required functionality, can be fully independent of the specific implementation of the target (e.g. memory addressing, microprocessor, clock speed, etc.). By exploiting this feature, one can use the same software description to modify the functionality of a number of different electronic processing platform implementations. This avoids the need to create, store and accurately distribute multiple implementations of essentially the same functionality for each individual platform implementation.
Whatever the form of the specification file, it will be important to keep the byte size of the file to a minimum in order to minimize the bandwidth and overall cost of transferring the specification file to the
device. In addition, the smaller the size of the specification file, the lower the probability of error insertion during the process of delivering the specification to the device. This can be particularly important in wireless applications. Additionally, there are a number of standard compression formats and supporting tools, such as ZIP™ format and the "compress" command, that are available on many engineering computer workstations. These software tools are generic in purpose and their performance is sub-optimal in many applications.
Thus, the needs exists to provide an efficient method for compressing a software specification prior to distribution to an electronic device. Additionally, the method must ensure that the electronic device utilizes the complementary method by which the device recovers the specification prior to automatic code generation.
Summary of the Invention
A data compression transmitter system for optimally compressing a software specification for transmission to an electronic device in communication network comprising: a custom compressor for converting the software specification into a customized format; a standard compressor for converting the customized format into an optimized format; at least one transmitter controller for controlling compression of the software specification in the custom compressor and the standard compressor; and a transmit driver for conveying the optimized format through at least one transmission media.
Brief Description of the Drawings
FIG. 1 is a block diagram showing down loading of software code from a mobile telecommunication network infrastructure to one or more stations;
FIG. 2 is a block diagram illustrating the component structure of a optimal compression system according to a preferred embodiment of the invention;
FIG. 3 is a flow chart illustrating a method for optimally compressing a software language;
FIG. 4 is a flow chart illustrating the main component functions of a custom compression function of FIG. 3, and
FIG. 5 is a is a flow chart illustrating the component functions of the specification transformation function.
Detailed Descrition of the Preferred E
Referring now to FIG. 2, a data communication and compression network 10 for providing optimized compression of a software specification language includes a transmitter compression system 12 and a receiver decompression system 14 where the transmitter compression system 12 acts to optimally compress data prior to transmission of the data to the receiver decompression system 14 using either a physical or wireless interface 16. It will be recognized by those skilled in the art that the wireless interface 16 may a include radio frequency (RF) link, infra-red (IR) link or the like.
In the transmitter compression system 12, a software specification store 18 is used to store software code such as a software specification language. The software specification store 18 forwards a software specification that will be compressed by a custom compressor 20. The custom compressor 20 includes a number of unique components that are capable of converting the software specification into a custom compressed format. These components include a non-functional character eliminator 22, a symbol set translator 24 and a specification language translator 26.
As will be discussed in further detail hereinafter, the nonfunctional character eliminator 22 acts to remove non-functional character data from the software code. This non-functional character data includes spaces, blank lines and comments within the software specification. The symbol set translator 24 works to identify and replace non-keyword tokens with software codes with shorter sequences of characters. The non-keyword tokens include variable identifiers, procedure identifiers, function identifiers, macro identifiers, constant Accordingly there is provided a data compression transmitter system for optimally compressing a software specification for transmission to an electronic device in a communication network, the system comprising:
a custom compressor for converting the software specification into a customized format using components defined for that specific software;
a standard compressor for converting the customized format into an optimized format;
at least one transmitter controller for controlling compression of the software specification in the custom compressor and the standard compressor; and
a transmit driver for conveying the optimized format through at least one transmission medium.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram showing down loading of software code from a mobile telecommunication network infrastructure to one or more stations;
FIG. 2 is a block diagram illustrating the component structure of a optimal compression system according to a preferred embodiment of the invention;

identifiers and other user defined character sequences. Thus, subjective commands that have been identified within the software specification by the programmer can be shortened to reduce storage space and/or transmission time.
The language translator 26 further customizes the specification transformation function by replacing the normally long strings of software code that represent the various keyword tokens with short strings of customized software code. Thus, software code that is an intrinsic part of the software language, such as predetermined software language instructions, can be further shortened to provide a customized compression of the software specification.
The customized version of the software specification is then further compressed using a standard compressor 28. The standard compressor 30 can use a commonly used standard compression format such as the ZIP™ format or the like. Each of the components within the custom compressor 20 as well as the standard compressor 30 is controlled by a transmitter controller 30. The transmitter controller 30 coordinates the custom compression and standard compression where the optimally compressed data is subsequently transmitted using a transmit interface driver 32. The optimally compressed data can be used in a variety of applications in order to convey the software specification using limited bandwidth and decreased network resources due to compressed size of the optimally compressed data.
After transmission through the interface 16, a receiver decompression system 14 will generally be used with an electronic device having the capability to decompress and process the software specification in substantially the original form of the software specification. The receiver decompression system 14 includes a receiver interface driver 34 that receives the optimally compressed data. The optimally compressed data is forwarded to a standard decompresser 36 where the optimally compressed data is decompressed using a standard format to again produce the software specification in a custom compressed format.
The custom compressed data is then subjected to a custom decompresser 38 having a language recovery translator 40. The language recovery translator 38 again reconverts and replaces the custom keywords with the original standard keywords. There will be no need to fully reconvert the software specification back to the original form of the software specification, since functionally the output of the custom decompresser 38 is identical to the original software specification. At this point in the custom decompressed format, the software specification is again readable in the original software language of the software specification. It will be readable by a microprocessor associated with the electronic device but will be in a pseudo-custom form. While in pseudo-custom form the software specification is only partially in a pre-compressed state; the pseudo-custom form does not include non-functional character data nor subjective names for non-keyword tokens.
At the output of the custom decompresser 38, the partially customized software specification is subjected to an automatic code generator 42 where appropriate software code is generated for use by the electronic device. A receiver controller 44 is used to control each of the foregoing functions and also works to control a loader 46 to input the new software code into an executable code store 48 where the new software code can be used by the electronic device or any application equipment 50.
In FIG. 3, the method for optimally compressing a software specification language 100 includes a number of unique steps. In the following illustration, Specification and Description Language (SDL) is the software specification language used in the compression process. It should be recognized however, that the same approach could be used for any other software specification languages, such as ESTELLE™ and LOTOS™ and for particular languages commonly used as programming languages such as C™ and ADA™.
The novel aspects of this invention include the insertion of a custom compression step or function 101 and a custom decompression function 109 into the overall process for optimally compressing the software
specification. The custom compression and decompression functions are customized in the sense that they are specific to the specification language used as an input to the automatic code generation function. Despite this customization process, as noted above, these principles can be applied to any number of different software languages.
Generally after the custom compression step 101, the preferred method of the invention includes the step of providing a standard generic compression 103 of the custom compressed data. Thereafter, the optimally compressed data is distributed 105 to an electronic device. The electronic device will include circuitry and software to first provide a standard decompression 107 of the optimally compressed data. This is then followed by a custom decompression 109 where an automatic code generation 111 can be performed on the compressed SDL to generate an executable set of instructions to be loaded into the executable code store 48 and subsequently used by the equipment hardware.
In FIG. 4, additional details are shown of the custom compression step 101 including a specification transformation function 201. The specification transformation function 201 can be defined as a collection of functions which together remove any un-necessary characters from the original SDL text file. In addition, the SDL specification will generally be written by human action. Consequently, the SDL specification can be expected to contain many long character strings. The character strings act as symbols, by which variables, code functions and/or similar intrinsic character structures may be defined and identified.
As is well known in the art, long character strings are typically used by a software engineer or programmer writing the software code. The character strings assist in the human intelligibility and recognition of the software specification. A disadvantage of using the character strings as described above however, is that the long character strings are of no particular value for the ensuing automatic code generation processes. Therefore, during the custom compression step 101, the long character strings are exchanged or replaced by new
shorter character strings. In addition, any functionless data such as spaces, blank lines and comments in the specification are removed.
As illustrated in FIG. 5, further detail is shown for the steps involved in the specification transformation function 201. The first step in the specification transformation function 201 includes removing functionless information and data, for example, deleting or removing spaces, blank lines and comments 301 from the software code. The spaces, blank lines and/or comments are frequently present in the specification in order to format a file containing the software code, making it easier to read for the software engineer or programmer.
The removal of the spaces and blank lines is achieved by reading in the file, character-by-character, and then determining whether each character is a space or a blank line. Additionally, a determination is also made whether the spaces or blank lines can be deleted or eliminated altogether from the software code. This is achieved by evaluating each individual character in the code and determining a position relative to any adjacent characters. Moreover, comments within the code are also candidates for removal. The removal of any comments however, must also be treated carefully, since specifically formatted comments are often used as compiler directives. In this event, those comments should not be removed.
To even further transform the SDL code into a customized format, a translate symbol set function 303 searches the software code or text for each individual non-keyword token. A determination is made whether each individual non-keyword token represents a symbol. The non-keyword token is a programmer defined sequence of characters used, for example, to identify a function, variable, constant, procedure, macro or other user defined character sequence or value.
If the non-keyword token does represent a symbol, the symbol is tested against any previous occurrence of that symbol. If the symbol has not been encountered before, then a new symbol of minimum length is generated from a predictable algorithm. The new symbol is then substituted in the place of the old symbol. If the individual symbol
has been encountered before, then the same replacement symbol is used to replace the new instance of the symbol.
Thus, the translated symbol set function 303 has the effect of replacing or exchanging the normally long code strings, that represent the non-keyword functions by short strings. The final output of the specification transformation function 201 results in a compressed SDL file, that is still valid SDL and can be read and understood by a commercial SDL tool.
Moreover, to further custom compress the SDL text file, a language transformation function 203 is next used. The language transformation function 203 changes the actual format and intelligibility of the SDL language. It will also change the language of any allowable code insert language, such as C. The principles by which the languages are changed are similar to those by which symbol names were changed as described above. Each keyword token, which defines the language syntax in a form which is meaningful to one reading the software such as a programmer, is replaced by a shorter string of characters.
In essence, the language transformation function 203 searches the text for each individual keyword token or language unit. If the token is a language keyword, such as "end", "system", etc., the token is tested against any previous occurrence of that token. If the symbol has not been previously encountered, then a new token of minimum size is generated from a predictable algorithm and the new token is exchanged or substituted in the place of the old token. If the individual token has been previously encountered, then the same replacement token is used to replace the new instance of the token. Thus, the language transformation function 203 has the effect of replacing the normally long strings of software code that represent the various tokens with short strings of customized software code.
Again referring to FIG. 3, following the custom compression function, a standard compression function 103 is then applied to the SDL in custom format. A commonly used standard compression format is the ZIP ™ format that would work well in this application.
The combination of the custom compression plus the standard compression is considerably more effective at compressing the SDL than merely applying standard compression alone.
Based upon experimentation, it has been shown that using a ZIP format standard compression alone can reduce an SDL file to approximately 15% of the original size (measured in bytes). However if custom compression as described herein is first applied to the standard SDL file, the combination of custom compression followed by standard compression into ZIP format will reduce the SDL file to approximately 7% of the original size (measured in bytes).
As compared to a ZIP format compression alone, only half the bandwidth is required to distribute the functionality to an electronic device. Moreover, additional experimentation has shown that the optimal compression of software code utilizes a custom compression followed by a standard ZIP compression that results in a file size which is in the region of 8% of the resultant executable file size.
As indicated above, the electronic device applies the standard decompression 109, which exactly reverses the alterations made by the standard compression applied earlier. Standard decompression is followed by custom decompression, which can reverse the changes made by the language transformation function 203. This occurs by replacing the tokens representing the SDL keywords and inserting the actual keywords that were originally exchanged during the compression process.
Specifically, during decompression a standard decompression function 107 is then applied to the optimally compressed format. As indicated above, a commonly used standard decompression format is the ZIP™ format. Thereafter, a language recovery translator searches the text for each token that was replaced for an individual keyword token or language unit. As in the customized compression of the data, the language recovery translator has the effect of replacing the short strings of custom software code with the long strings of software code that were originally replaced in the compression process.
Thus, during the software language recovery process, a language recovery translation changes the SDL language back to a format which is compliant with the SDL language standards. As indicated above, it often will not be necessary to fully reconvert the SDL specification back into the original form of the SDL specification. A language recovery translator can be used to convert the custom compressed software code into a pseudo-custom code. This would be accomplished by merely replacing a portion of the code that was originally replaced. For example, only partial conversions could be done, such that those parts of the software specification, converted by the specification transformation function 201, would be reinserted.
Although the software language is translated back to the original form with keyword tokens reinserted, the code still contains no functionless data nor does it include the original non-keyword token identifiers. Hence, the resultant de-compressed SDL text file is a valid SDL file, that can be used with a standard SDL automatic code generation function. The pseudo-custom SDL is then conveyed to an automatic code reader. As an alternative to applying the custom decompression function, it is also possible to modify the SDL automatic code generation function so that it will accept and recognize the SDL specification in a custom format. This will avoid the need to apply the custom decompression function in the receiving device.
While the preferred embodiments of the invention have been illustrated and described, it will be clear that the invention is not so limited. Numerous modifications, changes, variations, substitutions and equivalents will occur to those skilled in the art without departing from the spirit and scope of the present invention as defined by the appended claims.


We Claim:
1. A data compression transmitter system for optimally compressing a
software specification for transmission to an electronic device in a
communication network, the system comprising:
a custom compressor for converting the software specification into a customized format using components defined for that specific software;
a standard compressor for converting the customized format into an optimized format;
at least one transmitter controller for controlling compression of the software specification in the custom compressor and the standard compressor; and
a transmit driver for conveying the optimized format through at least one transmission medium.
2. A system as claimed in claim 1, wherein the custom compressor has:
a non-functional character eliminator for removing at least one nonfunctional character from the software specification;
a symbol set translator for replacing at least one non-keyword token into a shorter sequence of characters; and
a language translator for exchanging at least one keyword token in the software specification into a shorter sequence of characters.
3. A system as claimed in claim 2, wherein the at least one non-keyword
token has variable identifier, procedure identifiers, function identifiers, macro
identifiers, constant identifiers and other user defined character sequences.
4. A system as claimed in claim 2, wherein the at least one keyword token
has predetermined software language instructions.
5. A system as claimed in claim 1, wherein the transmitter system forms
part of a mobile radio infrastructure to at least one mobile radio.
6. A system as claimed in claim 1, wherein the transmitter system forms
part of a mobile radio and the electronic device is a mobile radio
infrastructure.
7. A system as claimed in claim 1, comprising a data decompression
receiver for decompressing an optimally compressed software specification for
use by an electronic device in a communication network, the receiver has:
a standard decompresser for converting an optimally compressed software specification from at least one transmission medium into a customized format;
a custom decompresser for converting the customized format into a pseudo-customized format;
a code generator for generating executable software code for use by the electronic device; and
at least one receiver controller for controlling decompression of the software specification in the standard decompresser and the custom decompresser.
8. A system as claimed in claim 7, wherein the custom decompresser
comprises:
a language recovery translator for translating data in the customized format into a pseudo-customized format for use by the code generator.
9. A system as claimed in claim 7, wherein the pseudo customized format
is used in at least one mobile radio.
10. A system as claimed in claim 7, wherein the receiver system forms part
of a mobile radio infrastructure.
11. A data compression transmitter system substantially as herein described with reference to and as illustrated in the accompanying drawings.

Documents:

1103-del-1997-abstract.pdf

1103-DEL-1997-Assignment-(15-12-2010).pdf

1103-DEL-1997-Assignment-(25-03-2011).pdf

1103-DEL-1997-Claims.pdf

1103-DEL-1997-Correspondence-Others-(15-12-2010).pdf

1103-DEL-1997-Correspondence-Others-(25-03-2011).pdf

1103-del-1997-correspondence-others.pdf

1103-del-1997-correspondence-po.pdf

1103-DEL-1997-Description (Complete).pdf

1103-del-1997-drawings.pdf

1103-del-1997-form-1.pdf

1103-del-1997-form-13.pdf

1103-del-1997-form-19.pdf

1103-DEL-1997-Form-2.pdf

1103-del-1997-form-4.pdf

1103-del-1997-form-6.pdf

1103-DEL-1997-GPA-(15-12-2010).pdf

1103-del-1997-GPA-(24-04-2012).pdf

1103-DEL-1997-GPA-(25-03-2011).pdf

1103-del-1997-gpa.pdf

1103-del-1997-Petition Others-(24-04-2012).pdf

1103-del-1997-petition-137.pdf


Patent Number 246609
Indian Patent Application Number 1103/DEL/1997
PG Journal Number 10/2011
Publication Date 11-Mar-2011
Grant Date 07-Mar-2011
Date of Filing 29-Apr-1997
Name of Patentee MOTOROLA, LIMITED
Applicant Address JAYS CLOSE, VIABLES INDUSTRIAL ESTATE, BASINGSTOKE, HAMPSHIRE RG22 4PD, ENGLAND.
Inventors:
# Inventor's Name Inventor's Address
1 BAKER PAUL DOMINIC 7 HEATH CLOSE, FAIR OAK, HAMPSHIRE, SO5 7JU
2 ROBINSON WILLIAM NEIL 6 ALEE DE PLANTIER DU ROI, 78860 SAINT NOM LA BRETECHE, FRANCE
PCT International Classification Number H03M 7/30
PCT International Application Number N/A
PCT International Filing date
PCT Conventions:
# PCT Application Number Date of Convention Priority Country
1 PCT/EP97-01478 1997-03-24 PCT