UNITED STATES PATENT AND TRADEMARK OFFICE
`_______________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________
`
`NETAPP INC.,
`Petitioner
`
`v.
`
`REALTIME DATA LLC
`Patent Owner.
`
`Patent No. 7,415,530
`
`
`_______________
`
`
`
`Inter Partes Review No. IPR2017-01195
`____________________________________________________________
`
`DECLARATION OF DANIEL HIRSCHBERG
`
`
`
`
`
`
`
`
`
`NetApp Exhibit 1002 Page 1
`
`
`_______________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________
`
`NETAPP INC.,
`Petitioner
`
`v.
`
`REALTIME DATA LLC
`Patent Owner.
`
`Patent No. 7,415,530
`
`
`_______________
`
`
`
`Inter Partes Review No. IPR2017-01195
`____________________________________________________________
`
`DECLARATION OF DANIEL HIRSCHBERG
`
`
`
`
`
`
`
`
`
`NetApp Exhibit 1002 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. as a technical expert in
`
`connection with the proceeding identified above. I submit this declaration in
`
`support of NetApp’s Petition for Inter Partes Review of United States Patent No.
`
`7,415,530 (“the ’530 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. My resume is attached to this declaration as Exhibit A.
`
`4.
`
`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-1981.
`
`As a professor at UCI, I have taught courses in computer science topics, including
`
`a course covering compression techniques.
`
`
`
`2
`
`NetApp Exhibit 1002 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 ’530 patent;
`
`b) the prosecution history for the ’530 patent, including reexamination
`
`prosecution history;
`
`c) NetApp’s petition for inter partes review of the ’530 patent (the
`
`“Petition”) to which my declaration relates (I generally agree with the
`
`statements regarding the technical disclosures and characterizations of
`
`the ’530 patent and prior art contained in the Petition); and
`
`
`
`3
`
`NetApp Exhibit 1002 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).
`
`IV. Legal Standards
`
`A. Claim Construction
`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 further
`
`understand that the broadest reasonable construction is the broadest reasonable
`
`interpretation (BRI) of the claim language and that any term that lacks a definition
`
`in the specification is also given a broad interpretation. I have also been advised
`
`that, at the same time, claim terms are given their ordinary and accustomed
`
`meaning as would be understood by one of ordinary skill in the art. I have been
`
`informed that the construction of a patent term applied during this proceeding may
`
`differ from that in a district court proceeding.
`
`B. Obviousness
`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
`
`
`
`4
`
`NetApp Exhibit 1002 Page 4
`
`
`
`
`conceived the claimed invention, even if all of the limitations of the claim cannot
`
`be found in a single prior art reference.
`
`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
`
`
`
`5
`
`NetApp Exhibit 1002 Page 5
`
`
`
`
`combined or modified the elements or concepts from the prior art in the same way
`
`as in the claimed invention.
`
`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.
`
`
`
`6
`
`NetApp Exhibit 1002 Page 6
`
`
`
`
`V. The ’530 Patent
`
`A. Generally
`18. The ’530 patent, published August 19, 2008, is entitled “System and
`
`Methods for Accelerated Data Storage and Retrieval.” I understand that the ’530
`
`patent has a claimed priority date of March 11, 1999 because the ’530 patent states
`
`on its face that it is a continuation of U.S. Patent No 6,601,104, filed March 11,
`
`1999.
`
`19. The ’530 patent describes a compression/decompression system that is
`
`supposed to reduce the time required to store/retrieve or to increase the effective
`
`storage/retrieval rate under the assumption that the I/O data transmission rate
`
`exceeds the raw storage/retrieval rate. To store data, the ’530 patent describes
`
`using a collection of available encoders E_1 thru E_n. All (or a chosen subset of)
`
`encoders process an input block, either in parallel or sequentially. The best
`
`performing encoder (possibly subject to a processing time constraint) is chosen,
`
`unless its compression of this block does not meet a predetermined threshold, in
`
`which case NULL (no compression) is chosen. The encoded output and a
`
`descriptor of the chosen encoder are then output and stored.
`
`20. The retrieval process starts by receiving a compressed data block that
`
`contains compressed data and an encoder descriptor. The decoder associated with
`
`the described encoder is used to decompress the compressed data.
`
`
`
`7
`
`NetApp Exhibit 1002 Page 7
`
`
`
`
`21. The ’530 patent describes this system as a “data accelerator.” ’530 patent at
`
`5:6-6:37. The data accelerator is sometimes called a data storage accelerator or a
`
`data retrieval accelerator, but the basic concept is always the same. The data
`
`accelerator is supposed to compress data before storing the data so that time
`
`required to store and retrieve data from memory is reduced.
`
`22. Despite the ’530 patent’s characterization of a “data accelerator” as new, the
`
`“data accelerator” concept was well-known prior to the priority date of the ’530
`
`patent. For example, as I explain below, data modems in the 1990s widely
`
`implemented this concept to improve throughput while transmitting and receiving
`
`data. Various prior art references (including Osterlund, which is described in
`
`detail below) also show this concept was well-known prior to the priority date of
`
`the ’530 patent. As another example, see U.S. Patent No. 5,805,932
`
`(“Kawashima”) 3:8-46. Even the ’530 patent acknowledges that
`
`It is well known within the current art that data
`compression provides several unique benefits. First, data
`compression can reduce the time to transmit data by
`more efficiently utilizing low bandwidth data links.
`Second, data compression economizes on data storage
`and allows more information to be stored for a fixed
`memory size by representing information more
`efficiently. ’530 patent at 2:12-18.
`
`23. While not expressly disclosed as a new feature in the specification, claim 1
`
`of the ’530 patent also includes the idea that multiple compression algorithms are
`
`used. Claim 1 does not disclose why multiple compression algorithms should be
`8
`
`
`NetApp Exhibit 1002 Page 8
`
`
`
`
`used, but, regardless, this concept was also widely known before the priority date
`
`of the ’530 patent. For example, the PKZIP compression program (which I
`
`describe below) allowed for different compression techniques to be applied to
`
`different files that are to be compressed into one compressed file. As other
`
`examples, Sebastian, Wang, and Franaszek (which I describe in detail below) all
`
`use multiple compression techniques to improve compression efficiency.
`
`24. Accordingly, at most the ’530 patent is directed to a combination of concepts
`
`(using multiple compression technologies and using compression to increase
`
`storage and retrieval speed) that were well-known to a person of ordinary skill in
`
`the art as of the priority date of the ’530 patent. Combining these well-known
`
`concepts would have been well within the skill of a person of ordinary skill in the
`
`art using standard programming techniques to produced predictable results.
`
`B.
`State of the Art
`In general, well before March 1999, the concepts described and claimed in
`
`25.
`
`the ’530 patent were widely known and implemented in the computer industry.
`
`26. For example, the idea of compressing data to increase speed (e.g.,
`
`bandwidth) was widely known and implemented, such as in modem technology.
`
`The V.42bis modem protocol is one such example that was implemented in the
`
`early 1990s. (https://web-
`
`beta.archive.org/web/19981202062847/https://www.lsu.edu/OCS/its/unix/tutorial/
`
`
`
`9
`
`NetApp Exhibit 1002 Page 9
`
`
`
`
`ModemTutorial/MT-Compression.html (attached as Exhibit B.).) The V.42bis
`
`protocol allowed for compression of data before transferring the data. The
`
`compression was done on-the-fly so that a 50% reduction in the size of the
`
`transformed data would result in approximately 50% increase in throughput of the
`
`modem.
`
`27. As another example, in D.A. Lelewer and D.S. Hirschberg, “Data
`
`compression,” Computing Surveys 19:3 (1987) 261-297 (“Lelewer”) (Ex. 1011),
`
`my co-author and I explain that compression can speed the communication of
`
`information by effectively increasing the throughput of the communication
`
`channel.
`
`Compressing data to be stored or transmitted reduces
`storage and/or communication costs. When the amount of
`data to be transmitted is reduced, the effect is that of
`increasing the capacity of the communication channel.
`Similarly, compressing a file to half of its original size is
`equivalent to doubling the capacity of the storage
`medium. It may then become feasible to store the data at
`a higher, thus faster, level of the storage hierarchy and
`reduce the load on the input/output channels of the
`computer system. (Lelewer at 1-2.)
`
`28. The benefits of compression were also recognized in other areas besides
`
`communications. For example, archival systems (e.g., backup systems) commonly
`
`used compression to significantly increase the amount of data that could be stored
`
`in a particular system.
`
`
`
`10
`
`NetApp Exhibit 1002 Page 10
`
`
`
`
`
`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%).
`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. Similarly, the benefits of using different compression methods on different
`
`types of data blocks was also widely implemented long before the priority date of
`
`the ’530 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 C 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:
`
`local file header signature 4 bytes (0x04034b50)
`
`version needed to extract
`2 bytes
`11
`
`
`
`NetApp Exhibit 1002 Page 11
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`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)
`
`***
`compression method: (2 bytes)
`
`
`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. As another example, in U.S. Patent No. 5,374,916 (“Chu”), the data type of
`
`a data stream is identified and an optimal compression technique is selected based
`
`on the data type. The optimal compression technique is then applied to the data
`
`stream to produce the best compression ratio. Chu at Abst., FIG. 5, 5:14-6:31.
`
`
`
`12
`
` (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
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`NetApp Exhibit 1002 Page 12
`
`
`
`
`
`C.
`Person of Ordinary Skill in the Art
`32. A person of ordinary skill in the art for the ’530 patent in March 1999 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 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 claims 1-4, 12, and 18-20 are challenged in the Petition.
`
`35. Claim 1 is:
`
`A system comprising:
`
`a memory device; and
`
`a data accelerator, wherein said data accelerator is
`coupled to said memory device, a data stream is received
`by said data accelerator in received form, said data
`stream includes a first data block and a second data
`block, said data stream is compressed by said data
`accelerator to provide a compressed data stream by
`13
`
`
`
`NetApp Exhibit 1002 Page 13
`
`
`
`
`
`compressing said first data block with a first compression
`technique and said second data block with a second
`compression technique, said first and second
`compression techniques are different, said compressed
`data stream is stored on said memory device, said
`compression and storage occurs faster than said data
`stream is able to be stored on said memory device in said
`received form, a first data descriptor is stored on said
`memory device indicative of said first compression
`technique, and said first descriptor is utilized to
`decompress the portion of said compressed data stream
`associated with said first data block.
`
`36. Claim 2 is:
`
`The system of claim 1, wherein said data accelerator
`stores said first descriptor to said memory device.
`
`37. Claim 3 is
`
`The system of claim 1, wherein said data accelerator
`retrieves said first descriptor and said compressed data
`stream from said memory device.
`
`38. Claim 4 is
`
`The system of claim 1, wherein said data accelerator
`retrieves said compressed data stream from said memory
`device.
`
`39. Claim 12 is
`
`The system of claim 1, wherein said memory device is a
`solid-state mass storage device.
`
`40. Claim 18 is
`
`The system of claim 1, wherein said first compression
`technique comprises compressing with a first encoder.
`
`
`
`14
`
`NetApp Exhibit 1002 Page 14
`
`
`
`
`41. Claim 19 is
`
`The system of claim 1, wherein said data stream
`comprises a collection of multiple files.
`
`42. Claim 20 is
`
`The system of claim 1, wherein said data stream includes
`a third data block and a fourth data block.
`
`VII. Claim Construction
`43. My analysis below is based on the broadest reasonable interpretation of the
`
`claim terms consistent with the ordinary and accustomed meaning as would be
`
`understood by one of ordinary skill in the art.
`
`VII. Prior Art Analysis
`
`A. References
`
`1.
`U.S. Patent No. 5,870,036 (“Franaszek”) (Ex. 1006)
`44. Franaszek describes a data compression system that applies different data
`
`compression techniques to different data blocks depending on the data type of the
`
`data blocks. The system determines the “best” compression technique available by
`
`compressing a portion of the block and selecting the technique with the best
`
`compression ratio. This is a similar process used to select compression techniques
`
`in the ’530 patent. ’530 patent at 11:40-12:59.
`
`45. 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
`15
`
`
`NetApp Exhibit 1002 Page 15
`
`
`
`
`example, a block of plain text might be compressed with a LZ compression
`
`technique while a block of image data might be compressed with a run-length
`
`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.
`
`46. Franaszek’s decompression is the opposite sequence of the compression
`
`sequence. The CMD and compressed data block is retrieved. The CMD is used to
`
`determine the identity of the particular compressor (or NOOP) that was used to
`
`produce 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.
`
`47. 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.
`
`
`
`16
`
`NetApp Exhibit 1002 Page 16
`
`
`
`
`48. While the Franaszek does not expressly use the term “data accelerator,”
`
`Franaszek’s system includes all of the features that claim 1 attributes to the “data
`
`accelerator.” Specifically, claim 1 states that the “data accelerator” (1) is coupled
`
`to a memory device, (2) receives a data stream that includes a first data block and a
`
`second data block, (3) compresses the first and second data blocks with different
`
`compression techniques, (4) performs the compression such that storage and
`
`compression is faster than storing the data stream as received. Compressor 30 of
`
`Franaszek’s system, shown in FIG. 1 and also as compressor 220 in FIG. 2 (4:35-
`
`35), meets the above attributes of the data accelerator and is therefore a data
`
`accelerator in the context of the ’530 patent.
`
`
`
`
`
`17
`
`NetApp Exhibit 1002 Page 17
`
`
`
`
`
`
`
`49. With respect to (1), the compressor 30 is coupled to second memory 20 as
`
`shown in FIG. 1. The second memory could be any of “semiconductor memories,
`
`magnetic storage (such as a disk or tape), optical storage or any other suitable type
`
`of information storage media.”
`
`50. With respect to (2), the compressor 30 receives a data stream of multiple
`
`data blocks from first memory 10, as shown in FIG. 1. In FIG. 1, the received
`
`form of the data blocks is an uncompressed format. FIG. 2 also shows a stream of
`
`uncompressed data blocks received by the compressor that produces corresponding
`
`compressed data blocks. In FIG. 2, the uncompressed data blocks are similarly the
`
`“received form” (as recited in claim 1) of the data stream. FIG. 2 also shows that
`
`the data stream included at least four data blocks (i.e., a first data block, a second
`18
`
`
`NetApp Exhibit 1002 Page 18
`
`
`
`
`data block, a third data block, and a fourth data block as recited in claims 1 and
`
`20). There are two uncompressed data blocks 210 and two more compressed data
`
`blocks 230 that were previously received and already compressed. Additionally,
`
`the ellipses in the FIG. 2 indicate there are additional data blocks (both
`
`uncompressed and compressed) that are not explicitly depicted in FIG. 2. To the
`
`extent that it is argued that Franaszek does not expressly disclose a third and fourth
`
`block, it would have been obvious to a person of ordinary skill in the art for the
`
`data stream to include a third and fourth block. The presence of sufficiently more
`
`data in the data stream would result in additional data blocks in the data stream. In
`
`Franaszek, one example data block size is 4kB. Franaszek 7:6-9. Accordingly, for
`
`the data stream to have a third and fourth data block, the data stream would only
`
`have to be larger than 12kB. Data streams of hundreds of kilobytes were common
`
`(e.g., a stream of one or more program files, document files, and/or multimedia
`
`files) and a person of ordinary skill in the art would have found it obvious to apply
`
`Franaszek’s technique to these types of data streams.
`
`51. With respect to (3), the compressor 30 applies one of any number of
`
`different compression techniques to the uncompressed data blocks 15 received
`
`from first memory 10. The selected compression technique is the “best” technique
`
`that is available. The compressed data blocks 25 are then stored in second memory
`
`20. De-compressor 40, which may also be included in the data accelerator (but is
`
`
`
`19
`
`NetApp Exhibit 1002 Page 19
`
`
`
`
`not expressly required by the claim language of claim 1), performs the reverse
`
`function and decompresses compressed data blocks 25 in second memory 20. The
`
`decompressor uses the compression method identifier (described below) that is
`
`stored with the compressed data block in the second memory to choose the
`
`appropriate decompression method for the compressed data block. In other words,
`
`the “data accelerator” in Franaszek “retrieves said first descriptor and said
`
`compressed data stream from said memory device.”
`
`52. With respect to (4), while Franaszek does not expressly disclose that
`
`compression and storage is faster than storing the data stream as received, such a
`
`result would likely be inherently present in Franaszek’s compressor 30. As long as
`
`the compression is fast enough and the compression ratio is high enough,
`
`compression and storage (including the transmission of the compressed data to the
`
`memory device) of data will take less time than simply storing the uncompressed
`
`data because there will be fewer bytes to be stored. Generally, less data will
`
`always be stored in less time because the transmission time is related to the amount
`
`of data and the time that the memory device requires to process the data is also
`
`related to the amount of data. I note that the ’530 patent does not identify any new
`
`compression algorithms that are particularly useful to achieve the “faster than”
`
`result in claim 1. The ’530 patent also does not identify any implementation
`
`details or improvements to existing compression techniques for achieving the
`
`
`
`20
`
`NetApp Exhibit 1002 Page 20
`
`
`
`
`“faster than” result. The ’530 patent only states that well known or conventional
`
`compression techniques may be used to implement the data accelerator.
`
`It is to be understood that any conventional
`compression/decompression system and method (which
`comply with the above mentioned constraints) may be
`employed in the data storage accelerator 10 and data
`retrieval accelerator 80 for providing accelerated data
`storage and retrieval in accordance with the present
`invention. ’530 patent at 11:5-10.
`
`As stated above, the data storage accelerator 10 employs
`any of the data compression methods disclosed in the
`above-incorporated U.S. Ser. No. 09/210,491, or any
`conventional data compression method suitable for
`compressing data at a rate necessary for obtaining
`accelerated data storage. ’530 patent at 16:23-28.
`
`In accordance with Method 1, compression of data block
`1 and subsequent storage of the encoded data block 1
`occurs within time interval T1. Similarly, the
`compression and storage of each successive data block
`occurs within the time interval the data block is received.
`Specifically, data blocks 2 . . . n are compressed in time
`intervals T2 . . . Tn, respectively, and the corresponding
`encoded data blocks 2 . . . n are stored during the time
`intervals T2 . . . Tn, respectively. It is to be understood
`that Method 1 relies on data compression and encoding
`techniques that process data as a contiguous stream, i.e.,
`are not block oriented. It is well known within the current
`art that certain data compression techniques including,
`but not limited to, dictionary compression, run length
`encoding, null suppression and arithmetic compression
`are capable of encoding data when received. Method 1
`possesses the advantage of introducing a minimum delay
`in the time from receipt of input to storage of encoded
`data blocks. ’530 patent at 7:18-34.
`
`
`
`21
`
`NetApp Exhibit 1002 Page 21
`
`
`
`
`
`Data compression is performed by an encoder module 25
`which may comprise a set of encoders E1, E2, E3 . . . En.
`The encoder set E1, E2, E3 . . . En may include any
`number “n” (where n may=1) of those lossless encoding
`techniques currently well known within the art such as
`run length, Huffman, Lempel-Ziv Dictionary
`Compression, arithmetic coding, data compaction, and
`data null suppression. It is to be understood that the
`encoding techniques are selected based upon their ability
`to effectively encode different types of input data. It is to
`be appreciated that a full complement of encoders are
`preferably selected to provide a broad coverage of
`existing and future data types. ’530 patent at 14:16-27.
`
`53. Franaszek discloses many of these same compression techniques that the
`
`’530 patent describes as being capable of implementing the described data
`
`accelerator.
`
`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.
`
`54. A person of ordinary skill in the art would have understood Franaszek to
`
`teach that “a first data descriptor is stored on said memory device indicative of said
`
`
`
`22
`
`NetApp Exhibit 1002 Page 22
`
`
`
`
`first compression technique, and said first descriptor is utilized to decompress the
`
`portion of said compressed data stream associated with said first data block.”
`
`Each block of data includes a coding identifier which is
`indicative of the method or mechanism used to compress
`the block. The coding identifier is examined to select an
`appropriate one of the data decompression mechanisms
`to apply to the block. The block is then decompressed
`using the selected one of the mechanisms. Franaszek at
`3:42-45.
`
`The compressor outputs compressed data blocks 230,
`with an index (M) 232 identifying the selected
`compression method, and for dictionary-based methods,
`dictionary block identifier (D), encoded in a compression
`method description (CMD) area 235 in the compressed
`block. Franaszek at 4:55-59.
`
`55. The “CMD” area of FIG. 2 is stored with each compressed data block in the
`
`second memory of FIG. 1 and identifies the compression method used to compress
`
`the compressed data block. For example, CMD area 235 in FIG. 2, which is
`
`described at 4:55-59, includes the compression method for the compressed data
`
`block. The CMD area is used during decompression to identify the correct
`
`decompression technique to use for the compressed data block.
`
`Compressed data blocks 230, with the compressi
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
