CA2252045C - Recompression server - Google Patents
Recompression server Download PDFInfo
- Publication number
- CA2252045C CA2252045C CA002252045A CA2252045A CA2252045C CA 2252045 C CA2252045 C CA 2252045C CA 002252045 A CA002252045 A CA 002252045A CA 2252045 A CA2252045 A CA 2252045A CA 2252045 C CA2252045 C CA 2252045C
- Authority
- CA
- Canada
- Prior art keywords
- file
- compressed
- node
- distinct
- network system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/75—Indicating network or usage conditions on the user display
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Information Transfer Between Computers (AREA)
Abstract
A recompression server (20) that automatically decompresses selected pre-compressed data streams and recompresses the decompressed data to a greater degree than the original pre-compressed data. In one embodiment, the recompression server (20) determines from a request whether a requested file is pre-compressed. In another embodiment, the recompression server (20) determines from a retrieved requested file's name or attributes whether the file is pre-compressed. Optionally, the recompression server (20) may cache frequently requested files in re-compressed form to further optimize the bandwidth of a wide area network (8). Such caching can be done on-line or off-line.
Description
RECOMPRESSION SERVER
BACKGROUND OF THE INVENTION
1. Field of the Invention This invention relates to electronic computers and network systems, and more particularly to a network server for automatically decompressing selected pre-compressed data streams and recompressing the decompressed data to a greater degree than the original pre-compressed data.
BACKGROUND OF THE INVENTION
1. Field of the Invention This invention relates to electronic computers and network systems, and more particularly to a network server for automatically decompressing selected pre-compressed data streams and recompressing the decompressed data to a greater degree than the original pre-compressed data.
2. Description of Related Art FIGURE 1 is a diagram of a prior art wide area public network system, such as the Internet. A first node 2 (which may be a workstation, a terminal, a personal computer, or the like), can communicate with a second node 4 (which may be a network server, a minicomputer or mainframe computer, a personal computer, or the like) by an apparently direct connection 6. In reality, the connection between node 2 and node 4 is made through a network "cloud" of connections 8, generally through one or more "proxy"
server computers 10 that help route requests through the network S. Such proxy server computers 10 generally include storage devices 12 for storing various sorts of data.
Each connection between a pair of nodes 2, 4 consumes some amount of communication bandwidth. In order to conserve bandwidth, it is common to pre-compress files to be transmitted from one node 2 to another 4. For example, graphics images may be pre-compressed using commonly available file formats, such as the Graphics Interchange Format (GIF), Tagged Interchange File Format (TIFF), and JPEG. (It should be understood that the term "files" as used herein includes live data streams, collections or archives of files, portions of files, data blocks, etc.) One drawback of the present system is that such pre-compressed files may not be optimally compressed, thus wasting bandwidth. However, a requestor node 2 generally has no ability to cause a provider node 4 to optimize compression of requested files.
Another existing problem is that many files on provider nodes 4 are not pre-compressed at all. While some compression may be achieved automatically by use of transport protocols or modems that include a compression function, there is no general solution to this problem.
The present invention is based on the inventor's recognition of a need for optimizing bandwidth usage in a network system for pre-compressed data files, and a need for general method of compressing files that are not pre-compressed.
The present invention provides a solution to these problems.
WO 97/38434 PCT/[JS97/06005 SUMMARY OF THE INVENTION
The present invention is a recompression server that automatically decompresses selected pre-compressed data streams and recompresses the decompressed data to a greater degree than the original pre-compressed data. In one embodiment, the recompression server determines from a request whether a requested file is pre-compressed. In another embodiment, the recompression server determines from a retrieved requested file's name or attributes whether the file is pre-compressed.
Optionally, the recompression server may compress requested but previously uncom-pressed files. As another option, the recompression server may cache frequently requested files in re-compressed form to further optimize the bandwidth of a wide area network.
Such caching can be done on-line or off-line.
The details of the preferred embodiment of the present invention are set forth in the accompanying drawings and the description below. Once the details of the invention are known, numerous additional innovations and changes will become obvious to one skilled in the art.
server computers 10 that help route requests through the network S. Such proxy server computers 10 generally include storage devices 12 for storing various sorts of data.
Each connection between a pair of nodes 2, 4 consumes some amount of communication bandwidth. In order to conserve bandwidth, it is common to pre-compress files to be transmitted from one node 2 to another 4. For example, graphics images may be pre-compressed using commonly available file formats, such as the Graphics Interchange Format (GIF), Tagged Interchange File Format (TIFF), and JPEG. (It should be understood that the term "files" as used herein includes live data streams, collections or archives of files, portions of files, data blocks, etc.) One drawback of the present system is that such pre-compressed files may not be optimally compressed, thus wasting bandwidth. However, a requestor node 2 generally has no ability to cause a provider node 4 to optimize compression of requested files.
Another existing problem is that many files on provider nodes 4 are not pre-compressed at all. While some compression may be achieved automatically by use of transport protocols or modems that include a compression function, there is no general solution to this problem.
The present invention is based on the inventor's recognition of a need for optimizing bandwidth usage in a network system for pre-compressed data files, and a need for general method of compressing files that are not pre-compressed.
The present invention provides a solution to these problems.
WO 97/38434 PCT/[JS97/06005 SUMMARY OF THE INVENTION
The present invention is a recompression server that automatically decompresses selected pre-compressed data streams and recompresses the decompressed data to a greater degree than the original pre-compressed data. In one embodiment, the recompression server determines from a request whether a requested file is pre-compressed. In another embodiment, the recompression server determines from a retrieved requested file's name or attributes whether the file is pre-compressed.
Optionally, the recompression server may compress requested but previously uncom-pressed files. As another option, the recompression server may cache frequently requested files in re-compressed form to further optimize the bandwidth of a wide area network.
Such caching can be done on-line or off-line.
The details of the preferred embodiment of the present invention are set forth in the accompanying drawings and the description below. Once the details of the invention are known, numerous additional innovations and changes will become obvious to one skilled in the art.
BRIEF DESCRIPTION OF THE DRAWINGS
FIGURE 1 is a diagram of a prior art wide area network system, such as the Internet.
FIGURE 2 is a diagram of the preferred hardware embodiment of the present invention.
FIGURE 3 is a block diagram showing the flow of selected data through the recompres-s sion server of FIGURE 2.
FIGURE 4 is a flowchart showing the method of a first embodiment of the present invention.
FIGURE 5 is a flowchart showing the method of a second embodiment of the present invention.
Like reference numbers and designations in the various drawings refer to like elements.
DETAILED DESCRIPTION OF THE INVENTION
Throughout this description, the preferred embodiment and examples shown should be considered as exemplars, rather than as limitations on the present invention.
FIGURE 2 is a diagram of the preferred hardware embodiment of the present invention.
The diagram shown in FIGURE 2 is similar to the diagram shown in FIGURE 1. A
requester 2' (for example, a web browser on the World Wide Web service provided by the Internet) can send file requests to a provider 4' (for example, a web server on the Internet) via a network 8. Each request is processed through a recompression server 20 in accordance with the present invention.
The recompression server 20 includes a web proxy server 10' having an optional cache 22. The recompression server 20 also includes a data path from the web proxy server 10' along a first connection 23 through a decompressor 24, along a second connection 25 through a recompressor 26, and along a third connection 27 back to the web proxy server 10'.
The components along the data path 23-27 can comprise hardware, a software or firmware programmed dedicated processor, or simply be software routines executed on the general processor(s) of the web proxy server 10', as a matter of design choice.
FIGURE 3 is a block diagram showing the flow of selected data through the recompres-sion server of FIGURE 2. When a file requested from a provider 4' passes through the recompression server 20, a determination is made in the web proxy server 10' whether the file is pre-compressed. If so, the compressed data 23 is routed along a first connection 23 to a decompressor 24. For example, if a requested data file is a graphics imaged compressed using the GIF standard, the file extension (.GIF) indicates that the file is pre-compressed. The file would be routed through the decompressor 24, which includes conventional decompression code for decompressing the GIF file. The decompressed data is routed along a second connection 25 (either directly or after temporary storage, such as in RAM or a mass storage device) to a recompressor 26.
The recompressor 26 re-compresses the decompressed data using any algorithm that provides a better compression ratio than the original compression. More than one recompression algorithm may be used if desired, to provide better compression for different data types. In the preferred embodiment, the algorithm used by the recompressor 26 for graphics files is a variable-loss (which includes no loss) compression algorithm called "GT", available from the former Johnson-Grace, Inc. of Newport Beach, California (now America Online, of Virginia). This algorithm can give file sizes from 15%
(for zero loss) to 70% smaller than the GIF standard, depending on desired degree of loss. Other algorithms, or combinations of algorithms, may be used, such as Huffman Coding, Lempel-Ziv '77, Lempel-Ziv '78, and Lempel-Ziv-Welch algorithms for lossless compression, and MPEG, JPEG, wavelet, and fractal algorithms for lossy compression.
After passing through the recompressor 26, the recompressed data passes along a third connection 27 back to the web proxy server 10' for transmission to the requester 2'.
As an optional step, the recompressed file may be cached in that form within the web proxy server 10' in a mass storage cache 22 (FIGURE 2), so that faster response can be provided to requestors 2' for frequently requested pre-compressed files. Any caching algorithm may be used, such as a conventional "least recently used" (LRU) algorithm, to manage the cache 22. Alternatively, the web proxy server 10' may maintain a log of file requests, and select files to be recompressed and cached based upon logged request frequencies. Caching may be done on-line, while recompressing files, or off-line, using logged request frequencies to retrieve "popular" files and recompress them during idle time for the web proxy server 10'.
WO 97/38434 - ~- PCT/US97/06005 As another option, the recompression server 20 may compress requested but previously uncompressed files. This aspect of the invention is advantageously used with the caching option, since frequently requested uncompressed files can be compressed and cached within the recompression server 20 so that network bandwidth is conserved each time such a file is requested thereafter.
The invention may be implemented as a computer program storable on a media that can be read by a computer system, such as a web proxy server 10', so as to configure the computer system to provide the functions described herein. Again, while the invention has been described as if executed on a separate processor, it may be implemented as a software process executed within the web proxy server 10.
FIGURE 4 is a flowchart showing the method of a first embodiment of the present invention. The web proxy server 10' examines each file request from a requestor 2' to determine from the request itself that the requested file is pre-compressed (for example, by examining the file extension) (STEP 400). If the requested file is not pre-compressed (STEP 402), the web proxy server 10' continues normal processing (STEP 404).
If the requested file is pre-compressed (STEP 402), the file is retrieved in conventional fashion from the provider 4' (STEP 406). The file is then decompressed in the decompressor 24 (STEP 408) and recompressed in the recompressor 26 (STEP 410).
The recompressed file is then forwarded to the requestor 2' in conventional fashion (STEP
412).
As an optional step, the recompressed file may be cached in that form within the web proxy server 10' in a mass storage cache 22 (STEP 414).
FIGURE 5 is a flowchart showing the method of a second embodiment of the present invention. In this embodiment, rather than examining a file request from a requestor 2' to determine if a file is pre-compressed, as in the method shown in FIGURE 4, files are retrieved in conventional fashion and then examined within the web proxy server 10' (STEP 500). Whether a file is pre-compressed or not may be determined by examination of the file extension (for example, GIF or .TIF), or key bytes within a file header, or any other characteristic or attribute of the file that indicates compression.
If the requested file is not pre-compressed (STEP 502), the web proxy server 10' continues normal processing (STEP 504). If the requested file is pre-compressed (STEP
502), the file is then decompressed in the decompressor 24 (STEP 506) and recompressed in the recompressor 26 (STEP 508). The recompressed file is then forwarded to the to requestor 2' in conventional fashion (STEP 510).
As an optional step, the recompressed file may be cached in that form within the web proxy server 10' in a mass storage cache 22 (STEP 512).
In an alternative embodiment, rather than recompressing every compressed file or compressing every previously uncompressed file, additional testing may be done to decide whether the inventive process described above provides a time savings in transmission over simply retransmitting a requested file. For example, if a requested compressed file is small, the time required to decompress it and recompress it may exceed the time required to transfer it unchanged. In general, if TT is the estimated transfer time for a file, TD is the estimated decompression time (zero for an uncompressed file), and TR
is the estimated recompression time (initial compression time if the file is originally uncompressed), then the invention should only be used where TR + TD < TT.
Estimates for TT can be readily obtained by measuring the actual bit rate to a particular requestor, in known fashion. Estimates for TR and TD can be generated by first performing, in a preparation stage, a statistical analysis of actual decompression and recompression times versus file size for each compression type (e.g., GIF, TIFF, JPEG, etc.).
Thus, by knowing the size of a particular requested file, an estimate can be readily determined for TR and TD
by extrapolation. Alternatively, an estimate for TR and TD can be generated by decom-pressing a portion of a file and concurrently attempting to recompress that portion, timing each action, and extrapolating to the entire file size.
Referring to FIGURE 4, this type of testing can be done before STEP 408. If the test indicates that TR + TD is less than TT, then processing continues at STEP 408.
Otherwise, the requested file is directly forwarded to the requestor. Referring to FIGURE
FIGURE 1 is a diagram of a prior art wide area network system, such as the Internet.
FIGURE 2 is a diagram of the preferred hardware embodiment of the present invention.
FIGURE 3 is a block diagram showing the flow of selected data through the recompres-s sion server of FIGURE 2.
FIGURE 4 is a flowchart showing the method of a first embodiment of the present invention.
FIGURE 5 is a flowchart showing the method of a second embodiment of the present invention.
Like reference numbers and designations in the various drawings refer to like elements.
DETAILED DESCRIPTION OF THE INVENTION
Throughout this description, the preferred embodiment and examples shown should be considered as exemplars, rather than as limitations on the present invention.
FIGURE 2 is a diagram of the preferred hardware embodiment of the present invention.
The diagram shown in FIGURE 2 is similar to the diagram shown in FIGURE 1. A
requester 2' (for example, a web browser on the World Wide Web service provided by the Internet) can send file requests to a provider 4' (for example, a web server on the Internet) via a network 8. Each request is processed through a recompression server 20 in accordance with the present invention.
The recompression server 20 includes a web proxy server 10' having an optional cache 22. The recompression server 20 also includes a data path from the web proxy server 10' along a first connection 23 through a decompressor 24, along a second connection 25 through a recompressor 26, and along a third connection 27 back to the web proxy server 10'.
The components along the data path 23-27 can comprise hardware, a software or firmware programmed dedicated processor, or simply be software routines executed on the general processor(s) of the web proxy server 10', as a matter of design choice.
FIGURE 3 is a block diagram showing the flow of selected data through the recompres-sion server of FIGURE 2. When a file requested from a provider 4' passes through the recompression server 20, a determination is made in the web proxy server 10' whether the file is pre-compressed. If so, the compressed data 23 is routed along a first connection 23 to a decompressor 24. For example, if a requested data file is a graphics imaged compressed using the GIF standard, the file extension (.GIF) indicates that the file is pre-compressed. The file would be routed through the decompressor 24, which includes conventional decompression code for decompressing the GIF file. The decompressed data is routed along a second connection 25 (either directly or after temporary storage, such as in RAM or a mass storage device) to a recompressor 26.
The recompressor 26 re-compresses the decompressed data using any algorithm that provides a better compression ratio than the original compression. More than one recompression algorithm may be used if desired, to provide better compression for different data types. In the preferred embodiment, the algorithm used by the recompressor 26 for graphics files is a variable-loss (which includes no loss) compression algorithm called "GT", available from the former Johnson-Grace, Inc. of Newport Beach, California (now America Online, of Virginia). This algorithm can give file sizes from 15%
(for zero loss) to 70% smaller than the GIF standard, depending on desired degree of loss. Other algorithms, or combinations of algorithms, may be used, such as Huffman Coding, Lempel-Ziv '77, Lempel-Ziv '78, and Lempel-Ziv-Welch algorithms for lossless compression, and MPEG, JPEG, wavelet, and fractal algorithms for lossy compression.
After passing through the recompressor 26, the recompressed data passes along a third connection 27 back to the web proxy server 10' for transmission to the requester 2'.
As an optional step, the recompressed file may be cached in that form within the web proxy server 10' in a mass storage cache 22 (FIGURE 2), so that faster response can be provided to requestors 2' for frequently requested pre-compressed files. Any caching algorithm may be used, such as a conventional "least recently used" (LRU) algorithm, to manage the cache 22. Alternatively, the web proxy server 10' may maintain a log of file requests, and select files to be recompressed and cached based upon logged request frequencies. Caching may be done on-line, while recompressing files, or off-line, using logged request frequencies to retrieve "popular" files and recompress them during idle time for the web proxy server 10'.
WO 97/38434 - ~- PCT/US97/06005 As another option, the recompression server 20 may compress requested but previously uncompressed files. This aspect of the invention is advantageously used with the caching option, since frequently requested uncompressed files can be compressed and cached within the recompression server 20 so that network bandwidth is conserved each time such a file is requested thereafter.
The invention may be implemented as a computer program storable on a media that can be read by a computer system, such as a web proxy server 10', so as to configure the computer system to provide the functions described herein. Again, while the invention has been described as if executed on a separate processor, it may be implemented as a software process executed within the web proxy server 10.
FIGURE 4 is a flowchart showing the method of a first embodiment of the present invention. The web proxy server 10' examines each file request from a requestor 2' to determine from the request itself that the requested file is pre-compressed (for example, by examining the file extension) (STEP 400). If the requested file is not pre-compressed (STEP 402), the web proxy server 10' continues normal processing (STEP 404).
If the requested file is pre-compressed (STEP 402), the file is retrieved in conventional fashion from the provider 4' (STEP 406). The file is then decompressed in the decompressor 24 (STEP 408) and recompressed in the recompressor 26 (STEP 410).
The recompressed file is then forwarded to the requestor 2' in conventional fashion (STEP
412).
As an optional step, the recompressed file may be cached in that form within the web proxy server 10' in a mass storage cache 22 (STEP 414).
FIGURE 5 is a flowchart showing the method of a second embodiment of the present invention. In this embodiment, rather than examining a file request from a requestor 2' to determine if a file is pre-compressed, as in the method shown in FIGURE 4, files are retrieved in conventional fashion and then examined within the web proxy server 10' (STEP 500). Whether a file is pre-compressed or not may be determined by examination of the file extension (for example, GIF or .TIF), or key bytes within a file header, or any other characteristic or attribute of the file that indicates compression.
If the requested file is not pre-compressed (STEP 502), the web proxy server 10' continues normal processing (STEP 504). If the requested file is pre-compressed (STEP
502), the file is then decompressed in the decompressor 24 (STEP 506) and recompressed in the recompressor 26 (STEP 508). The recompressed file is then forwarded to the to requestor 2' in conventional fashion (STEP 510).
As an optional step, the recompressed file may be cached in that form within the web proxy server 10' in a mass storage cache 22 (STEP 512).
In an alternative embodiment, rather than recompressing every compressed file or compressing every previously uncompressed file, additional testing may be done to decide whether the inventive process described above provides a time savings in transmission over simply retransmitting a requested file. For example, if a requested compressed file is small, the time required to decompress it and recompress it may exceed the time required to transfer it unchanged. In general, if TT is the estimated transfer time for a file, TD is the estimated decompression time (zero for an uncompressed file), and TR
is the estimated recompression time (initial compression time if the file is originally uncompressed), then the invention should only be used where TR + TD < TT.
Estimates for TT can be readily obtained by measuring the actual bit rate to a particular requestor, in known fashion. Estimates for TR and TD can be generated by first performing, in a preparation stage, a statistical analysis of actual decompression and recompression times versus file size for each compression type (e.g., GIF, TIFF, JPEG, etc.).
Thus, by knowing the size of a particular requested file, an estimate can be readily determined for TR and TD
by extrapolation. Alternatively, an estimate for TR and TD can be generated by decom-pressing a portion of a file and concurrently attempting to recompress that portion, timing each action, and extrapolating to the entire file size.
Referring to FIGURE 4, this type of testing can be done before STEP 408. If the test indicates that TR + TD is less than TT, then processing continues at STEP 408.
Otherwise, the requested file is directly forwarded to the requestor. Referring to FIGURE
5, this type of testing can be done before STEP 506. If the test indicates that TR + Tp is less than TT, then processing continues at STEP 506. Otherwise, the requested file is directly forwarded to the requestor. In either method, the requested file may still be cached.
The invention may be implemented in hardware or software, or a combination of both.
However, preferably, the invention is implemented in computer programs executing on programmable computers each comprising a processor, a data storage system (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Program code is applied to input data to perform the functions described herein and generate output information. The output information is applied to one or more output devices, in known fashion.
Each program is preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.
Each such computer program is preferably stored on a storage media or device (e.g., ROM or magnetic diskette) readable by a general or special purpose programmable computer, for configuring and operating the computer when the storage media or device is read by the computer to perform the procedures described herein. The inventive system may also be considered to be implemented as a computer-readable storage medium, WO 97/38434 _ 1 O_ PCTIUS97/06005 configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner to perform the functions described herein.
A number of embodiments of the present invention have been described.
Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, although the invention has been described in the context of a wide area public network, it can be applied to any network (including private wide area and local area networks) in which files requested from one node by another node pass through an intermediate processor that can be programmed or configured as a recompression server. Accordingly, it is to be understood that the invention is not to be limited by the specific illustrated embodiment, but only by the scope of the appended claims.
The invention may be implemented in hardware or software, or a combination of both.
However, preferably, the invention is implemented in computer programs executing on programmable computers each comprising a processor, a data storage system (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Program code is applied to input data to perform the functions described herein and generate output information. The output information is applied to one or more output devices, in known fashion.
Each program is preferably implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language.
Each such computer program is preferably stored on a storage media or device (e.g., ROM or magnetic diskette) readable by a general or special purpose programmable computer, for configuring and operating the computer when the storage media or device is read by the computer to perform the procedures described herein. The inventive system may also be considered to be implemented as a computer-readable storage medium, WO 97/38434 _ 1 O_ PCTIUS97/06005 configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner to perform the functions described herein.
A number of embodiments of the present invention have been described.
Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, although the invention has been described in the context of a wide area public network, it can be applied to any network (including private wide area and local area networks) in which files requested from one node by another node pass through an intermediate processor that can be programmed or configured as a recompression server. Accordingly, it is to be understood that the invention is not to be limited by the specific illustrated embodiment, but only by the scope of the appended claims.
Claims (39)
PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:
1. A method for increasing available bandwidth in a network system, including the steps of:
(a) for each file requested from a provider node in the network system, determining whether the file is a pre-compressed file, each file including a plurality of bytes of data;
(b) automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire pre-compressed file into a distinct decompressed file;
(c) automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the distinct recompressed file having a greater degree of compression than the pre-compressed file; and (d) providing the entire recompressed file to the requester node.
(a) for each file requested from a provider node in the network system, determining whether the file is a pre-compressed file, each file including a plurality of bytes of data;
(b) automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire pre-compressed file into a distinct decompressed file;
(c) automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the distinct recompressed file having a greater degree of compression than the pre-compressed file; and (d) providing the entire recompressed file to the requester node.
2. The method of claim 1 wherein the step of determining whether a file is pre-compressed includes examining a file request from the requester node before retrieving the pre-compressed file.
3. The method of claim 1 wherein the step of determining whether a file is pre-compressed includes examining a retrieved file.
4. The method of claim 1, further including the step of caching the recompressed file.
5. The method of claim 1, further including the steps of:
a. before the step of decompressing, determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file; and b. if not, then continuing with the step of decompressing, and if so, then providing the pre-compressed file directly to the requester node.
a. before the step of decompressing, determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file; and b. if not, then continuing with the step of decompressing, and if so, then providing the pre-compressed file directly to the requester node.
6. A method for increasing available bandwidth in a network system, including the steps of:
(a) for each file requested from a provider node in the network system, determining whether the file is an uncompressed file, each file including a plurality of bytes of data;
(b) automatically compressing, independent of the compression capabilities of the provider node and a requester node in the network system, the entire uncompressed file into a distinct compressed file having a length shorter than the uncompressed file;
(c) providing the entire distinct compressed file to the requester node; and (d) caching the entire compressed file.
(a) for each file requested from a provider node in the network system, determining whether the file is an uncompressed file, each file including a plurality of bytes of data;
(b) automatically compressing, independent of the compression capabilities of the provider node and a requester node in the network system, the entire uncompressed file into a distinct compressed file having a length shorter than the uncompressed file;
(c) providing the entire distinct compressed file to the requester node; and (d) caching the entire compressed file.
7. The method of claim 6, further including the steps of:
a. before the step of compressing, determining whether an estimated time required to directly provide the uncompressed file to the requester node would be less than an estimated time to compress the uncompressed file; and b. if not, then continuing with the step of compressing, and if so, then providing the uncompressed file directly to the requester node.
a. before the step of compressing, determining whether an estimated time required to directly provide the uncompressed file to the requester node would be less than an estimated time to compress the uncompressed file; and b. if not, then continuing with the step of compressing, and if so, then providing the uncompressed file directly to the requester node.
8. A method for increasing available bandwidth in a network system, including the steps of:
(a) for each file requested from a provider node in the network system, examining a request for the file to determine if the requested file is pre-compressed, each file including a plurality of bytes of data;
(b) retrieving the requested file from the provider node in the network system;
(c) if the requested file is pre-compressed, automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire retrieved pre-compressed file into a distinct decompressed file;
(d) automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (e) providing the entire distinct recompressed file to the requester.
(a) for each file requested from a provider node in the network system, examining a request for the file to determine if the requested file is pre-compressed, each file including a plurality of bytes of data;
(b) retrieving the requested file from the provider node in the network system;
(c) if the requested file is pre-compressed, automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire retrieved pre-compressed file into a distinct decompressed file;
(d) automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (e) providing the entire distinct recompressed file to the requester.
9. The method of claim 8, further including the step of caching the recompressed file.
10. The method of claim 8, further including the steps of:
a. before the step of decompressing, determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file; and b. if not, then continuing with the step of decompressing, and if so, then providing the pre-compressed file directly to the requester node.
a. before the step of decompressing, determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file; and b. if not, then continuing with the step of decompressing, and if so, then providing the pre-compressed file directly to the requester node.
11. A method for increasing available bandwidth in a network system, including the steps of:
(a) for each file requested from a provider node in the network system, retrieving a file from the provider node, each file having a plurality of bytes of data;
(b) examining the retrieved file to determine if the file is pre-compressed;
(c) if the retrieved file is pre-compressed, automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire retrieved pre-compressed file into a distinct decompressed file;
(d) automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (e) providing the distinct recompressed file to the requester node.
(a) for each file requested from a provider node in the network system, retrieving a file from the provider node, each file having a plurality of bytes of data;
(b) examining the retrieved file to determine if the file is pre-compressed;
(c) if the retrieved file is pre-compressed, automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire retrieved pre-compressed file into a distinct decompressed file;
(d) automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (e) providing the distinct recompressed file to the requester node.
12. The method of claim 11, further including the step of caching the recompressed file.
13. The method of claim 11, further including the steps of:
a. before the step of decompressing, determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file;
b. if not, then continuing with the step of decompressing, and if so, then providing the pre-compressed file directly to the requester node.
a. before the step of decompressing, determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file;
b. if not, then continuing with the step of decompressing, and if so, then providing the pre-compressed file directly to the requester node.
14. An apparatus for increasing available bandwidth in a network system, including:
(a) means for determining whether each file requested from a provider node in the network system is a pre-compressed file, each file including a plurality of bytes of data;
(b) a decompressor for automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire pre-compressed file into a distinct decompressed file;
(c) a recompressor for automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (d) means for providing the distinct recompressed file to the requester node.
(a) means for determining whether each file requested from a provider node in the network system is a pre-compressed file, each file including a plurality of bytes of data;
(b) a decompressor for automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire pre-compressed file into a distinct decompressed file;
(c) a recompressor for automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (d) means for providing the distinct recompressed file to the requester node.
15. The apparatus of claim 14 wherein the means for determining whether a file is pre-compressed includes means for examining a file request from the requester node before retrieving the pre-compressed file.
16. The apparatus of claim 14 wherein the means for determining whether a file is pre-compressed includes means for examining a retrieved file.
17. The apparatus of claim 14, further including a cache for storing the recompressed file.
18. The apparatus of claim 14, further including a testing means for determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file, and if so, then providing the pre-compressed file directly to the requester node.
19. An apparatus for increasing available bandwidth in a network system, including:
(a) means for determining whether each file requested from a provider node in the network system is an uncompressed file, each file including a plurality of bytes of data;
(b) a compressor for automatically compressing, independent of the compression capabilities of the provider node and a requester node in the network system, the entire uncompressed file into a distinct compressed file having a length shorter than the uncompressed file;
(c) means for providing the distinct compressed file to the requester node;
and (d) a cache for storing the compressed file.
(a) means for determining whether each file requested from a provider node in the network system is an uncompressed file, each file including a plurality of bytes of data;
(b) a compressor for automatically compressing, independent of the compression capabilities of the provider node and a requester node in the network system, the entire uncompressed file into a distinct compressed file having a length shorter than the uncompressed file;
(c) means for providing the distinct compressed file to the requester node;
and (d) a cache for storing the compressed file.
20. The apparatus of claim 19, further including a testing means for determining whether an estimated time required to directly provide the uncompressed file to the requester node would be less than an estimated time to compress the uncompressed file, and if so, then providing the uncompressed file directly to the requester node.
21. An apparatus for increasing available bandwidth in a network system, including:
(a) for each file requested from a provider node in the network system, means for examining a request for the file to determine if the file is pre-compressed, each file including a plurality of bytes of data;
(b) means for retrieving the requested file from the provider node in the network system;
(c) a decompressor for automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, an entire retrieved pre-compressed file into a distinct decompressed file;
(d) a recompressor for automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (e) means for providing the distinct recompressed file to the requester node.
(a) for each file requested from a provider node in the network system, means for examining a request for the file to determine if the file is pre-compressed, each file including a plurality of bytes of data;
(b) means for retrieving the requested file from the provider node in the network system;
(c) a decompressor for automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, an entire retrieved pre-compressed file into a distinct decompressed file;
(d) a recompressor for automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (e) means for providing the distinct recompressed file to the requester node.
22. The apparatus of claim 21, further including a cache for storing the recompressed file.
23. The apparatus of claim 21, further including a testing means for determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file, and if so, then providing the pre-compressed file directly to the requester node.
24. An apparatus for increasing available bandwidth in a network system, including:
(a) for each file requested from a provider node in the network system, means for retrieving the file from the provider node, each file including a plurality of bytes of data;
(b) means for determining that the retrieved file is pre-compressed;
(c) a decompressor for automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, an entire retrieved pre-compressed file into a distinct decompressed file;
(d) a recompressor for automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (e) means for providing the distinct recompressed file to the requester node.
(a) for each file requested from a provider node in the network system, means for retrieving the file from the provider node, each file including a plurality of bytes of data;
(b) means for determining that the retrieved file is pre-compressed;
(c) a decompressor for automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, an entire retrieved pre-compressed file into a distinct decompressed file;
(d) a recompressor for automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (e) means for providing the distinct recompressed file to the requester node.
25. The apparatus of claim 24, further including a cache for storing the recompressed file.
26. The apparatus of claim 24, further including a testing means for determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file, and if so, then providing the pre-compressed file directly to the requester node.
27. A computer readable medium having operating codes embodied therein for increasing available bandwidth in a network system, the operating codes being tangibly stored on a media readable by a computer system, for configuring the computer system upon being read and executed by the computer system to perform the functions of:
(a) for each file requested from a provider node in the network system, determining whether the file is a pre-compressed file, each file including a plurality of bytes of data;
(b) automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire pre-compressed file into a distinct decompressed file;
(c) automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (d) providing the distinct recompressed file to the requester node.
(a) for each file requested from a provider node in the network system, determining whether the file is a pre-compressed file, each file including a plurality of bytes of data;
(b) automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire pre-compressed file into a distinct decompressed file;
(c) automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (d) providing the distinct recompressed file to the requester node.
28. The computer readable medium of claim 27 wherein the function of determining whether a file is pre-compressed includes examining a file request from the requester node before retrieving the pre-compressed file.
29. The computer readable medium of claim 27 wherein the function of determining whether a file is pre-compressed includes examining a retrieved file.
30. The computer readable medium of claim 27, further including the function of caching the recompressed file.
31. The computer readable medium of claim 27, further including the functions of:
a. before the function of decompressing, determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file; and b. if not, then continuing with the function of decompressing, and if so, then providing the pre-compressed file directly to the requester node.
a. before the function of decompressing, determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file; and b. if not, then continuing with the function of decompressing, and if so, then providing the pre-compressed file directly to the requester node.
32. A computer readable medium having operating codes embodied therein for increasing available bandwidth in a network system, the operating codes being tangibly stored on a media readable by a computer system, for configuring the computer system upon being read and executed by the computer system to perform the functions of:
(a) for each file requested from a provider node in the network system, determining whether the file is an uncompressed file each file including a plurality of bytes of data;
(b) automatically compressing, independent of the compression capabilities of the provider node and a requester node in the network system, the entire uncompressed file into a distinct compressed file having a length shorter than the uncompressed file;
(c) providing the entire distinct compressed file to the requester node; and (d) caching the compressed file.
(a) for each file requested from a provider node in the network system, determining whether the file is an uncompressed file each file including a plurality of bytes of data;
(b) automatically compressing, independent of the compression capabilities of the provider node and a requester node in the network system, the entire uncompressed file into a distinct compressed file having a length shorter than the uncompressed file;
(c) providing the entire distinct compressed file to the requester node; and (d) caching the compressed file.
33. The computer readable medium of claim 32, further including the functions of:
a. before the function of compressing, determining whether an estimated time required to directly provide the uncompressed file to the requester node would be less than an estimated time to compress the uncompressed file; and b. if not, then continuing with the function of compressing, and if so, then providing the uncompressed file directly to the requester node.
a. before the function of compressing, determining whether an estimated time required to directly provide the uncompressed file to the requester node would be less than an estimated time to compress the uncompressed file; and b. if not, then continuing with the function of compressing, and if so, then providing the uncompressed file directly to the requester node.
34. A computer readable medium having operating codes embodied therein for increasing available bandwidth in a network system, the operating codes being tangibly stored on a media readable by a computer system, for configuring the computer system upon being read and executed by the computer system to perform the functions of:
(a) for each file requested from a provider node in the network system, examining a request for the file to determine if the file is pre-compressed, each file including a plurality of bytes of data;
(b) retrieving the requested file from the provider node in the network system;
(c) if the requested file is pre-compressed, automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire retrieved pre-compressed file into a distinct decompressed file;
(d) automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (e) providing the distinct recompressed file to the requester node.
(a) for each file requested from a provider node in the network system, examining a request for the file to determine if the file is pre-compressed, each file including a plurality of bytes of data;
(b) retrieving the requested file from the provider node in the network system;
(c) if the requested file is pre-compressed, automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire retrieved pre-compressed file into a distinct decompressed file;
(d) automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (e) providing the distinct recompressed file to the requester node.
35. The computer readable medium of claim 34, further including the function of caching the recompressed file.
36. The computer readable medium of claim 34, further including the functions of:
a. before the function of decompressing, determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file; and b. if not, then continuing with the function of decompressing, and if so, then providing the pre-compressed file directly to the requester node.
a. before the function of decompressing, determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file; and b. if not, then continuing with the function of decompressing, and if so, then providing the pre-compressed file directly to the requester node.
37. A computer readable medium having operating codes embodied therein for increasing available bandwidth in a network system, the operating codes being tangibly stored on a media readable by a computer system, for configuring the computer system upon being read and executed by the computer system to perform the functions of:
(a) for each file requested from a provider node in the network system, retrieving a file from the provider node, each file including a plurality of bytes of data;
(b) examining the retrieved file to determine if the file is pre-compressed;
(c) if the retrieved file is pre-compressed, automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire retrieved pre-compressed file into a distinct decompressed file;
(d) automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (e) providing the distinct recompressed file to the requester node.
(a) for each file requested from a provider node in the network system, retrieving a file from the provider node, each file including a plurality of bytes of data;
(b) examining the retrieved file to determine if the file is pre-compressed;
(c) if the retrieved file is pre-compressed, automatically decompressing, independent of the decompression capabilities of the provider node and a requester node in the network system, the entire retrieved pre-compressed file into a distinct decompressed file;
(d) automatically recompressing, independent of the compression capabilities of the provider node and the requester node, the entire distinct decompressed file into a distinct recompressed file, the recompressed file having a greater degree of compression than the pre-compressed file; and (e) providing the distinct recompressed file to the requester node.
38. The computer readable medium of claim 37, further including the function of caching the recompressed file.
39. The computer readable medium of claim 37, further including the functions of:
a. before the function of decompressing, determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file; and b. if not, then continuing with the function of decompressing, and if so, then providing the pre-compressed file directly to the requester node.
a. before the function of decompressing, determining whether an estimated time required to directly provide the pre-compressed file to the requester node would be less than an estimated time to decompress the pre-compressed file and recompress the decompressed file; and b. if not, then continuing with the function of decompressing, and if so, then providing the pre-compressed file directly to the requester node.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA2591578A CA2591578C (en) | 1996-04-11 | 1997-04-11 | Recompression server |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/630,846 | 1996-04-11 | ||
US08/630,846 US6112250A (en) | 1996-04-11 | 1996-04-11 | Recompression of files at an intermediate node in a network system |
PCT/US1997/006005 WO1997038434A1 (en) | 1996-04-11 | 1997-04-11 | Recompression server |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA2591578A Division CA2591578C (en) | 1996-04-11 | 1997-04-11 | Recompression server |
Publications (2)
Publication Number | Publication Date |
---|---|
CA2252045A1 CA2252045A1 (en) | 1997-10-16 |
CA2252045C true CA2252045C (en) | 2007-07-03 |
Family
ID=38280075
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002252045A Expired - Lifetime CA2252045C (en) | 1996-04-11 | 1997-04-11 | Recompression server |
Country Status (1)
Country | Link |
---|---|
CA (1) | CA2252045C (en) |
-
1997
- 1997-04-11 CA CA002252045A patent/CA2252045C/en not_active Expired - Lifetime
Also Published As
Publication number | Publication date |
---|---|
CA2252045A1 (en) | 1997-10-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2731259C (en) | Recompression server | |
US8024484B2 (en) | Caching signatures | |
US6697844B1 (en) | Internet browsing using cache-based compaction | |
US7051126B1 (en) | Hardware accelerated compression | |
US6449658B1 (en) | Method and apparatus for accelerating data through communication networks | |
US20030023813A1 (en) | Multiple cache communication | |
US6304904B1 (en) | Method and apparatus for collecting page-level performance statistics from a network device | |
WO1997038434B1 (en) | Recompression server | |
US7069342B1 (en) | Communication system with content-based data compression | |
US8271689B2 (en) | System and method for partial data compression and data transfer | |
EP1535177B1 (en) | Method for caching and delivery of compressed content in a content delivery network | |
US7844740B2 (en) | System and method for dynamic compression of data | |
WO2001063485A2 (en) | Content distribution system | |
CA2435923A1 (en) | Compression system for low-bandwith client-server data link | |
WO2002013037A1 (en) | Method and system for accelerating the delivery of content in a networked environment | |
US7564861B1 (en) | Systems and methods for compressing data | |
US7640362B2 (en) | Adaptive compression in an edge router | |
WO2002010929A1 (en) | System and method for serving compressed content over a computer network | |
CA2252045C (en) | Recompression server | |
CA2591578C (en) | Recompression server | |
AU2004311797A1 (en) | Reusable compressed objects | |
Chi et al. | COMPRESSIONPROXYSERVE R: DESIGNANDIMPLEMENT AT ION | |
Liu et al. | HTTP compression techniques | |
WO2003001748A1 (en) | Method and apparatus for compression and decompression of data | |
WO2004036362A2 (en) | Compression of secure content |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
MKEX | Expiry |
Effective date: 20170411 |