Trials@uspto.gov
`571-272-7822
`
`
`
`
`
`Paper: 7
`Entered: December 5, 2017
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`
`
`
`LG ELECTRONICS, INC.,
`Petitioner,
`
`v.
`
`BROADCOM CORPORATION,
`Patent Owner.
`____________
`
`Case IPR2017-01544
`Patent 7,342,967 B2
`____________
`
`
`
`Before THOMAS L. GIANNETTI, PATRICK M. BOUCHER, and
`NORMAN H. BEAMER, Administrative Patent Judges.
`
`GIANNETTI, Administrative Patent Judge.
`
`
`
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`On June 13, 2017, LG Electronics, Inc. (“Petitioner”) filed a Petition
`(Paper 2, “Pet.”) pursuant to 35 U.S.C. §§ 311–319 to institute an inter
`partes review of claims 1–5 of U.S. Patent No. 7,342,967 B2 (“the ’967
`patent”). On September 19, 2017, Broadcom Corporation (“Patent Owner”)
`filed a Preliminary Response (Paper 6, “Prelim. Resp.”). Applying the
`
`
`571-272-7822
`
`
`
`
`
`Paper: 7
`Entered: December 5, 2017
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`
`
`
`LG ELECTRONICS, INC.,
`Petitioner,
`
`v.
`
`BROADCOM CORPORATION,
`Patent Owner.
`____________
`
`Case IPR2017-01544
`Patent 7,342,967 B2
`____________
`
`
`
`Before THOMAS L. GIANNETTI, PATRICK M. BOUCHER, and
`NORMAN H. BEAMER, Administrative Patent Judges.
`
`GIANNETTI, Administrative Patent Judge.
`
`
`
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`On June 13, 2017, LG Electronics, Inc. (“Petitioner”) filed a Petition
`(Paper 2, “Pet.”) pursuant to 35 U.S.C. §§ 311–319 to institute an inter
`partes review of claims 1–5 of U.S. Patent No. 7,342,967 B2 (“the ’967
`patent”). On September 19, 2017, Broadcom Corporation (“Patent Owner”)
`filed a Preliminary Response (Paper 6, “Prelim. Resp.”). Applying the
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`standard set forth in 35 U.S.C. § 314(a), which requires demonstration of a
`reasonable likelihood that Petitioner would prevail with respect to at least
`one challenged claim, we grant the Petition and institute an inter partes
`review of claims 1–5.
`
`I. BACKGROUND
`A. The ’967 Patent
`The ’967 patent is titled “System and Method for Enhancing
`Performance of Personal Video Recording (PVR) Functions on HITS Digital
`Video Streams.” Ex. 1001. The patent relates to video recorder and
`playback systems, and more particularly to controlling the presentation of
`content. Id. col. 1, ll. 26–28.
`Currently, distribution of digital video content for TV display is
`dominated by use of the MPEG-2 video compression standard. Id. col. 1, ll.
`30–33. An MPEG-encoded stream may have three types of pictures: Intra-
`coded (I), Predicted (P), and Bi-directionally predicted (B). I-pictures are
`not compressed using any temporal predictions and can be decoded without
`the need of any other picture. P-pictures perform temporal predictions from
`a picture that comes before it in the display order. B-pictures are bi-
`directionally predicted and use two pictures for prediction, one from the past
`and another from the future (in display order). Id. col. 1, ll. 35–47.
`A special class of MPEG-2 streams, known as “Headend In The Sky”
`or “HITS” streams, do not include I-pictures, in order to increase the video
`compression and reduce the bandwidth required to transmit a video stream.
`Instead, HITS streams use a progressive refresh mechanism to build
`reference pictures. Id. col. 2, ll. 1–6.
`
`2
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`
`The progressive refresh mechanism of HITS mandates that each P-
`picture have at least one intra-coded or I-slice, where a slice is 16 horizontal
`lines of pictures. Id. col. 2, ll. 6–9. Furthermore, the intra-coded slice(s) in
`a P-picture will be just below the intra-coded slice(s) of the previous P-
`picture, and the top slice is intra-coded for a P-picture following a P-picture
`with an intra-coded slice at the bottom of the picture. Id. col. 2, ll. 9–13.
`Additionally, the HITS streams ensure that the slices above the intra-
`coded slice(s) predict only from those slices of the previous P-picture that
`are above the current I slice(s). Id. col. 5, ll. 53–56. Thus, the slices are
`progressively refreshed from top to bottom. Id. col. 2, ll. 19–20. This
`ensures that if a series of pictures is decoded starting from a P-picture whose
`first-slice is intra-coded, then a “clean” refreshed picture will be built after
`all slices have been progressively refreshed. Id. col 5, ll. 56–59.
`The P-picture whose first-slice is intra-coded is called an Entry Point
`(EP) picture. The P-picture immediately before the EP picture, i.e., the P-
`picture with the I-slice(s) at the bottom of the picture, will be referred to as a
`clean reference picture RP. Id. col. 5, ll. 60–64. This is illustrated by
`Figure 4 of the ’967 patent, reproduced below as annotated by Petitioner
`(Pet. 5):
`
`3
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`
`
`
`In annotated Figure 4, each of a first P-picture P14 and second P-
`picture P15 includes slices (indicated in red) above an intra-coded slice
`(shaded in green), and slices (shaded in blue) below the intra-coded slice.
`Pet. 4. The downward progression of intra-coded slices from picture to
`picture enables predicting slices above an intra-coded slice in a later picture
`(e.g., P15) based on only the slices of the previous P-picture (e.g., P14) that
`are above the current intra-coded slice. Id.
`During rewind of a HITS stream, the video decoder builds a clean
`reference picture.1 The clean reference picture is built by decoding each of
`the P-pictures in the EP-EP segment. Ex. 1001, col. 2, l. 65–col. 3, l. 1.
`However, because the P-pictures are not displayed, the decoder does not
`decode the portion of the P-picture below the last I slice. Id. col. 3, ll. 1–3.
`The decoder can build the clean reference picture without decoding the
`portions of the P-pictures below the last I-slice because the subsequent
`
`
`1 Pausing, fast forwarding, rewinding, and skipping portions of the video
`stream are sometimes referred to as “trick modes.” Delp Decl. ¶ 96.
`
`4
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`pictures do not use those portions for prediction. Id. col. 3, ll. 3–7. Omitting
`decoding the portion of the P-pictures below the I-slice advantageously
`reduces the processing required to build a clean reference picture. Id. col. 3,
`ll. 8–10.
`
`B. Illustrative Claims
`Challenged claim 1 of the ’967 patent is the only independent claim.
`Claim 1 is reproduced here:
`1. A system for displaying pictures, said system
`comprising:
`
`a host processor for transmitting transport packets, said
`transport packets providing a plurality of instructions;
`
`a video decoder for executing the plurality of
`instructions; and
`wherein execution of the instructions by the video
`decoder comprises causing:
`selecting a picture, said picture comprising an intracoded
`slice and at least one slice above the intracoded slice, and at
`least one slice below the intracoded slice;
`decoding the at least one slice above the intracoded slice;
`decoding the intracoded slice; and
`decoding at least a portion of another picture after
`decoding the at least one slice above the intracode slice and the
`intracode slice without having decoding the at least one slice
`below the intracoded slice.
`Ex. 1001, col. 8, ll. 8–27.
`
`C. References
`Petitioner relies on the following patent publications:
`
`MacInnis US 2002/0061183 A1 Pub. May 23, 2002 Ex. 1003
`
`5
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`
`Ex. 1004
`
`Chen ’677 US 2001/0026677 A1 Pub. Oct. 4, 2001
`Petitioner relies also on ISO/IEC Standard 13818-2:2000:
`“Information technology-Generic coding of moving pictures and associated
`audio information: Video.” Ex. 1009 (“ISO 13818-2”).
`
`In addition, Petitioner provides an expert declaration of Dr. Edward J.
`Delp, which we have also considered. Ex. 1002 (“Delp Decl.”).
`
`D. Asserted Grounds of Unpatentability
`Petitioner challenges claims 1–5 over the following references:
`
`Reference(s)
`
`MacInnis
`MacInnis and ISO 13818-2
`Chen ’677
`Chen ’677
`Chen ’677 and ISO 13818-2
`
`Claim(s)
`1–5
`4
`1–4
`5
`1–5
`
`Basis
`§ 102(a)
`§ 103(a)
`§ 102(a)
`§ 103(a)
`§ 103(a)
`
`E. Real Parties in Interest
`Petitioner identifies LG Electronics, Inc. and LG Electronics U.S.A.,
`Inc. as real parties in interest in this proceeding. Pet. 80.
`Patent Owner identifies only itself as a real party in interest.
`Paper 4, 1.
`
`F. Related Proceedings
`The parties identify the following proceedings as involving the ’171
`patent: (1) Broadcom Corp. v. VIZIO, Inc., Case No. 8:17-cv-00408 (C.D.
`Cal.); (2) Broadcom Corp. v. LG Elecs. Inc., Case No. 8:17-cv-00404 (C.D.
`Cal.); (3) Broadcom Corp. v. Media Tek Inc., Case No. 8:17-cv-00405 (C.D.
`Cal.); and (4) In re: Certain Semiconductor Devices and Consumer
`
`6
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`Audiovisual Products Containing the Same, 337-TA-1047 (USITC). Pet.
`80; Paper 4, 1.
`
`II. ANALYSIS
`A. Claim Construction
`The Board interprets claims of an unexpired patent using the broadest
`reasonable construction in light of the specification of the patent in which
`they appear. See 37 C.F.R. § 42.100(b); Cuozzo Speed Techs., LLC v. Lee,
`136 S. Ct. 2131, 2144–46 (2016). Terms are given their ordinary and
`customary meaning, as would be understood by one of ordinary skill in the
`art at the time of the invention. In re Translogic Tech., Inc., 504 F.3d 1249,
`1257 (Fed. Cir. 2007). The broadest reasonable construction must be
`“consistent with the specification.” In re Morris, 127 F.3d 1048, 1054 (Fed.
`Cir. 1997) (citation omitted); see also In re Suitco Surface Inc., 603 F.3d
`1255, 1259–60 (Fed. Cir. 2010).
`While the claims must be read in view of the specification, limitations
`from the specification are not to be read into the claims. Teleflex, Inc. v.
`Ficosa N. Am. Corp., 299 F.3d 1313, 1326 (Fed. Cir. 2002) (citations
`omitted). 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. Liebel-Flarsheim Co. v.
`Medrad, Inc., 358 F.3d 898, 906 (Fed. Cir. 2004) (citing Teleflex, supra).
`Claim terms need only be construed to the extent necessary to resolve
`the controversy. Wellman, Inc. v. Eastman Chem. Co., 642 F.3d 1355, 1361
`(Fed. Cir. 2011).
`
`7
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`
`1. “instructions”
`This term appears in all claims. Petitioner proposes the following
`construction: “commands, separate from video or audio data that specify
`trick play functions to be performed.” Pet. 12. Patent Owner responds that
`“[f]or the purpose of this preliminary response, Patent Owner is applying
`LG’s proposed construction of the term ‘instructions.’” Prelim. Resp. 5.
`We have considered Petitioner’s construction and the supporting record
`citations. Pet. 12–13. Specifically, we have concluded that the intrinsic
`record supports Petitioner’s conclusion that the broadest reasonable
`construction of the term “instructions” does not require that the commands
`be part of the contents of the compressed audio or video itself. Id.
`However, we are not convinced by Petitioner’s argument that the commands
`necessarily must be separate from audio or video data. The references by
`Petitioner to certain embodiments in the specification of the ’967 patent and
`its parent application at pages 12–13 of the Petition do not persuade us that
`we should read this limitation into the claims. See Liebel-Flarsheim Co.,
`358 F.3d at 906. Nor are we persuaded that instructions should be limited to
`commands that specify trick play functions. The ’967 patent describes
`handling the packets containing commands as follows:
`The data transport processor then de-multiplexes the TS
`[transport stream] into its PES constituents and passes the audio
`TS to an audio decoder 360 and the video TS to a video transport
`processor 340, and then to a MPEG video decoder 345 that is
`operable to decode and extract embedded, TS formatted
`command packets, that may include instructions to perform trick
`play functionality.
`Ex. 1001, col. 5, ll. 7–13 (emphasis added). Thus, according to the
`specification, command packets may or may not include instructions for
`
`8
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`performing trick play functions. Accordingly, we construe “instructions” as
`“commands that specify playback functions to be performed, including trick
`play functionality.”
`2. “host processor”
`Although neither party expressly requested construction of this term,
`determining its meaning appears necessary. See discussion infra. Petitioner
`adopts a construction it states was proposed by Patent Owner in ITC
`Investigation No. 337-TA-1047, identified supra as a Related Proceeding.
`Pet. 54 (citing Ex. 1008). According to Petitioner, under that construction, a
`“host processor” is “any device or element that processes an incoming
`transport stream (i.e., a stream of packets), extracts the packets from the
`stream, and passes the packets on to a decoder device (such as any audio or
`visual decoding device or functionality).” Id. Patent Owner does not
`challenge this contention, referring to it as Petitioner’s “own applied
`construction of the term.” Prelim. Resp. 7.
`We are not persuaded that this is the broadest reasonable construction
`consistent with the specification. Figure 1 of the ’967 patent, reproduced
`below, shows host processor 110 as a box communicating with the decoder:
`
`9
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`
`Figure 1 of the’967 patent is a block system diagram of a personal video
`recording system. Ex. 1001, col. 3, ll. 23–25. The ’967 patent specification
`describes the host processor as performing two functions: providing a data
`transport stream to decoder 120 and controlling the playback (including trick
`playback) of the data. Id. col, 3, ll. 45–50. Accordingly, consistent with the
`specification, we construe “host processor” as “a device or element that
`delivers an incoming transport stream (i.e., a stream of packets) that may
`contain instructions for controlling the playback to a decoder device (such as
`any audio or visual decoding device or functionality).”
`
`3. Other Terms
`Petitioner proposes constructions for two other terms appearing in the
`claims: “without having decoding the at least one slice below the intracoded
`slice,” and “transport packet.” Pet. 14–15. We determine that at this stage,
`construction of those terms is unnecessary.
`
`10
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`
`B. Challenges Based on MacInnis
`1. Overview of MacInnis (Ex. 1003)
`
`MacInnis it titled “System and Method for Personal Video
`
`Recordings.” MacInnis describes a system and method for implementing
`trick modes such as fast forward and reverse for digital audio-video systems.
`Ex. 1003 ¶ [0002]. MacInnis describes decoding of digital streams having
`no I-pictures such as HITS. Id. ¶ [0050]. Figure 4A of MacInnis and the
`accompanying text describe a video stream with no I-pictures in which the
`P-pictures include a pattern of I-slices that appear sequentially from top to
`bottom. An annotated version of Figure 4A from the Petition (Pet. 19)
`follows:
`
`
`
`Figure 4A of MacInnis (annotated) illustrates changes to the location
`of I-slices in a block of pictures without I-pictures. Ex. 1003 ¶ [0018]. The
`I-slices move down until all rows in the consecutive sequence of pictures
`have been represented in I-slices. Pet. 19 (citing Ex. 1003 ¶¶ [0056]–
`[0057]). MacInnis also describes a system for implementing reverse play.
`Id. ¶¶ [0108]–[0119]; Pet. 19–23.
`
`11
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`
`
`2. Anticipation of Claims 1–5 by MacInnis
`Petitioner sets forth an element-by-element analysis of claim 1 of the
`’967 patent in relation to MacInnis at pages 23–38 of the Petition. Petitioner
`contends that each element of claim 1 is met by MacInnis. For example, the
`claim recites “a host processor for transmitting transport packets, said
`transport packets providing a plurality of instructions.” Petitioner provides
`alternative analyses of this element. Pet. 25–28. The first assumes the term
`“instructions” is construed as “commands, separate from video or audio data
`that specify trick play functions to be performed.” Pet. 25. Under this
`construction, Petitioner identifies CPU 113 in MacInnis as meeting this
`limitation. Id. at 27. According to Petitioner, “CPU 113 inserts into the
`stream transport packets that contain commands, separate from video or
`audio data, that specify trick play functions to be performed (i.e.,
`‘instructions’) into a stream for transmission to video transport processor
`118 and video decoder 120.” Pet. 27.
`Petitioner’s alternative analysis assumes that “instructions” are “the
`contents of the coded or compressed audio or video syntax itself.” Id.
`Because we were not persuaded to adopt this construction, we do not
`consider this alternative analysis. We have, instead, construed “instructions”
`as “commands that specify playback functions to be performed, including
`trick play functionality.” See supra. We determine that under either this
`construction or the construction proposed by Petitioner, this element is met
`by MacInnis. Furthermore, we determine that the other elements of claim 1
`are met by MacInnis for the reasons advanced by Petitioner.
`Patent Owner responds that this anticipation challenge fails because
`Petitioner does not explain how the instructions “cause the system to
`
`12
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`perform the slice decoding steps described in claim 1.” Prelim. Resp. 8.
`According to Patent Owner, MacInnis’s slice decoding process “occurs
`irrespective of the commands received.” Id. at 8. We are not persuaded by
`this argument. According to MacInnis, “CPU 113 preferably reads the
`[MPEG transport stream] data from the storage device 102 based on the user
`selected playback mode.” Ex. 1003 ¶ [0036]. Further: “CPU 113 may
`control the data transport processor 116 and/or the video transport processor
`118 to implement trick modes.” Id. ¶ [0037]. Still further,
`[A] data transport driver (DTD) which preferably runs in the
`CPU 113, preferably is responsible for data flow of the stream to
`be played back through the data transport processor 116 and/or
`the video transport processor 118. The DTD in this embodiment
`also preferably inserts a command transport packet containing
`various commands to the video transport processor 118 and the
`video decoder 120. The inserted transport packet preferably
`contains command fields for controlling the data flow of the
`MPEG video stream during play back . . . .
`Id. ¶ [0040] (emphasis added).
`We have construed “instructions” as “commands that specify
`playback functions to be performed, including trick play functionality.” We
`are persuaded by Petitioner’s argument that the “causing” limitation is met
`by this operation in MacInnis in which the transport packets deliver
`commands that control the playback. Pet. 29.
`In view of the foregoing, and on this record, we are persuaded that
`Petitioner has established a reasonable likelihood of prevailing on its
`anticipation challenge to claim 1 based on MacInnis.
`We reach the same conclusion as to claims 2–5. Petitioner provides
`element-by-element claim analyses for each of these claims in relation to
`MacInnis. Pet. 38–47. Petitioner contends that each element of claims 2–5
`
`13
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`is met by MacInnis. For example, as to claim 4, Petitioner asserts that the
`claim element “decoding the at least one slice in raster order” is met by the
`description in MacInnis of decoding I-slices from top to bottom. Pet. 45–46
`(citing Fig. 4A of MacInnis, reproduced supra).
`Patent Owner does not present separate arguments as to these
`dependent claims. We have reviewed Petitioner’s claim analyses and find
`them persuasive. In view of the foregoing, and on this record, we are
`persuaded that Petitioner has established a reasonable likelihood of
`prevailing on its anticipation challenge to claims 2–5 based on MacInnis.
`
`3. Obviousness of Claim 4 over MacInnis and ISO 13818-2
`Petitioner presents this ground as an alternative, “to the extent that
`[Patent Owner] argues or the Board finds, before or after institution, that
`MacInnis does not expressly disclose ‘decoding the at least one slice in
`raster order.’” Pet. 47–48. Petitioner relies on ISO 13818-2 for this feature
`only. Id. Petitioner points out that MacInnis specifically refers to the rows
`and slices defined in ISO 13838-2. Pet. 48 (citing Ex. 1003 ¶ [0054]).
`Petitioner further points out that ISO 13838-2 refers to “proceeding by raster
`scan order” and describes a top to bottom order of decoding. Id. at 48–49.
`On this record, we are persuaded that a person of ordinary skill would have
`found it obvious to implement the teachings of MacInnis so as to decode at
`least one slice in raster order as taught in ISO 13818-2. Id. at 49. In view of
`the foregoing, we are persuaded that Petitioner has established a reasonable
`likelihood of prevailing on this challenge to claim 4.
`
`14
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`
`
`
`C. Challenges Based on Chen ’677
`1. Overview of Chen ’677 (Ex. 1004)
`Chen ’677 is titled “Methods and Apparatus for Transcoding
`Progressive I-slice Refreshed MPEG Data Streams to Enable Trick Play
`Mode Features on a Television Appliance.” Chen ’677 describes decoding
`progressive I-slice refreshed MPEG data streams to facilitate trick play
`modes on a television appliance. Ex. 1004 ¶ [0002]. Figure 1 of Chen ’677,
`reproduced below, provides an example of such a stream:
`
`
`
`
`
`Figure 1 of Chen ’677 shows a video stream where the I-frame is
`divided into slices and spread across P-frames. Chen ’677 explains that
`those skilled in the art will appreciate that the P-frames need only be
`partially decoded in order to recover the I-slices. Id. ¶ [0025].
`Reconstructing a P-frame requires decoding at least the previous frame. Id.
`¶ [0022]. For example, I-slice 25 and P-slice 40 in P-frame P4 provide
`
`15
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`“reference macroblocks” that can be used to predict the contents of P-slice
`45 in P-frame P7. Id. ¶ [0023].
` 2. Anticipation of Claims 1–4 by Chen ’677
`Petitioner sets forth an element-by-element analysis of claims 1–4 of
`the ’967 patent in relation to Chen ’677 at pages 53–73 of the Petition.
`Petitioner contends that each element of claims 1–4 is met by Chen ’677.
`For example, to meet the claim limitation “a host processor for transmitting
`transport packets, said transport packets providing a plurality of
`instructions,” Petitioner states:
`Because MPEG streams are stored and sent in the form of
`packetized streams, and because Chen ’677 teaches a receiver
`210 that receives an MPEG stream 10 and extracts data in the
`form of packets from the MPEG stream, and, Chen ’677 teaches
`that the “plurality of instructions” transmitted by a “host
`processor” is stored and sent in a series of “transport packets.”
`Pet. 58. In this analysis, Petitioner relies on a construction of “instructions”
`that would include “the contents of the coded or compressed audio or video
`syntax itself.” Id. at 55. Our construction is similar in this respect.
`Patent Owner responds with two main arguments. First is that
`Chen ’677 does not disclose “instructions” under Petitioner’s “own proposed
`construction.” Prelim. Resp. 5–6. Second is that Chen ’677 does not
`disclose a “host processor.” Id. at 6–7.
`As to the first argument, we have construed “instructions” as not
`necessarily separate from audio or video data. See supra. Accordingly, we
`determine on this record that Chen ’677 meets this limitation, for
`Chen ’677’s data stream contains commands that specify trick play functions
`to be performed. Ex. 1004 ¶ [0027].
`
`16
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`
`According to Patent Owner, Chen ’677’s receiver 210 does not meet
`the requirement of a host processor because it does not process an incoming
`transport stream or extract packets from the stream, as required by
`Petitioner’s “own” construction of the term. Prelim. Resp. 6. As discussed
`supra, Patent Owner is referring here to the construction of “host processor”
`used in its submission to the ITC. See Ex. 1008.
`Consistent with the ’967 patent specification, however, our
`construction of “host processor” does not require processing an incoming
`stream or extracting packets from the stream. See supra. Accordingly, we
`determine on this record that Chen ’677 meets this limitation, for
`Chen ’677’s receiver 210 delivers an incoming transport stream (i.e., a
`stream of packets) which contain instructions for controlling the playback to
`a decoder device.
`
`3. Obviousness of Claim 5 over Chen ’677
`
`Claim 5 reads: “The system of claim 1, wherein the picture comprises
`a P-picture from a HITS stream.” Petitioner contends:
`Given that the streams in Chen ’677 are progressive I-slice
`refreshed MPEG data streams, of which HITS is a type of stream,
`a POSITA would have found it obvious to implement the
`teachings of Chen
`’677 over a HITS stream. Such
`implementation would have been a straightforward substitution.
`Pet. 73 (citing Ex. 1002 ¶ 203). Patent Owner does not challenge this
`assertion. We are persuaded on this record that Petitioner has established a
`reasonable likelihood of prevailing on this challenge.
`
`4. Obviousness of Claims 1–5 over Chen ’677 and ISO 13818-2
` Petitioner presents this ground as an alternative, “[t]o the extent that
`[Patent Owner] argues or the Board finds, before or after institution, that
`Chen ’677 does not disclose one or more of the claimed ‘transport packets’
`
`17
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`(claim 1), or ‘raster order’ (claim 4).” Pet. 74. Petitioner relies on ISO
`13818-2 for these features. Id. at 74–78. As to “transport packets,”
`Petitioner contends:
`A POSITA would have considered “transport packets
`providing a plurality of instructions” obvious in view of the
`combined disclosures of Chen ‘677 and ISO 13818-2. EX-1002
`¶212. Applying the known techniques of ISO 13838 [sic] in
`Chen ‘677 would have yielded predictable results and known
`advantages. EX-1002 ¶212.
`Pet. 76. As to “raster order,” Petitioner contends:
`Having started with ISO 13818-2 when implementing the
`teachings of Chen ’677, based on these disclosures of ISO 13818-
`2, a POSITA would have found it obvious to implement the
`teachings of Chen ’677 so as to decode at least one slice in raster
`order. EX-1002 ¶218. . . . Because ISO 13818-2 explains that
`MPEG data (such as in Chen ’677) is encoded in raster order,
`decoding in raster order would be the most straightforward
`method of decoding. EX-1002 ¶218.
`Pet. 78. Patent Owner does not challenge these assertions. We are
`persuaded by the foregoing that, on this record, Petitioner has established a
`reasonable likelihood of prevailing on this challenge.
`
`III. ORDER
`In consideration of the foregoing, it is hereby:
`ORDERED that the Petition is granted and inter partes review is of
`the ’967 patent is instituted on the following grounds:
`A. Anticipation of claims 1–5 by MacInnis;
`B. Obviousness of claim 4 over MacInnis and ISO 13818-2;
`C. Anticipation of claims 1–4 by Chen ’677;
`D. Obviousness of claim 5 over Chen ’677; and
`E. Obviousness of claims 1–5 over Chen ’677 and ISO 13818-2;
`
`18
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`
`FURTHER ORDERED that inter partes review based on any other
`proposed grounds of unpatentability is not authorized; and
`FURTHER ORDERED that pursuant to 35 U.S.C. § 314(c) and
`37 C.F.R. § 42.4, notice is hereby given of the institution of a trial
`commencing on the entry date of this decision.
`
`
`
`19
`
`
`
`IPR2017-01544
`Patent 7,342,967 B2
`
`PETITIONER
`
`Erika H. Arner
`Joshua Goldberg
`James Stein
`Finnegan, Henderson, Farabow, Garrett & Dunner, L.L.P.
`erika.arner@finnegan.com
`joshua.goldberg@finnegan.com
`james.stein@finnegan.com
`
`
`PATENT OWNER
`
`John M. Caracappa
`Thomas Yebernetsky
`Steptoe & Johnson LLP
`jcaracap@steptoe.com
`tyebernetsky@steptoe.com
`
`
`20
`
`
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
