UNITED STATES PATENT AND TRADEMARK OFFICE
`_______________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________
`
`NETAPP INC., RACKSPACE US INC.,
`Petitioners
`
`v.
`
`REALTIME DATA LLC
`Patent Owner.
`
`Patent No. 7,161,506
`
`_______________
`
`Inter Partes Review No. IPR2017-____
`____________________________________________________________
`
`DECLARATION OF DANIEL HIRSCHBERG
`
`(cid:3)
`
`NetApp; Rackspace Exhibit 1005 Page 1
`
`
`_______________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________
`
`NETAPP INC., RACKSPACE US INC.,
`Petitioners
`
`v.
`
`REALTIME DATA LLC
`Patent Owner.
`
`Patent No. 7,161,506
`
`_______________
`
`Inter Partes Review No. IPR2017-____
`____________________________________________________________
`
`DECLARATION OF DANIEL HIRSCHBERG
`
`(cid:3)
`
`NetApp; Rackspace Exhibit 1005 Page 1
`
`
`
`I, Daniel Hirschberg, make this declaration in connection with the
`
`proceeding identified above.
`
`I.
`
`1.
`
`Introduction
`
`I have been retained by counsel for NetApp Inc. and Rackspace US Inc. as a
`
`technical expert in connection with the proceeding identified above. I submit this
`
`declaration in support of NetApp’s and Rackspace’s Petition for Inter Partes
`
`Review of United States Patent No. 7,161,506 (“the ’506 patent”).
`
`2.
`
`I am being paid an hourly rate for my work on this matter. I do not have any
`
`personal or financial stake or interest in the outcome of the present proceeding.
`
`II. Qualifications
`
`3.
`
`4.
`
`My resume is attached to this declaration as Exhibit A.
`
`I earned my Ph.D. in Computer Science from Princeton University in 1975.
`
`I also earned a MSE and MA from Princeton University in 1973. I also earned a
`
`BE in Electrical Engineering from City College of New York in 1971.
`
`5.
`
`Since 2003, I have been a Professor of Computer Science and EECS at
`
`University of California, Irvine (UCI). Prior to that, I was a professor in various
`
`departments and held various other positions at UCI. I also held the position of
`
`Assistant Professor of Electrical Engineering at Rice University from 1975 through
`
`1981. As a professor at UCI, I have taught courses in computer science topics,
`
`including a course covering compression techniques.
`2
`
`dn-193685
`
`NetApp; Rackspace Exhibit 1005 Page 2
`
`
`
`6.
`
`In addition to my roles with UCI and Rice University, I have also provided
`
`various consulting services over the years. For example, I have consulted on the
`
`design of compression/decompression techniques. I have also provided technical
`
`expert services in intellectual property cases covering various technologies,
`
`including compression.
`
`7.
`
`I have also extensively published in the area of compression and participated
`
`in professional organizations and conferences focused on compression
`
`technologies. For example, publications nos. B2, J25, J29, J30, J35, J36, J43, J47,
`
`C15, C16, C19, C21, C22, and C31 all relate to lossless data compression.
`
`III. Materials Considered
`
`8.
`
`In preparing this declaration, I have reviewed, among other things, the
`
`following materials:
`
`a) the ’506 patent;
`
`b) the prosecution history for the ’506 patent, including reexamination
`
`prosecution history;
`
`c) NetApp’s and Rackspace’s petition for inter partes review of the ’506
`
`patent (the “Petition”) to which my declaration relates (I generally
`
`agree with the statements regarding the technical disclosures and
`
`characterizations of the ’506 patent and prior art contained in the
`
`Petition); and
`
`3
`
`dn-193685
`
`NetApp; Rackspace Exhibit 1005 Page 3
`
`
`
`d) the exhibits to the Petition (below, I use the names defined in the
`
`Petition’s exhibit list to refer to the exhibits) and any other documents
`
`cited below.
`
`IV. Legal Standards
`
`Claim Construction
`A.
`I have been informed that, when construing claim terms in an unexpired
`
`9.
`
`patent, a claim subject to post grant review receives the broadest reasonable
`
`construction in light of the specification of the patent in which it appears. I have
`
`also been informed that the ’506 patent is likely to expire during any IPR
`
`proceeding instituted based on the Petition. I understand that under this
`
`circumstance, the claims terms are construed according to their plain meaning in
`
`light of the intrinsic record.
`
`Obviousness
`B.
`I understand that a patent claim may also be invalid if the claimed invention
`
`10.
`
`would have been obvious to a person of ordinary skill in the art at the time of the
`
`claim’s effective filing date. I understand that an invention may be obvious if a
`
`person of ordinary skill in the art with knowledge of the prior art would have
`
`conceived the claimed invention, even if all of the limitations of the claim cannot
`
`be found in a single prior art reference.
`
`dn-193685
`
`4
`
`NetApp; Rackspace Exhibit 1005 Page 4
`
`
`
`11.
`
`I understand that, in assessing whether a claimed invention would have been
`
`obvious, the following factors are considered.
`
`12.
`
`First, I understand that the level of ordinary skill that a person working in the
`
`field of the claimed invention would have had at its effective filing date must be
`
`considered.
`
`13.
`
`Second, I understand that the scope and content of the prior art must be
`
`considered. I understand that, to be considered as prior art, a reference must be
`
`reasonably related to the claimed invention, which means that the reference is in
`
`the same field as the claimed invention or is from another field to which a person
`
`of ordinary skill in the art would refer to solve a known problem.
`
`14.
`
`Third, I understand that the differences, if any, that existed between the prior
`
`art and the claimed invention must be considered. I understand that the
`
`determination of such differences should focus on the claimed invention as a
`
`whole.
`
`15.
`
`I understand that it is not sufficient to prove a patent claim obvious to show
`
`that each of its limitations was independently known in the prior art but that there
`
`also must have been a reason for a person of ordinary skill in the art to have
`
`combined or modified the elements or concepts from the prior art in the same way
`
`as in the claimed invention.
`
`dn-193685
`
`5
`
`NetApp; Rackspace Exhibit 1005 Page 5
`
`
`
`16.
`
`In assessing whether such a reason existed, I understand that the following
`
`may be considered: (i) whether the combination or modification was merely the
`
`predictable result of using prior art elements according to their known functions;
`
`(ii) whether the claimed invention provided an obvious solution to a known
`
`problem in the art; (iii) whether the claimed invention applied a known technique
`
`that had been used to improve a similar device or method in a similar way; (iv)
`
`whether the prior art teaches or suggests making the combination or modification
`
`claimed in the patent; (v) whether the prior art teaches away from combining
`
`elements in the claimed invention; (vi) whether it would have been obvious to try
`
`the combination or modification, such as when there is a design need or market
`
`pressure to solve a problem and there are a finite number of identified, predictable
`
`solutions; and (vii) whether the combination or modification resulted from design
`
`incentives or other market forces.
`
`17.
`
`I understand that, when considering whether a claimed invention was
`
`obvious, one should be careful not to use the benefit of hindsight and that, instead,
`
`one should put oneself in the position of a person of ordinary skill in the art as of
`
`the effective filing date of the claimed invention and should not consider what is
`
`known today or what is learned from the teaching of the patent.
`
`dn-193685
`
`6
`
`NetApp; Rackspace Exhibit 1005 Page 6
`
`
`
`V.
`
`18.
`
`The ’506 Patent
`
`The ’506 patent, published January 9, 2007, is entitled “Systems and
`
`Methods for Data Compression Such as Content Dependent Data Compression.”
`
`Priority Date
`A.
`I understand that page 1 of the ’506 patent include a priority chain with an
`
`19.
`
`earliest date of December 11, 1998 (for U.S. Patent No. 6,195,024 (the “’024
`
`patent”)).
`
`20.
`
`I understand that for the ’506 patent to be entitled to a priority date of
`
`December 11, 1998, the specification of the application that issued as the ’024
`
`patent must have provided sufficient description of the claims of the ’506 patent
`
`such that a person of ordinary skill in the art would have understood that the named
`
`inventors were in possession of the claimed technology.
`
`21.
`
`I reviewed the application that issued as the ’024 patent. The application
`
`only describes content independent data compression. The ’506 patent’s claims
`
`include a determined of whether to apply content independent data compression or
`
`content dependent data compression. Accordingly, a person of ordinary skill in the
`
`art reviewing the application filed on December 11, 1998 that issued as the ’024
`
`patent would not have understood the named inventor to have been in possession
`
`of the technology claimed in the ’506 patent as of December 11, 1998.
`
`dn-193685
`
`7
`
`NetApp; Rackspace Exhibit 1005 Page 7
`
`
`
`22.
`
`The first time that the concept of content dependent data compression
`
`appears in any of the patent applications in the priority chain is October 29, 2001
`
`when the application that issued as U.S. Patent No. 6,624,761 was filed. In that
`
`application, FIGS. 13-18 and associated text were added, which are the portions of
`
`the ’506 patent that describe choosing between content dependent data
`
`compression and content independent data compression. Accordingly, this is the
`
`earliest possible priority date for the claims of the ’506 patent.
`
`Generally
`B.
`The ’506 patent discloses data compression “using a combination of content
`
`23.
`
`independent data compression and content dependent data compression.” ’506
`
`patent at Abstract. FIGS. 13A and 13B, reproduced below, depict an example of
`
`the ’506 patent’s system.
`
`dn-193685
`
`8
`
`NetApp; Rackspace Exhibit 1005 Page 8
`
`
`
`dn-193685
`
`9
`
`NetApp; Rackspace Exhibit 1005 Page 9
`
`
`
`24.
`
`The system described in the ’506 patent includes an input data buffer that
`
`buffers a data stream after passing through a data block counter that counts the
`
`sizes of data blocks in the data stream. ’506 patent at 16:8-28. The content
`
`dependent data recognition module “analyzes the incoming data stream to
`
`recognize data types, data structures, data block formats, file substructures, file
`
`types, and/or any other parameters that may be indicative of either the data
`
`type/content of a given data block or the appropriate data compression algorithm or
`
`algorithms (in serial or in parallel) to be applied.” ’506 patent at 16:29-35.
`
`25.
`
`For each data block, if the above analysis recognizes the data block, the data
`
`block is routed to a content dependent encoder module. ’506 patent at 16:38-40. If
`
`the analysis does not recognize the data block, the data block is sent to a content
`
`independent encoder module. ’506 patent at 16:40-42.
`
`26.
`
`In the content dependent encoder module, a data block is compressed using a
`
`subset of available encoders D1...Dm producing compressed data block versions
`
`(e.g., C1...Cm). ’506 patent at 16:43-57. The compression ratios (e.g., R1...Rm)
`
`are calculated for each of the compressed versions, where a ratio is the size of the
`
`uncompressed data block divided by the size of the compressed data block (i.e., a
`
`higher compression ratio indicates more compression). ’506 patent at 17:50-58.
`
`27.
`
`The compression encoder that produces the highest compression ratio is
`
`chosen. ’506 patent at 19:11-28. If that highest compression ratio is less than a
`10
`
`dn-193685
`
`NetApp; Rackspace Exhibit 1005 Page 10
`
`
`
`minimum predefined threshold, then the original uncompressed data block is
`
`output with an associated descriptor Null (meaning no compression used).
`
`’506 patent at 18:66-19:10. Otherwise, a compressed block with descriptor that
`
`identifies the compression technique that was used is output. ’506 patent at
`
`19:24-28.
`
`State of the Art
`B.
`In general, well before March 1999, the concepts described and claimed in
`
`28.
`
`the ’506 patent were widely known and implemented in the computer industry.
`
`For example, in D.A. Lelewer and D.S. Hirschberg, “Data compression,”
`
`Computing Surveys 19:3 (1987) 261-297 (“Lelewer”) (Ex. 1015), my co-author
`
`and I explain that the benefits of compression were recognized in many areas, such
`
`as communications and archival systems. It was also widely recognized that
`
`different types of compression techniques were more suitable for certain types of
`
`data.
`
`dn-193685
`
`Many of the methods discussed in this paper are
`implemented in production systems. The UNIX utilities
`compact and compress are based on methods discussed in
`Sections 4 and 5, respectively [UNIX 1984]. Popular file
`archival systems such as ARC and PKARC use
`techniques presented in Sections 3 and 5 [ARC 1986;
`PKARC 1987]. The savings achieved by data
`compression can be dramatic; reduction as high as 80% is
`not uncommon [Reghbati 1981]. Typical values of
`compression provided by compact are text (38%), Pascal
`source (43%), C source (36%), and binary (19%).
`11
`
`NetApp; Rackspace Exhibit 1005 Page 11
`
`
`
`Compress generally achieves better compression (50-
`60% for text such as source code and English) and takes
`less time to compute [UNIX 1984]. (Lelewer at 2.)
`
`29. Using different compression methods on different types of data blocks was
`
`also widely implemented long before the priority date of the ’506 patent. For
`
`example, the commonly used and widely distributed program PKZIP supported
`
`using different compression techniques for different files. The specification for the
`
`PKZIP file format (https://www.pkware.com/documents/APPNOTE/APPNOTE-
`
`1.0.txt (attached as Exhibit B to this declaration)) describes a “compression
`
`method” field in the header that describes the compression method used for that
`
`file. As noted in the APPNOTE file for version 1.0, this version was released in
`
`1990.
`
`Overall zipfile format:
`[local file header + file data + data_descriptor] . . .
`[central directory] end of central directory record
`A. Local file header:
`4 bytes (0x04034b50)
`local file header signature
`2 bytes
`version needed to extract
`2 bytes
`general purpose bit flag
`2 bytes
`compression method
`2 bytes
`last mod file time
`2 bytes
`last mod file date
`4 bytes
`crc-32
`4 bytes
`compressed size
`uncompressed size 4 bytes
`filename length 2 bytes
`extra field length
` 2 bytes
`filename
`(variable size)
`extra field
`(variable size)
`
`
`
`dn-193685
`
`12
`
`NetApp; Rackspace Exhibit 1005 Page 12
`
`
`
`***
`compression method: (2 bytes)
`
`(see accompanying documentation for algorithm
`descriptions)
`
`0 - The file is stored (no compression)
`1 - The file is Shrunk
`2 - The file is Reduced with compression factor 1
`3 - The file is Reduced with compression factor 2
`4 - The file is Reduced with compression factor 3
`5 - The file is Reduced with compression factor 4
`6 - The file is Imploded
`7 - Reserved for Tokenizing compression algorithm
`8 - The file is Deflated
`
`30.
`
`PKZIP had the ability to choose file-specific compression algorithms. This
`
`allowed for the appropriate algorithm to be applied to each file in a directory.
`
`31.
`
`The prior art described in more detail below provides more examples
`
`showing that the ’506 patent’s technology was well known as of the priority date
`
`of the ’506 patent.
`
`Person of Ordinary Skill in the Art
`C.
`32. A person of ordinary skill in the art for the ’506 patent in October 2001
`
`would have had an undergraduate degree in computer science, computer
`
`engineering, electrical and computer engineering, or equivalent field and one to
`
`three years of experience working with data compression or a graduate degree with
`
`course work or research in the field of data compression. A person without the
`
`undergraduate or graduate degree described above would still qualify as a person
`13
`
`dn-193685
`
`NetApp; Rackspace Exhibit 1005 Page 13
`
`
`
`of ordinary skill in the art if they had additional education or industry experience
`
`that compensated for the deficiency in the requirement above.
`
`33.
`
`I am familiar with the capabilities and skills of a person of ordinary skill in
`
`the art. For example, I have supervised and taught graduate students who would
`
`qualify as persons of ordinary skill in the art.
`
`VI. CHALLENGED CLAIMS
`34.
`I understand that claim 105 is challenged in the Petition.
`
`35. Claim 105 is:
`
`A computer implemented method comprising:
`
`receiving a data block in an uncompressed form,
`said data block being included in a data stream;
`
`analyzing data within the data block to determine a
`type of said data block; and
`
`compressing said data block to provide a
`compressed data block,
`
`wherein if one or more encoders are associated to
`said type, compressing said data block with at least one
`of said one or more encoders,
`
`otherwise compressing said data block with a
`default data compression encoder, and
`
`wherein the analyzing of the data within the data
`block to identify one or more data types excludes
`analyzing based only on a descriptor that is indicative of
`the data type of the data within the data block.
`
`dn-193685
`
`14
`
`NetApp; Rackspace Exhibit 1005 Page 14
`
`
`
`VII. Claim Construction
`36. My analysis below is based on meanings of the claim terms according to
`
`their plain meaning in light of the intrinsic record. The claim constructions in the
`
`Petition are consistent with the plain meaning in light of the intrinsic record.
`
`VII. Prior Art Analysis
`
`A.
`
`References
`
`1.
`
`“Automatic Synthesis of Compression Techniques for
`Heterogeneous Files,” by Hsu and Zwarico (“Hsu”) (Ex.
`1002)
`37. Hsu presents a technique to compress a data file by applying the “most
`
`appropriate” compression algorithm from a suite of available algorithms to each
`
`block of the file. Hsu’s technique works in two phases.
`
`38.
`
`In the first phase, the system first determines for each block its type (one of
`
`ten) and its compressibility via what Hsu calls “redundancy metrics.” If the data
`
`block has an appropriate combination (i.e., one that has an assigned compression
`
`algorithm) of data classification (also called a data type in Hsu) and largest
`
`redundancy metric, then the assigned compression algorithm is tagged for the data
`
`block by associating the data block with the assigned compression algorithm in a
`
`compression plan. Hsu at 1109. On the other hand, if an appropriate combination
`
`of data classification and largest redundancy metric is not identified (and no other
`
`dn-193685
`
`15
`
`NetApp; Rackspace Exhibit 1005 Page 15
`
`
`
`redundancy metric that would produce an appropriate combination is above a
`
`metric threshold), the data block is tagged with “no compression.” Hsu at 1106.
`
`39.
`
`The block type is determined by an extension of the Unix “file” command
`
`that examines the first, middle, and last 512 bytes of the block and compares the
`
`pattern of data to a collection of known data patterns. There are ten data
`
`classifications (sometimes also referred to as “data types” in Hsu) in Hsu’s
`
`database depicted in Table I and reproduced below with annotations to show the
`
`different rows that represent each data classification. The entries in Table I are
`
`chosen to provide for better compression for each combination of data
`
`classification and redundancy metric.
`
`dn-193685
`
`16
`
`NetApp; Rackspace Exhibit 1005 Page 16
`
`
`
`40. A person of ordinary skill in the art would have recognized nine of these
`
`data classifications (i.e., ANSI, hexadecimal, natural language, source code, audio,
`
`low resolution graphic, high resolution graphic, high redundancy binary
`
`executable, and object) are data classifications that have recognizable, specific
`
`structures. See Hsu at 1103-04 for a description of the data classifications. On the
`
`other hand, low redundancy binary does not have a specific structure. A person of
`
`ordinary skill in the art would have recognized that Hsu’s low redundancy binary
`
`data is a default data classification that is used when none of the other nine data
`
`classifications are identified using the “new-file” program.
`
`dn-193685
`
`17
`
`NetApp; Rackspace Exhibit 1005 Page 17
`
`
`
`41.
`
`This understanding of how the “new-file” program works is consistent with
`
`how the “file” program worked before the priority date of the ’506 patent.
`
`Specifically, according to the manual page for the “file” program at that time,
`
`“file” would output the type “data” to mean “anything else” that could not be
`
`matched to another data type. See Manual Page for “file” Command (attached as
`
`Exhibit C this declaration).
`
`The first test that succeeds causes the file type to be
`printed.
`
`The type printed will usually contain one of the words
`text (the file contains only ASCII characters and is
`probably safe to read on an ASCII terminal), executable
`(the file contains the result of compiling a program in a
`form understandable to some UNIX kernel or another), or
`data meaning anything else (data is usually ‘binary’ or
`nonprintable).
`
`(Bold and italics in original.) A person of ordinary skill in the art would have
`
`understood the “low redundancy binary” data classification in Hsu to be the
`
`equivalent of the “data” type in the unaltered version of “file.” It represents any
`
`other binary data classification that did not match one of the other nine well-
`
`recognized data classifications.
`
`42. Returning to the operation of Hsu’s first phase, the compressibility of the
`
`data block is determined by the values of three redundancy metrics representing
`
`the degree of variation in character frequency (“MAD”), average run length
`18
`
`dn-193685
`
`NetApp; Rackspace Exhibit 1005 Page 18
`
`
`
`(“MRL”), and string repetition ratio (“MSR”) in the block. Each redundancy metric
`
`is calculated by a separate statistical sampling routine and normalized using a
`
`gamma distribution function to be a number between 0 and 10. If the metrics are
`
`all below a threshold then the block is not compressed in order to save the
`
`overhead of attempting to compress the data block when the redundancy metric
`
`indicates low potential for significant compression. Otherwise, using the block
`
`type and largest metric, the assigned compression algorithm is chosen from the
`
`compression algorithm database. The data block is then tagged with the assigned
`
`compression algorithm in a compression plan. If the block classification and
`
`largest metric are not an appropriate combination in the database and none of the
`
`other redundancy metrics are above a metric threshold, then the data block is
`
`tagged for no compression in the compression plan in order to save on the
`
`overhead of trying to compress the data block when the data block produced an
`
`unexpected combination of data classification and largest redundancy metric.
`
`43.
`
`In the second phase, Hsu’s system compresses the data block according to
`
`the compression plan. Prior to applying the chosen compression algorithm,
`
`adjacent blocks are merged if they are to be compressed with the same algorithm.
`
`(Hsu at 1109.) After a data block or merged group of data blocks is compressed
`
`with the identified compression algorithm, the compressed data block is checked
`
`for negative compression (e.g., making sure that the compression ratio is greater
`19
`
`dn-193685
`
`NetApp; Rackspace Exhibit 1005 Page 19
`
`
`
`than 1). (Hsu at 1109.) If negative compression is detected, the uncompressed
`
`data block is used and “no compression” is recorded in the compression history.
`
`(Hsu at 1109.) Otherwise, the compressed data block is used and the appropriate
`
`compression algorithm is recorded in the compression history. Once all of the data
`
`blocks are processed, the compression history is prepended to the resulting data
`
`blocks to produce the output file that can be stored.
`
`U.S. Patent No. 6,253,264 (“Sebastian”) (Ex. 1012)
`2.
`Sebastian discloses compressing different types of data sources with
`
`44.
`
`different compression encoders (called “filters” in Sebastian) to produce a “format-
`
`specific compression” system. When the type of a data source is not supported and
`
`an associated encoder cannot be identified, a “generic” compression encoder is
`
`used.
`
`dn-193685
`
`At the highest level, a preferred compression system in
`accordance with the invention uses an architecture called
`a Base-Filter-Resource (BFR) system. This approach
`integrates the advantages of format-specific compression
`into a general-purpose compression tool serving a wide
`range of data formats. The system includes filters which
`each support a specific data format, such as for Excel
`XLS worksheets or Word DOC files. The base includes
`the system control modules and a library used by all the
`filters. The resources include routines which are used by
`more than one filter, but which are not part of the base. If
`a filter is installed which matches the format of the data
`to be encoded, the advantages of format-specific
`compression can be realized for that data. Otherwise, a
`“generic” filter is used which achieves performance
`20
`
`NetApp; Rackspace Exhibit 1005 Page 20
`
`
`
`similar to other non-specific data compression systems
`(such as PKZip, Stacker, etc.). (Sebastian at 1:36-60
`(emphasis added).)
`
`FIG. 2 is a block diagram of a preferred encoder using a
`Base-Filter-Resource (BFR) network in accordance with
`the invention. The encoder 3` is based on the use of a
`plurality of filters 10a, . . . , 10x, . . . , 10z which serve
`specific file formats. For example, one filter 10a might
`support several versions of the DBF database format,
`while another filter 10z might support several versions of
`the DOC format used by the Microsoft Word software
`program. The individual filters provide respective
`selection criteria 12 to a filter selection system 22.
`
`The filter selection system 22 receives the source data 2
`and checks the selection criteria 12a, . . . , 12x, . . . , 12z
`of all filters 10a, . . . , 10x, . . . , 10z installed in the
`system to see if any of them support the source data’s
`format. If not, a “generic” filter is used which provides
`compression performance similar to other generic
`compression systems, such as Lempel-Ziv (LZ) engines.
`In a particular preferred embodiment of the invention, the
`generic compression system employs an SZIP engine as
`described by Mr. Schindler in U.S. application Ser. No.
`08/970,220 filed Nov. 14, 1997, the teachings of which
`are incorporated herein by reference in their entirety. The
`descriptions of the network will primarily cover the
`situations in which a filter to support the data format is
`successfully found. (Sebastian at 3:66-4:22 (emphasis
`added).)
`
`U.S. Patent No. 5,870,036 (“Franaszek”) (Ex. 1003)
`3.
`Franaszek describes a data compression system that applies different data
`
`45.
`
`compression techniques to different data blocks depending on the data type of the
`
`data blocks. In Franaszek’s system, a data block to be compressed is checked to
`
`dn-193685
`
`21
`
`NetApp; Rackspace Exhibit 1005 Page 21
`
`
`
`determine whether a “data type” field identifies the data type of the data block. If
`
`the “data type” field identifies a data type, a list of compression methods
`
`corresponding to the data type (that was identified by the contents of the “data
`
`type” field) is assigned to the data block. Franaszek at Fig. 2, 4:25-35, 5:49-54,
`
`6:1-11. If the “data type” field does not identify the data type, a list of default
`
`compression methods is assigned to the data block. In other words, Franaszek
`
`teaches automatically applying a predefined default encoder from the list of
`
`compression methods to the data block when a data type specific encoder is not
`
`identified from the data type. Nothing in Franaszek describes how the “data type”
`
`information for the “data type” field is determined or where it came from.
`
`46.
`
`The system determines the “best” compression technique available by
`
`compressing a portion of the block with each of the list of compression methods
`
`and selecting the technique that results in the best compression ratio. This is
`
`similar to a process used to select compression techniques in the ’506 patent.
`
`’506 patent at 4:9-24.
`
`47. Nothing in Franaszek limits how many compression methods are present in
`
`the lists of compression methods (i.e., the lists of compression methods associated
`
`with specific data types or the list of default compression methods).
`
`In step 401, if a data type (e.g. text, image, etc.) for a
`given uncompressed block B is available, in step 404 the
`Compression Method List (CML) is set to a list of
`22
`
`dn-193685
`
`NetApp; Rackspace Exhibit 1005 Page 22
`
`
`
`compression methods that have been preselected for that
`data type. Otherwise, if no data type is available, in step
`407 the CML is set to a default list of compression
`methods. (Franaszek at 5:49-54.)
`
`In step 414, it is determined if a data type is available (i.e
`the block includes a “data type” entry in the type field
`205), If a data type is available, in steps 417, 421, 424,
`and 427, the CML is expanded by replacing E with the
`list (M,D1), (M,D2), . . . , (M,Dj), where (D1, . . . , Dj) is
`a list of dictionary block identifiers that have been
`preselected for the data type when using compression
`method M. Otherwise, if no data type is available), steps
`419, 421, 424, and 427, replace E with the list (M,D1'),
`(M,D2'), . . . , (M,Dk'), where (D1', . . . , Dk') is a default
`list of dictionary block identifiers for compression
`method M. (Franaszek at 6:1-11.)
`
`Accordingly, a person of ordinary skill in the art would understand Franaszek’s
`
`lists to contain any number of compression methods (i.e., one or more compression
`
`methods). This is similar to the disclosure in the ’506 patent that describes
`
`encoding a data block using “a set of encoders D1, D2, D3 . . . Dm . . . [that] may
`
`include any number ‘n’ of those lossless or lossy encoding techniques currently
`
`well known with the art.” ’506 patent at 16:45-48.
`
`48.
`
`Franaszek’s compression works by using a sample from a block that is to be
`
`compressed. Each of a set of compressors is applied to the sample and the
`
`compressor that results in the best compression of the sample is selected. For
`
`example, a block of plain text might be compressed with an LZ compression
`
`technique while a block of image data might be compressed with a run-length
`
`dn-193685
`
`23
`
`NetApp; Rackspace Exhibit 1005 Page 23
`
`
`
`compression technique. If, however, the best compression is not sufficient, then a
`
`NOOP (i.e., no compressor) may be used for the block. If a “best” compressor is
`
`identified, then that compressor is applied to the data block to produce a
`
`compressed data block (i.e., a block with fewer bytes than the original data block)
`
`that can be stored in memory. A compression method description (CMD) stored
`
`with the compressed data block identifies the compressor used for a particular data
`
`block.
`
`49.
`
`Franaszek’s decompression sequence is the opposite sequence of the
`
`compression sequence. The compressed data block, which includes the CMD and
`
`compressed data, is retrieved. The CMD is used to determine the identity of the
`
`particular compressor (or NOOP) that was used to produce compressed data in the
`
`compressed data block. This information will enable the system to identify the
`
`decompressor (or NOOP) that should be used to decompress the data. The
`
`identified decompressor is then used to generate the uncompressed data.
`
`50.
`
`The Franaszek system stores and retrieves the compressed data blocks on a
`
`memory device. For example, Franaszek discloses memory devices such as
`
`“semiconductor memories, magnetic storage (such as a disk or tape), optical
`
`storage or any other suitable type of information storage media.” Franaszek at
`
`4:10-12.
`
`dn-193685
`
`24
`
`NetApp; Rackspace Exhibit 1005 Page 24
`
`
`
`51.
`
`Franaszek discloses many of these same compression techniques that the
`
`’506 patent describes as default compression encoders and compression encoders
`
`associated with data types.
`
`For simplicity, assume that all uncompressed data blocks
`are a given fixed size, say 4096 bytes. Each such block
`can be considered to consist of 8 512-byte sub-blocks, for
`example. In some cases it may happen that using the first
`such sub-block as a dictionary may yield better
`compression than any of the fixed static dictionaries. This
`method is shown as 602 in the compression method table
`240. Alternatively, take the first 64 bytes of each sub-
`block, and concatenating these into a 512-byte dictionary,
`could be the best dictionary for some blocks having
`certain phrase patterns. This method is indicated by 603
`in the figure. The other three methods indicated in the
`figure are arithmetic coding 600, run-length coding 601,
`and LZ1 using one of the fixed set of static dictionaries
`602. (Franaszek at 7:6-19.)
`
`52.
`
`Franaszek outputs a descriptor that indicates the compression method that
`
`was used to compress a particular block of data.
`
`Each block of data includes a coding identifier which is
`indicative of the method
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
