Trials@uspto.gov
`571-272-7822
`
`
`
`
`
`
`
`
`Paper No. 62
`Filed: September 28, 2017
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`HEWLETT-PACKARD ENTERPRISE CO.; HP ENTERPRISE
`SERVICES, LLC; and TERADATA OPERATIONS, INC.,
`Petitioner,
`
`v.
`
`REALTIME DATA LLC d/b/a IXO,
`Patent Owner.
`____________
`
`Case IPR2016-00783
`Patent 6,597,812 B1
`____________
`
`
`Before GEORGIANNA W. BRADEN, JASON J. CHUNG, and
`SCOTT C. MOORE, Administrative Patent Judges.
`
`CHUNG, Administrative Patent Judge.
`
`
`FINAL WRITTEN DECISION
`Inter Partes Review
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`571-272-7822
`
`
`
`
`
`
`
`
`Paper No. 62
`Filed: September 28, 2017
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`HEWLETT-PACKARD ENTERPRISE CO.; HP ENTERPRISE
`SERVICES, LLC; and TERADATA OPERATIONS, INC.,
`Petitioner,
`
`v.
`
`REALTIME DATA LLC d/b/a IXO,
`Patent Owner.
`____________
`
`Case IPR2016-00783
`Patent 6,597,812 B1
`____________
`
`
`Before GEORGIANNA W. BRADEN, JASON J. CHUNG, and
`SCOTT C. MOORE, Administrative Patent Judges.
`
`CHUNG, Administrative Patent Judge.
`
`
`FINAL WRITTEN DECISION
`Inter Partes Review
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`
`I.
`
`INTRODUCTION
`
`Hewlett-Packard Enterprise Company, HP Enterprise Services, LLC,
`and Teradata Operations, Inc. (collectively, “Petitioner”), filed a Petition to
`institute an inter partes review of claims 1–4, 8, 14–17, 21, and 28 of U.S.
`Patent No. 6,597,812 B1 (“the ’812 patent”). Paper 1 (“Pet.”). Realtime
`Data LLC (“Patent Owner”), filed a Preliminary Response pursuant to
`35 U.S.C. § 313. Paper 12 (“Prelim. Resp.”).
`Upon consideration of the Petition and the Preliminary Response, on
`October 5, 2016, we instituted inter partes review of claims 1–4, 8, 14–17,
`21, and 28 (“instituted claims”), pursuant to 35 U.S.C. § 314. Paper 19
`(“Dec.”).
`Subsequent to institution, Patent Owner filed a Patent Owner
`Response. Paper 29 (“PO Resp.”). Petitioner filed a Reply to Patent
`Owner’s Response. Paper 37 (“Reply”). An oral hearing was held on June
`30, 2017 and a transcript of the oral hearing is available in the record. Paper
`59 (“Tr.”).
`We issue this Final Written Decision pursuant to 35 U.S.C. § 318(a)
`and 37 C.F.R. § 42.73. For the reasons discussed herein, Petitioner has
`shown by a preponderance of the evidence that claims 1–4, 8, 14–17, 21, and
`28 of the ’812 patent are unpatentable. See 35 U.S.C. § 316(e).
`
`Related Matters
`
`A.
`Petitioner and Patent Owner inform us that the ’812 patent is involved
`in multiple suits in the U.S. District Court for the Eastern District of Texas.
`Pet. 1; Paper 9, 1–2; Paper 10, 2–3; Paper 58, 4–5. Patent Owner also
`informs us that the ’812 patent is involved in a suit in the U.S. District Court
`
`2
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`for the Northern District of California. Paper 9, 2; Paper 10, 2–3; Paper 58,
`4–5.
`
`The Instituted Grounds
`
`B.
`We instituted the following grounds of unpatentability:
`References1
`Basis
`Instituted Claims
`O’Brien2 and Nelson3
`§ 103(a)4 1–4, 8, and 28
`O’Brien, Nelson, and Welch5 § 103(a) 14–17 and 21
`
`The ’812 Patent
`
`C.
`The ’812 patent describes systems and methods “for providing
`lossless data compression and decompression.” Ex. 1001, Abs. The ’812
`patent further describes “characteristics of run-length encoding, parametric
`dictionary encoding, and bit packing to comprise an encoding/decoding
`process.” Id. Figure 1 of the ’812 patent is reproduced below.
`
`
`1 Petitioner also relies upon the Declarations of Dr. Charles D. Creusere.
`Ex. 1005
`2 U.S. Patent No. 4,929,946; issued May 29, 1990, (Ex. 1002, “O’Brien”)
`3 MARK NELSON, THE DATA COMPRESSION BOOK (1992), (Ex. 1003,
`“Nelson”)
`4 The Leahy-Smith America Invents Act (“AIA”), Pub. L. No. 112-29,
`125 Stat. 284, 287–88 (2011), revised 35 U.S.C. § 103, effective March 16,
`2013. The ’812 patent was issued prior to the effective date of the AIA.
`Thus, we apply the pre-AIA version of § 103.
`5 U.S. Patent No. 4,558,302; issued Dec. 10, 1985, (Ex. 1004, “Welch”)
`
`3
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`
`
`
`Figure 1 of the ’812 patent, reproduced above, is a detailed block
`diagram of a system for combining run-length encoding with dictionary
`encoding. Ex. 1001, 5:14–23. Input buffer 11 temporarily buffers an input
`data stream, and encoder 12 compresses the input data stream. Id. at 4:66–
`5:2. Encoder 12 implements a combination of run-length encoder 13 and
`dictionary encoder 14. Id. at 5:14–22. More specifically, encoder 12
`identifies any run-length sequence in the data stream and outputs one or
`more code words from dictionary 15 to represent the run-length sequence.
`Id. at 5:31–37. Dictionary encoder 14 builds a character string comprising
`two or more characters that does not comprise a run-length sequence,
`searches dictionary 15 for a code word corresponding to the character string,
`and then outputs the code word representing the character string. Id. at
`5:38–42.
`
`4
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`
`The Instituted Claims
`
`D.
`We instituted inter partes review of claims 1–4, 8, 14–17, 21, and 28.
`Claim 1 is illustrative and reproduced below:
`1. A method for compressing input data comprising a plurality
`of data blocks, the method comprising the steps of:
`detecting if the input data comprises a run-length sequence of
`data blocks;
`outputting an encoded run-length sequence, if a run-length
`sequence of data blocks is detected;
`maintaining a dictionary comprising a plurality of code words,
`wherein each code word in the dictionary is associated with a
`unique data block string;
`building a data block string from at least one data block in the
`input data that is not part of a run-length sequence;
`searching for a code word in the dictionary having a unique data
`block string associated therewith that matches the built data
`block string; and
`outputting the code word representing the built data block string.
`Ex. 1001, 16:53–17:2.
`
`II. ANALYSIS
`Principles of Law
`A.
`A claim is unpatentable under 35 U.S.C. § 103(a) if “the differences
`between the subject matter sought to be patented and the prior art are such
`that the subject matter as a whole would have been obvious at the time the
`invention was made to a person having ordinary skill in the art to which said
`subject matter pertains.” KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406
`(2007). The question of obviousness is resolved on the basis of underlying
`factual determinations, including: (1) the scope and content of the prior art;
`
`5
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`(2) any differences between the claimed subject matter and the prior art;
`(3) the level of skill in the art; and (4) objective evidence of nonobviousness,
`i.e., secondary considerations. See Graham v. John Deere Co. of Kansas
`City, 383 U.S. 1, 17–18 (1966).
`A determination of whether a patent claim is invalid as obvious under
`§ 103 requires consideration of all four Graham factors, and it is error to
`reach a conclusion of obviousness until all those factors are considered.”
`Apple v. Samsung Elecs. Co., Ltd., 839 F.3d 1034, 1048 (Fed. Cir. 2016) (en
`banc) (citations omitted). “This requirement is in recognition of the fact that
`each of the Graham factors helps inform the ultimate obviousness
`determination.” Id.
`“In an [inter partes review], the petitioner has the burden from the
`onset to show with particularity why the patent it challenges is
`unpatentable.” Harmonic Inc. v. Avid Tech., Inc., 815 F.3d 1356, 1363 (Fed.
`Cir. 2016) (citing 35 U.S.C. § 312(a)(3) (requiring inter partes review
`petitions to identify “with particularity . . . the evidence that supports the
`grounds for the challenge to each claim”)). This burden of persuasion never
`shifts to Patent Owner. See Dynamic Drinkware, LLC v. Nat’l Graphics,
`Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015) (discussing the burden of proof in
`inter partes review). Furthermore, Petitioner cannot satisfy its burden of
`proving obviousness by employing “mere conclusory statements.” In re
`Magnum Oil Tools Int’l, Ltd., 829 F.3d 1364, 1380 (Fed. Cir. 2016).
`Thus, to prevail in an inter partes review, Petitioner must explain how
`the proposed combinations of prior art would have rendered the challenged
`claims unpatentable. At this final stage, we determine whether a
`preponderance of the evidence of record shows that the challenged claims
`
`6
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`would have been obvious over the proposed combinations of prior art.
`We analyze the instituted grounds of unpatentability in accordance
`with the above-stated principles.
`
`Level of Ordinary Skill in the Art
`
`B.
`The parties do not disagree as to the level of skill in the art. See
`generally Pet., PO Resp., Reply. We find that the level of ordinary skill in
`the art is reflected by the prior art of record. See Okajima v. Bourdeau,
`261 F.3d 1350, 1355 (Fed. Cir. 2001); In re GPAC Inc., 57 F.3d 1573, 1579
`(Fed. Cir. 1995); In re Oelrich, 579 F.2d 86, 91 (CCPA 1978).
`
`Claim Construction
`
`C.
`In the Decision to Institute, we did not construe any terms. Dec. 5.
`Patent Owner argues a construction for “maintaining a dictionary” (claims 1
`and 14) and “consecutively outputting a first control word indicating a run-
`length sequence, a code word in the dictionary . . . that corresponds to the
`input data block, and a word corresponding to the number of successive data
`blocks that are similar to the input data block” (claims 3 and 16). PO Resp.
`23–33. In response, Petitioner argues for a construction of “maintaining a
`dictionary” (claims 1 and 14) and “consecutively” (claims 3 and 16). Reply
`1–9.
`
`Consecutively (Claims 3 and 16)
`
`1.
`Patent Owner argues “consecutively outputting a first control word
`indicating a run-length sequence, a code word in the dictionary . . . that
`corresponds to the input data block, and a word corresponding to the number
`of successive data blocks that are similar to the input data block” (claims 3
`
`7
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`and 16) should be construed as “the control word indicating a run-length
`sequence is outputted before the other two words in the run-length
`sequence.” PO Resp. 27–32. At the outset, Patent Owner mischaracterizes
`Petitioner’s argument to construe “consecutively” (see Pet. 31) as a request
`to construe “consecutively outputting a first control word indicating a run-
`length sequence, a code word in the dictionary . . . that corresponds to the
`input data block, and a word corresponding to the number of successive data
`blocks that are similar to the input data block” (claims 3 and 16) to mean
`“following one another in uninterrupted order; successive.” PO Resp. 27.
`We note, however, that Petitioner did not argue for a construction of
`“consecutively outputting a first control word indicating a run-length
`sequence, a code word in the dictionary . . . that corresponds to the input
`data block, and a word corresponding to the number of successive data
`blocks that are similar to the input data block” (claims 3 and 16). Pet. 31;
`Reply 8. Rather, Petitioner argues for a construction of just the term
`“consecutively” (claims 3 and 16). Pet. 31; Reply 8.
`Regarding the construction of the phrase “consecutively outputting a
`first control word indicating a run-length sequence, a code word in the
`dictionary . . . that corresponds to the input data block, and a word
`corresponding to the number of successive data blocks that are similar to the
`input data block” (claims 3 and 16), Patent Owner argues the use of the term
`“first” recited in claims 3 and 16 necessitates a particular chronological
`order – i.e., the control word is output first. PO Resp. 28–30 (citing
`Ex. 2007 ¶¶ 101–107, 152). In addition, Patent Owner argues Petitioner is
`attempting to read out “first” from claims 3 and 16, thereby rendering the
`term “first” superfluous. PO Resp. 29.
`
`8
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`Patent Owner also argues its proposed construction is supported by a
`preferred embodiment discussed in the Specification of the ’812 patent that
`describes the control code being output first from the dictionary, followed by
`the code word for the character that is stored, which is then followed by the
`number of consecutive characters that were found in the input stream. PO
`Resp. 29–32 (citing Ex. 1001, 8:33–39, Fig. 4A).
`We disagree with Patent Owner. In particular, we disagree with
`Patent Owner that the word “first” necessitates a particular chronological
`order in which “a first control code word indicating a run-length sequence”
`(claims 3 and 16) is output before both “a code word in the dictionary
`having a unique data block string associated therewith that corresponds to
`the input data block” (claims 3 and 16) and “a word corresponding to the
`number of successive data blocks that are similar to the input data block”
`(claims 3 and 16) are output. More specifically, we disagree with Patent
`Owner because the word “first” recited in claims 3 and 16 modifies the
`claimed “control word” rather than modifying the claimed “outputting,”
`while “consecutively” modifies “outputting.” Ex. 1001, 17:9–15, 18:40–48.
`That is, claims 3 and 16 recite “first control code word” and “consecutively
`outputting.” Id. Because “first” modifies “control word” rather than
`modifying “outputting,” we are not persuaded by Patent Owner that “first”
`has any bearing on an alleged chronological order of outputs in claims 3 and
`16.
`
`Moreover, we disagree with Patent Owner’s argument that the
`Specification of the ’812 patent limits claims 3 and 16 to the chronological
`order of “words” described in the “preferred embodiment.” Ex. 1001, 6:14–
`33. Limiting a claim to what is described in a preferred embodiment is
`
`9
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`seldom correct. Hill-Rom Servs., Inc. v. Stryker Corp., 755 F.3d 1367, 1372
`(Fed. Cir. 2014) (“Even when the specification describes only a single
`embodiment, the claims of the patent will not be read restrictively unless the
`patentee has demonstrated a clear intention to limit the claim scope using
`‘words or expressions of manifest exclusion or restriction.’”).
`We instead adopt Petitioner’s definition of “consecutively” to mean
`“following one another in uninterrupted order; successive” (Pet. 31; Reply 8)
`because it is consistent with the plain and ordinary meaning and the
`Specification.
`
`Remaining Terms
`
`2.
`We determine that no other terms require express construction for
`purposes of this Decision. See Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`200 F.3d 795, 803 (Fed. Cir. 1999) (only those claim terms or phrases that
`are in controversy need to be construed, and only to the extent necessary to
`resolve the controversy).
`
`D.
`
`Overview of O’Brien (Ex. 1002)
`
`Alleged Obviousness of Independent Claims 1 and 14
`1.
`O’Brien teaches adaptive data compression to compress efficiently a
`user data file. Ex. 1002, Abs. O’Brien teaches that “[r]uns of three or more
`repeated bytes are encoded using a predetermined set of reserved reference
`values to indicate that the preceding character was repeated the number of
`times specified by the repeat code.” Id. at 3:67–4:2. O’Brien further teaches
`the adaptive data compression operates in a way such that strings are built a
`character at a time, which means “a previously defined string plus the next
`
`10
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`user data byte shall define a new string and is assigned the next previously
`undefined reference value.” Id. at 12:23–31. As a result, strings become
`longer and data compression becomes more efficient as more data bytes are
`examined. Id. at 12:31–33. String definition occurs by combining the last
`used reference value with the next user data byte; this resultant string is then
`used to search the string table to determine if this string was defined
`previously. Id. at 12:34–36. If the string was defined previously, the next
`subsequent data byte is concatenated to the reference value of the string that
`has been found to form a new string table search pattern. Id. at 12:36–41.
`The search is repeated iteratively until a string is found that has not been
`defined previously. Id. at 12:43–44. Once the undefined string is found, the
`last used defined string reference is placed in the output compressed data
`stream and the next consecutive unused reference value is assigned to this
`undefined string. Id. at 12:44–48.
`
`Overview of Nelson (Ex. 1003)
`
`2.
`Nelson teaches source code for a complete version of Lempel-Ziv-
`Welch (“LZW”) compression and decompression. Ex. 1003, 306. Nelson
`teaches using a dictionary to include definitions of symbols, code,
`characters, etc. Id. at 308. In addition, Nelson teaches adding definitions to
`the dictionary if a definition is not present in the dictionary. Id.
`
`O’Brien Teaches Maintaining a Dictionary (Claims 1 and 14)
`
`3.
`The parties’ dispute focuses on whether O’Brien teaches “maintaining
`a dictionary” as recited in claims 1 and 14. Pet. 40–42, 55–57; PO Resp.
`35–40. Because Petitioner has the burden of proof (see 35 U.S.C. § 316(e),
`37 C.F.R. § 42.20(c)), we begin with Petitioner’s arguments.
`
`11
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`Petitioner argues O’Brien teaches string compression, which is a
`dictionary algorithm. Pet. 41 (citing Ex. 1005 ¶ 84). Petitioner further
`argues that a person having ordinary skill in the art would have considered
`O’Brien’s “reference values” to be dictionary indices. Id. And, Petitioner
`argues “[t]he combination of character reference values mapped to
`characters and string reference values mapped to character strings stored in
`the string table is an example of a ‘dictionary.’ (Run length reference values
`are also part of the ‘dictionary,’ as control code words.)” Id. Petitioner
`argues O’Brien creates, populates, and uses the data structures and logic
`associated with its reference values and string table, and therefore that
`O’Brien teaches “maintaining a dictionary” as recited in claim 1 and 14. Id.
`at 41–42, 55–57.
`In response, Patent Owner argues that O’Brien’s segmentation
`approach fails to teach maintaining a dictionary because O’Brien generates a
`new dictionary for each new segment. PO Resp. 33–40. In particular,
`Patent Owner argues O’Brien divides its input data into segments of a pre-
`determined size; O’Brien then encodes each segment independently from the
`other segments and discards the dictionary after each segment is encoded
`and assigns new reference values for each segment. Id. at 34 (citing
`Ex. 1002, Abstract; Ex. 2009, 43:14–20).
`Patent Owner argues because O’Brien discards the dictionary and
`assigns new reference values for each segment, O’Brien fails to teach
`“maintaining a dictionary” pursuant to Patent Owner’s proposed
`construction. PO Resp. 34–35. Moreover, Patent Owner also argues
`O’Brien’s BEGIN and END variables teaches the generating and discarding
`
`12
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`of dictionaries, which Dr. Creusere acknowledges. Id. at 35–37 (citing
`Ex. 2009, 55:4–9).
`Patent Owner further argues O’Brien’s adaptive algorithm builds a
`dictionary by matching input strings to strings that were defined previously
`in the dictionary until a match is not found; then, O’Brien’s algorithm adds
`the unmatched string to an unused reference value in the dictionary. PO
`Resp. 38–39. Patent Owner argues O’Brien’s adaptive dictionary
`compression algorithm fails to teach “maintaining a dictionary” because it
`never makes a determination of whether to retain the dictionary during the
`course of compression of the input data stream and instead, discards its
`dictionary after encoding each segment and generates a new dictionary. Id.
`at 39–40 (citing Ex. 2007 ¶¶ 117–119; Ex. 2009, 55:4–9). We disagree with
`Patent Owner.
`At the outset, we note that Petitioner, Patent Owner, and their
`respective declarants all agree that O’Brien’s encoder is a type of dictionary
`encoder. See e.g., Pet. 41; PO Resp. 16–18; Ex. 1005 ¶¶ 32, 84; Ex. 2007
`¶¶ 74, 79, 80, 82, 85. Because O’Brien teaches a “dictionary,” we now turn
`to whether O’Brien teaches the larger phrase, “maintaining a dictionary” as
`recited in claims 1 and 14. To determine whether O’Brien teaches
`“maintaining a dictionary,” we turn to dependent claims 4 and 17 (Ex. 1001,
`17:16–22, 18:48–55), which depend from claims 1 and 14, respectively.
`Dependent claim 4 recites “maintaining a dictionary comprises the
`step of: dynamically generating a new code word corresponding to a built
`data block string, if the built data block string does not match a unique data
`block string in the dictionary; and adding the new code word in the
`
`13
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`dictionary” (emphasis added). Id. at 17:16–22. Dependent claim 17 recites
`similar features. Id. at 18:48–55.
`We are persuaded that a person having ordinary skill in the art would
`have considered O’Brien’s “reference values” to be dictionary indices,
`because O’Brien’s string compression includes the signature features of
`LZ78 (i.e., Lempel and Ziv’s paper in 1978) and LZW, which are dictionary
`algorithms. Pet. 41. Moreover, O’Brien teaches an adaptive algorithm that
`builds a dictionary by combining strings and matching these combined
`strings to strings that were defined previously in the dictionary until a match
`is not found. Id. at 49 (citing Ex. 1004, 12:43–48; Ex. 1005 ¶ 101); see id. at
`55. At that juncture, O’Brien’s algorithm adds the unmatched combined
`string to an unused reference value in the dictionary, which we find to teach
`“maintaining a dictionary comprises the step of: dynamically generating a
`new code word corresponding to a built data block string, if the built data
`block string does not match a unique data block string in the dictionary; and
`adding the new code word in the dictionary” (emphasis added) as recited in
`claim 4 (and similarly recited in claim 17). Pet. 49 (citing Ex. 1004, 12:43–
`48; Ex. 1005 ¶ 101); see id. at 55.
`Accordingly, because O’Brien teaches “dynamically generating a new
`code word corresponding to a built data block string, if the built data block
`string does not match a unique data block string in the dictionary; and
`adding the new code word in the dictionary” recited in dependent claims 4
`and 17, we are persuaded that Petitioner has established by a preponderance
`of the evidence that O’Brien teaches “maintaining a dictionary” (claims 1
`and 14).
`
`14
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`4.
`
`O’Brien’s Dictionary Encoder is Similar to a LZ78 and LZW
`Dictionary Encoder
`
`Petitioner argues O’Brien combines run-length encoding with LZ78 or
`LZW dictionary encoding. Pet. 10–11 (citing Ex. 1005 ¶¶ 32–40). In
`particular, Petitioner argues that O’Brien teaches “an example of an LZW
`variation of the LZ78 dictionary encoder.” Id. at 13 (citing Ex. 1005 ¶¶ 35–
`40). That is, O’Brien first initializes a dictionary with code words for all
`possible characters such that, at the beginning of each data segment,
`reference value encoder 304 is provided with two variables, END and
`BEGIN that correspond to the largest and smallest individual character
`codes in the data segment. Id. at 13–14 (citing Ex. 1002, 10:19–25).
`According to Petitioner, O’Brien’s END and BEGIN variables define the
`range of reference values, or code words that represent single characters and
`are referred to as character reference values. Pet. 14 (citing Ex. 1002,
`10:22–28). Petitioner also argues that O’Brien’s setting a range of character
`reference values and associated single characters “is analogous to the
`initialization of the LZW dictionary with all possible single characters.” Id.
`(citing Ex. 1005 ¶ 36).
`Petitioner then explains that O’Brien compression technique uses
`signature features of an LZ78 dictionary encoder. Pet. 13–15. In particular,
`Petitioner explains that
`O’Brien’s reference value encoder uses the signature LZ78
`features of 1) reading the next input character; 2) adding the next
`input character to the current prefix string to build a new,
`combined string; 3) searching the dictionary to see if the new
`string is found; 4) if so, continuing by updating the prefix string,
`building the new string by adding one character at a time, and
`continuing to search the dictionary until the new string is not
`
`15
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`found; 5) when the new string is not found in the dictionary,
`outputting the reference value for the prefix string and adding the
`new string to the dictionary. As in LZW, O’Brien’s encoder also
`includes features of initialization of code words (character
`reference values) for individual characters and setting the prefix
`string (referenced by last RV) to be the last input character when
`a combined string is not found in the string table. As such, it is
`a classic LZW dictionary encoder.
`
`Pet. 15–16 (citing Ex. 1005 ¶ 40) (emphases added).
`Moreover, Petitioner presents a table comparing the similarities
`between LZ78 compression, LZW compression, O’Brien’s compression, and
`that of the ’812 patent, and contrasting LZ77 (i.e., Lempel and Ziv’s paper in
`1977) compression with the aforementioned compression techniques. Reply
`14. Petitioner’s table is reproduced below.
`
`Petitioner’s table, above, illustrates three characteristics: “sliding
`window dictionary”; “initializes with all possible single character strings”;
`and “builds dictionary by adding new strings.” Petitioner argues its table
`illustrates that LZ77 is unlike O’Brien in that LZ77 has a sliding window
`
`
`
`16
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`dictionary, whereas O’Brien does not. Reply 14–15, 17. In addition,
`Petitioner explains the table illustrates that LZ77 does not initialize its
`dictionary with all possible single character strings, whereas O’Brien does.
`Id. at 15–17. Petitioner also points out that its table illustrates LZ77 does
`not build its dictionary by adding new strings, whereas O’Brien builds its
`dictionary by adding new strings. Id. at 16–17.
`Furthermore, Petitioner argues its table illustrates that LZ77 is unlike
`the ’812 patent in that LZ77 has a sliding window dictionary, whereas the
`’812 patent does not. Id. at 14–15, 17. In addition, Petitioner explains the
`table illustrates that LZ77 does not initialize its dictionary with all possible
`single character strings, whereas the ’812 patent does. Id. at 15–18.
`Petitioner also points out that its table illustrates LZ77 does not build its
`dictionary by adding new strings, whereas the ’812 patent does build its
`dictionary by adding new strings. Id. at 16–17.
`Patent Owner argues that O’Brien’s dictionary encoder is “more akin
`to an LZ77 dictionary encoder.” PO Resp. 16 (citing Ex. 2007 ¶¶ 82–83,
`85–86). In particular, Patent Owner argues that rather than reinitializing the
`dictionary when the dictionary is full and maintaining a dictionary when the
`dictionary is not full, O’Brien’s system, instead, partitions the input data into
`segments and uses a separate dictionary for each segment, which is similar
`to the functioning of an LZ77 dictionary encoder. Id. at 17 (citing Ex. 2007
`¶¶ 74–75). According to Patent Owner, O’Brien’s segmenting is a basic
`principle of its operation and can prevent its dictionary from becoming full,
`which ensures the dictionary does not impact negatively the encoding speed
`that data compression requires. Id. at 17–18.
`
`17
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`Moreover, Patent Owner argues its declarant, Mr. Laub, states that Dr.
`Creusere’s classification of O’Brien’s dictionary encoder as both an LZ78
`and an LZW dictionary encoder is flawed for several reasons. PO Resp. 18–
`21. First, Patent Owner argues that Petitioner is conflating LZ78 and LZW
`because LZW initializes the dictionary with all 256 possible single
`characters, whereas LZ78 starts with an essentially empty dictionary and
`builds the dictionary out of previously seen symbols in the input data. Id. at
`14–15, 19 (citing Ex. 2007 ¶ 78).
`Second, Patent Owner argues that O’Brien is neither an LZ78
`dictionary encoder nor an LZW dictionary encoder. PO Resp. 19. Patent
`Owner argues O’Brien is not an LZ78 dictionary encoder because O’Brien
`does not use a single dictionary for the entire input data, whereas an LZ78
`dictionary encoder can use the dictionary for an entire input data stream. Id.
`at 14, 19–20. Patent Owner further argues that O’Brien is not an LZ78
`dictionary encoder because O’Brien segments its data similar to a text
`window, whereas the LZ78 dictionary encoder abandons the text window.
`Id. at 14, 19.
`Patent Owner also argues O’Brien is not an LZW dictionary encoder
`because O’Brien does not initialize a dictionary to include all 256 possible
`single characters, whereas an LZW dictionary encoder does initialize a
`dictionary. Id. at 15, 20. And, Patent Owner argues O’Brien is not an LZW
`dictionary encoder because O’Brien does not use a single dictionary for the
`entire input data, whereas an LZW encoder can use the dictionary for the
`entire input data stream. Id. at 14, 20.
`Third, Patent Owner argues that Petitioner’s interpretation of O’Brien
`is wrong because O’Brien looks at short pieces of input data; much like an
`
`18
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`LZ77 dictionary encoder’s sliding window. Id. at 13–14, 20–21. According
`to Patent Owner, both O’Brien and an LZ77 dictionary encoder limit their
`dictionaries to the contents of those short pieces. Id. at 20–21.
`Patent Owner also argues that third parties having no interest in the
`present proceeding and Mr. Laub’s opinion characterize O’Brien’s encoder
`as an LZ77 dictionary encoder rather than as an LZ78 or an LZW dictionary
`encoder. PO Resp. 21–22 (citing Ex. 2010, 2; Ex. 2011, 1). These third
`parties and Mr. Laub characterize U.S. Patent No. 4,988,998 (“the ’998
`patent”), which is also issued to O’Brien, as an LZ77 compression
`technique. Id. at 21–22 (citing Ex. 2007 ¶ 84). We disagree with Patent
`Owner.
`At the outset, the instituted claims of the ’812 patent lack any implicit
`or explicit recitation of the type of dictionary compression. Instead, the
`instituted claims set forth the particular actions the claimed compressor
`requires. That said, whether O’Brien is more akin to LZ77, LZ78, or LZW
`is irrelevant and not dispositive to the present case. The important factor is
`whether O’Brien’s actions to compress the input data are the same as the
`actions required by claim 1. We believe the Petition shows that O’Brien’s
`actions are the same actions required by claim 1.
`Nonetheless, we analyze the parties’ argument regarding what type of
`compression is most similar to O’Brien’s type of compression because
`resolving the parties’ issue is helpful in determining whether O’Brien’s
`compression type is similar to Nelson’s compression type, as we will discuss
`infra in §§ II.D.5., II.D.6., II.D.7., and II.D.8.
`Although both an LZ77 dictionary encoder and O’Brien look at short
`pieces of input data (see PO Resp. 20–21), we agree with Petitioner that
`
`19
`
`
`
`IPR2016-00783
`Patent 6,597,812 B1
`
`there are numerous significant departures between an LZ77 dictionary
`encoder and O’Brien (see Reply 14). First, LZ77 is unlike O’Brien in that
`LZ77 has a sliding window dictionary, whereas O’Brien does not. Reply
`14–15, 17. Second, LZ77 does not initialize its dictionary with all possible
`single character strings, whereas O’Brien does. Id. at 15–17. Third, LZ77
`does not build its dictionary by adding new strings, whereas O’Brien builds
`its dictionary by adding new strings. Id. at 16–17. Fourth, an LZ77
`dictionary encoder has a fixed size dictionary, whereas O’Brien does not.
`Id. at 18. Fifth, LZ77 does not process fixed sized segments of input data,
`whereas O’Brien processes mostly fixed sized segments. Id.
`Moreover, Mr. Laub’s statement that O’Brien is more akin to an LZ77
`dictionary encoder rather than an LZ78 or LZW dictionary encoder because
`both an LZ77 dictionary encoder and O’Brien look at short pieces of data is
`flawed. This flaw exists because the sliding window of an LZ77 dictionary
`encoder is a window of already processed input data that operates as a
`dictionary, whereas O’Brien’s segments are unprocessed chunks of input
`data. Id.
`Patent Owner and Mr. Laub’s reliance on Exhibit 2010 and 2011 (see
`PO Resp. 21–22; Ex. 2007 ¶¶ 83–84) is misplaced because those Exhibits
`discuss a different patent rather than the ’812 patent at issue in this
`proceeding. Exhibit 2010 is a PCT application and Exhibit 2011 is a blog,
`and both state that the ’998 patent issued to O’Brien uses LZ77 compression
`(see Ex. 2010, 2; Ex. 2011, 1); however, the O’Brien patent at issue in this
`proceeding is the ’812 patent – a differ
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
