Trials@uspto.gov
`571-272-7822
`
`
`Paper 14
`Entered: January 6, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`HTC CORPORATION,
`HTC AMERICA, INC.,
`LG ELECTRONICS, INC.,
`SAMSUNG ELECTRONICS CO., LTD., and
`SAMSUNG ELECTRONICS AMERICA, INC.,
`Petitioner,
`
`v.
`
`PARTHENON UNIFIED MEMORY ARCHITECTURE LLC,
`Patent Owner.
`____________
`
`Case IPR2015-01500
`Patent 7,321,368 B2
`____________
`
`
`
`Before JAMES B. ARPIN, MATTHEW R. CLEMENTS, and
`SUSAN L. C. MITCHELL, Administrative Patent Judges.
`
`CLEMENTS, Administrative Patent Judge.
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`
`
`Apple Exhibit 1015
`Page 1 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`
`I.
`INTRODUCTION
`HTC Corporation; HTC America, Inc.; LG Electronics, Inc.; Samsung
`Electronics Co., Ltd.; and Samsung Electronics America, Inc. (collectively,
`“Petitioner”) filed a Petition requesting inter partes review of claims 1–3, 5,
`7, 13–15, 17–21, and 23–25 (“the challenged claims”) of U.S. Patent No.
`7,321,368 B2 (Ex. 1001, “the ’368 patent”). Paper 2 (“Pet.”). Parthenon
`Unified Memory Architecture LLC (“Patent Owner”) filed a Preliminary
`Response. Paper 7 (“Prelim. Resp.”). We review the Petition pursuant to
`35 U.S.C. § 314, which provides that an inter partes review may be
`authorized only if “the information presented in the petition . . . and any
`[preliminary] response . . . shows that there is a reasonable likelihood that
`the petitioner would prevail with respect to at least 1 of the claims
`challenged in the petition.” 35 U.S.C. § 314(a); 37 C.F.R. § 42.4(a). Upon
`consideration of the Petition and the Preliminary Response, we determine
`that the information presented by Petitioner establishes that there is a
`reasonable likelihood that Petitioner would prevail in showing the
`unpatentability of at least one of the challenged claims of the ’368 patent.
`Accordingly, pursuant to 35 U.S.C. § 314, we institute an inter partes review
`of claims 1–3, 5, 7, 13–15, 17–21, and 23–25 of the ’368 patent.
`
`A. Related Proceedings
`The ’368 patent is involved in several cases pending in the Eastern
`District of Texas. Pet. 2–3; Paper 5, 2–3. Petitioner also has filed other
`petitions seeking inter partes review of related patents. Pet. 3.
`
`2
`
`Apple Exhibit 1015
`Page 2 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`
`B. The ’368 patent
`The ’368 patent relates generally “to the field of electronic systems
`having a video and/or audio decompression and/or compression device, and
`is more specifically directed to sharing a memory interface between a video
`and/or audio decompression and/or compression device and another device
`contained in the electronic system.” Ex. 1001, 1:42–47. At the effective
`filing date of the ’368 patent, a conventional decoder included a dedicated
`memory, which represented a significant percentage of the cost of the
`decoder and which went unused most of the time. Id. at 2:28–59, 4:54–5:4,
`Figs. 1a–1c.
`To address these and other concerns, the ’368 patent discloses an
`electronic system in which a first device and a video and/or audio
`decompression and/or compression device are coupled to a shared memory
`through a bus having bandwidth sufficient for the video and/or audio
`decompression and/or compression device to operate in real time. Id. at 5:8–
`18. Figure 2 is reproduced below.
`
`.
`
`3
`
`Apple Exhibit 1015
`Page 3 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`Figure 2 is a block diagram of an electronic system that contains a device
`with a memory interface and an encoder and decoder. Id. at 6:17–19. “First
`device 42 can be a processor, a core logic chipset, a graphics accelerator, or
`any other device that requires access to the memory 50.” Id. at 6:43–46.
`Both first device 42 and decoder/encoder 80 have access to memory 50
`through memory interfaces 72 and 76, respectively, coupled to fast bus 70.
`Id. at 6:41–43, 7:55–56. Fast bus 70 has a bandwidth of at least the
`bandwidth required for decoder/encoder 80 to operate in real time and,
`preferably, has a bandwidth of at least approximately twice the bandwidth
`required for decoder/encoder 80 to operate in real time. Id. at 8:32–38.
`During operation, decoder/encoder 80, first device 42, and refresh
`logic 58, if it is present, request access to memory 50 through arbiter 82. Id.
`at 13:7–10. Arbiter 82 determines which of the devices gets access to
`memory 50. Id. at 13:11–13. Decoder/encoder 80 gets access to memory 50
`in the first time interval, and first device 42 gets access to memory 50 in the
`second time interval. Id. at 13:14–16. Direct Memory Access (DMA)
`engine 52 of decoder/encoder 80 determines the priority of decoder/encoder
`80 for access to memory 50 and the burst length when decoder/encoder 80
`has access to memory 50. Id. at 13:16–20. DMA engine 60 of first device
`42 determines its priority for access to memory 50 and the burst length when
`first device 42 has access to memory 50. Id. at 13:20–23.
`When decoder/encoder 80 or one of the other devices generates a
`request to access memory 50, the request is transferred to arbiter 82, and
`access to memory 50 is determined based on the state of arbiter 82 and on a
`priority scheme. Id. at 13:24–53. The priority scheme can be any scheme
`that ensures decoder/encoder 80 gets access to memory 50 often enough to
`
`4
`
`Apple Exhibit 1015
`Page 4 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`operate properly, but does not starve other devices sharing memory 50. Id.
`at 13:54–58.
`
`C. Illustrative Claim
`Of the challenged claims, claims 1, 5, 7, 13, and 20 are independent.
`Claim 1 is illustrative and is reproduced below:
`1.
`An electronic system comprising:
`a main memory having stored therein data corresponding to
`images to be decoded and also decoded data corresponding to
`images that have previously been decoded;
`a bus coupled to the memory;
`a decoder coupled to the bus for receiving compressed
`images and for outputting data for displaying the decoded images
`on a display device, the decoder receiving data from the main
`memory corresponding to at least one previously decoded image
`and to a current image to be decoded and outputting decoded data
`corresponding to a current image to be displayed, the current
`image being stored in the main memory;
`a microprocessor system coupled to the main memory, the
`microprocessor system storing non-image data in and retrieving
`data from the main memory; and
`an arbiter circuit coupled to both the microprocessor system
`and the decoder for controlling the access to said main memory by
`the decoder and the microprocessor.
`Ex. 1001, 15:57–16:9.
`
`D. Evidence Relied Upon
`Petitioner relies upon the following references:
`Bowes
`US 5,546,547
`Aug. 13, 1996
`International Organization for Standardization, “ISO/IEC
`11172-2: Information technology—Coding of moving pictures
`and associated audio for digital storage media at up to about
`1,5 Mbit/s—Part2: Video,” (1st ed. Aug. 1, 1993) (“MPEG”)
`
`Ex. 1003
`Ex. 1004
`
`5
`
`Apple Exhibit 1015
`Page 5 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`S. Rathnam et al., “An Architectural Overview of the
`Programmable Multimedia Processor, TM-1,” PROC. COMPCON,
`IEEE Computer Society Press, Los Alamitos, CA, 1996,
`pp. 319–326 (1996) (“Rathnam”)
`Stearns
`US 5,774,676
`
`June 30, 1998
`
`Ex. 1005
`
`Ex. 1007
`
`Pet. 5–6. Petitioner also relies upon the Declaration of Harold S. Stone,
`Ph.D. (“Stone Decl.”) (Ex. 1030).
`
`E. Asserted Grounds of Unpatentability
`Petitioner argues that the challenged claims are unpatentable based on
`the following grounds (Pet. 5–6):
`References
`Basis Claims challenged
`Rathnam
`§ 102 1–3, 5, 7, 13–15, 17–21, and 23–25
`Bowes and MPEG
`§ 103 1, 5, 7, 13, 15, 18, 20, 24, and 25
`Bowes, MPEG, and Rathnam § 103 17, 19, and 23
`Bowes, MPEG, and Stearns
`§ 103 2, 3, 14, and 21
`
`
`
`II. ANALYSIS
`
`A. Claim Construction
`Pursuant to 37 C.F.R. § 42.100(b), “[a] claim in an unexpired patent
`shall be given its broadest reasonable construction in light of the
`specification of the patent in which it appears.” Petitioner alleges that the
`’368 patent will expire in September 2016. Pet. 10–11. Patent Owner states
`that the ’368 patent will expire on September 11, 2016. Paper 8. Thus, the
`parties agree that the’368 patent will expire before we are likely to issue a
`final written decision as to the patentability of the challenged claims. Pet.
`11.
`
`In order to determine if Petitioner has demonstrated a reasonable
`likelihood that it will prevail in this proceeding, given the patent’s pending
`
`6
`
`Apple Exhibit 1015
`Page 6 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`expiration, we analyze Petitioner’s arguments through the lens of the claim
`construction standard that will apply to our final written decision. Thus, we
`construe the claims in accordance with the standard set forth in Phillips.1
` 37
`C.F.R. § 42.5(b); see Toyota Motor Corp. v. Cellport Sys., Inc., Case
`IPR2015-00633, slip op. at 8–10 (PTAB Aug. 14, 2015) (Paper 11); cf. In re
`Rambus Inc., 694 F.3d 42, 46 (Fed. Cir. 2012) (“While claims are generally
`given their broadest possible scope during prosecution, the Board’s review
`of the claims of an expired patent is similar to that of a district court’s
`review.”) (internal citation omitted). Petitioner argues that its proposed
`construction will remain the same even if we apply a Phillips-type claim
`construction standard. Pet. 11 (citing Phillips v. AWH Corp., 415 F.3d 1303,
`1314 (Fed. Cir. 2005) (en banc)).
`“In determining the meaning of the disputed claim limitation, we look
`principally to the intrinsic evidence of record, examining the claim language
`itself, the written description, and the prosecution history, if in evidence.”
`DePuy Spine, Inc. v. Medtronic Sofamor Danek, Inc., 469 F.3d 1005, 1014
`(Fed. Cir. 2006) (citing Phillips, 415 F.3d at 1312–17). The words of a
`claim generally are given their ordinary and customary meaning, and that is
`the meaning the term would have to a person of ordinary skill at the time of
`the invention, in the context of the entire patent including the specification.
`See Phillips, 415 F.3d at 1312–13. Claims are not interpreted in a vacuum
`but are a part of and read in light of the specification. See Slimfold Mfg. Co.
`
`
`1 Our construction of the disputed claim term set forth below would have
`been the same had we applied the broadest reasonable interpretation
`standard.
`
`7
`
`Apple Exhibit 1015
`Page 7 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`v. Kinkead Indus., Inc., 810 F.2d 1113, 1116 (Fed. Cir. 1987). Although it is
`improper to read a limitation from the specification into the claims, the
`claims still must be read in view of the specification of which they are a part.
`See Microsoft Corp. v. Multi-Tech Sys., Inc., 357 F.3d 1340, 1347 (Fed. Cir.
`2004).
`Petitioner proposes constructions under a broadest reasonable
`interpretation for “decoder,” “fast bus,” and “decoder directly supplies a
`display device with an image.” Pet. 8–12. For purposes of this decision, we
`determine that only one of those terms requires express construction under a
`Phillips-type construction.
`1. “decoder”
`Independent claims 1, 5, 7, 13, and 20 recite a “decoder.” Petitioner
`proposes to construe the term to mean “hardware and/or software that
`translates data streams into video or audio information.”2 Pet. 8–10 (citing
`Ex. 1001, 2:5–7 (“a video and/or audio decompression device (hereinafter
`‘decoder’)”), 6:66–7:6, 7:2–10, 15:51–54 (“[a]ny conventional decoder
`complying to the MPEG-1, MPEG-2, H.261, or H.261 standards, or any
`combination of them, or any other conventional standard can be used as the
`decoder/encoder.”), 16:63–64, and 17:9–13). Petitioner further relies upon a
`dictionary definition for “decoder” as evidence of the term’s ordinary and
`customary meaning to a person of ordinary skill in the art as of the effective
`filing date of the ’368 patent, in the context of the entire patent including the
`
`
`2 Petitioner proposes this construction as the broadest reasonable
`interpretation (Pet. 8–9), but argues that the construction is the same under a
`Phillips standard (id. at 12–13).
`
`8
`
`Apple Exhibit 1015
`Page 8 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`Specification. Id. at 10 (citing Ex. 1014, 56 (“decoder (n). Any hardware or
`software system that translates data streams into video or audio
`information.”). Patent Owner does not dispute Petitioner’s proposed
`construction at this time.
`The ’368 patent’s definition of “decoder” to mean “a video and/or
`audio decompression device,” and its disclosure that the “decoder/encoder”
`can be any conventional decoder complying to any conventional standard,
`support a construction of “decoder” that encompasses both hardware and
`software. In addition, as Petitioner points out, the ’368 patent describes at
`least audio decoding as being performed in software. Pet. 9 (citing Ex.
`1001, 6:66–7:10). Accordingly, on this record, and for purposes of this
`Decision, we adopt Petitioner’s proposed construction.
`2. Other Claim Terms
`Only terms which are in controversy in this proceeding need to be
`construed, and then only to the extent necessary to resolve the controversy.
`Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir.
`1999). For purposes of this Decision, no other claim terms require express
`construction.
`
`B. Claim 1–3, 5, 7, 13–15, 17–21, and 23–25 —
`Anticipation by Rathnam (Ground A)
`Petitioner argues that claims 1–3, 5, 7, 13–15, 17–21, and 23–25 are
`unpatentable under 35 U.S.C. § 102 as anticipated by Rathnam. Pet. 13–35.
`1. Rathnam (Ex. 1005)
`Rathnam describes a programmable multimedia processor called
`TM-1. Ex. 1005, Title, Abstract. TM-1 has a high performance VLIW-CPU
`core with video and audio peripheral units designed to support popular
`
`9
`
`Apple Exhibit 1015
`Page 9 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`multimedia applications. Id. at Abstract. “TM-1 easily implements popular
`multimedia standards such as MPEG-1 and MPEG-2, but its orientation
`around a powerful general-purpose CPU makes it capable of implementing a
`variety of multimedia algorithms, whether open or proprietary.” Id. at 319.
`Figure 1 of Rathnam is reproduced below.
`
`
`
`Figure 1 shows a block diagram of TM-1. Id. at 320. The CPU and
`peripherals are time-shared and communication between units is through the
`SDRAM memory. Id. at 320–321. “The internal data bus connects all
`internal blocks together and provides access to internal control registers (in
`each on-chip peripheral units), external SDRAM, and the external PCI bus.”
`Id. at 322. “Access to the internal bus is controlled by a central arbiter,
`which has a request line from each potential bus master.” Id.
`In operation, “[t]he CPU can enlist the [Image Coprocessor (ICP)] and
`video-in units to help with some of the straightforward, tedious tasks
`associated with video processing.” Id. at 321. “A typical mode of operation
`
`10
`
`Apple Exhibit 1015
`Page 10 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`for a TM-1 system is to serve as a video-decompression engine on a PCI
`card in a PC.” Id.. “Video decompression begins when the PC operating
`system hands the TM-1 a pointer to compressed video data in the PC’s
`memory . . . .” Id. “The TM-1 CPU fetches data from the compressed video
`stream via the PCI bus, decompresses frames from the video stream, and
`places them into local SDRAM.” Id. “Decompression may be aided by the
`VLD (variable-length decoder) unit, which implements Huffman decoding
`and is controlled by the TM-1 CPU.” Id. “The TM-1 CPU hands the VLD a
`pointer to a Huffman-encoded bit stream, and the VLD produces a tokenized
`bit stream that is very convenient for the TM-1 image decompression
`software to use.” Id. at 324.
`2. Analysis
`In light of the arguments and evidence of record, Petitioner has not
`established a reasonable likelihood that claims 1–3, 5, 7, 13–15, 17–21, and
`23–25 are unpatentable as anticipated by Rathnam.
`Independent claim 1 recites “the decoder receiving data from the main
`memory corresponding to at least one previously decoded image and to a
`current image to be decoded.” Petitioner argues that Rathnam’s “SDRAM
`(i.e., main memory) stores encoded (i.e., compressed) images.” Pet. 16
`(citing Ex. 1005, 321 (discussing video compression)). Petitioner concludes:
`Since Rathnam’s decoder can decode MPEG-1 and MPEG-2
`encoded data, and such encoded data is disclosed to have been
`written to the SDRAM, Rathnam’s decoder must receive data
`(i.e., main memory)
`via
`the bus
`from
`the SDRAM
`corresponding to at least one previously decoded image and to a
`current image to be decoded.”
`Pet. 17.
`
`11
`
`Apple Exhibit 1015
`Page 11 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`
`Patent Owner argues that Rathnam does not disclose a decoder
`configured to receive a video image to be decoded from the main memory.
`Prelim. Resp. 12–20. We agree. We are not persuaded that Rathnam’s
`decoder receives “from the main memory”—i.e., Rathnam’s SDRAM—“a
`current image to be decoded,” as recited by the claim. As Petitioner
`acknowledges (Pet. 17), Rathnam’s decoder receives compressed video
`data—i.e., the recited “current image to be decoded”—from the PCI bus.
`Ex. 1005, 321 (“The TM-1 CPU fetches data from the compressed video
`stream via the PCI bus, decompresses frames from the video stream, and
`places them into local SDRAM.”). Rathnam does not teach that the decoder
`retrieves compressed video data from the SDRAM. Petitioner relies on
`Rathnam’s description of storing compressed data in the SDRAM during
`encoding, but that teaching is not persuasive because it relates to the
`encoder, not to the decoder. Moreover, there is no teaching or suggestion in
`Rathnam that the “decoder” subsequently receives the data stored in
`SDRAM by the encoder. To the contrary, Rathnam teaches that after
`encoding,
`[t]he compressed video data can now be disposed of in any of
`several ways. It can be sent to a host system over the PCI bus
`for archival on local mass storage, or the host can transfer the
`compressed video over a network, such as ISDN. The data can
`also be sent to a remote system using the integrated V.34
`interface to create, for example, a video phone or video
`conferencing system.
`Ex. 1005, 321. Accordingly, on this record, we are not persuaded that the
`Petition establishes a reasonable likelihood that Petitioner would prevail in
`showing that claim 1, or claims 2 and 3, which depend therefrom, are
`anticipated by Rathnam.
`
`12
`
`Apple Exhibit 1015
`Page 12 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`
`Independent claims 5, 7, 13, and 20 recite limitations of
`commensurate scope, and Petitioner relies on its analysis with respect to
`claim 1 for the teachings of these limitations as well. Pet. 21, 26–27, 28,
`32–33. For the same reasons discussed above with respect to claim 1, we
`are not persuaded that the Petition establishes a reasonable likelihood that
`Petitioner would prevail in showing that independent claims 5, 7, 13, and 20,
`or claims 14, 15, 17–19, 21, and 23–25, which depend therefrom, are
`anticipated by Rathnam.
`3. Conclusion
`On this record, we are not persuaded that Petitioner has established a
`reasonable likelihood that it would prevail in showing that claims 1–3, 5, 7,
`13–15, 17–21, and 23–25 are unpatentable under 35 U.S.C. § 102 as
`anticipated by Rathnam.
`
`C. Claims 1, 5, 7, 13, 15, 18, 20, 24, and 25 —
`Obviousness over Bowes and MPEG (Ground B)
`Petitioner argues that claims 1, 5, 7, 13, 15, 18, 20, 24, and 25 are
`unpatentable under 35 U.S.C. § 103(a) as obvious over Rathnam and Artieri.
`Pet. 35–51.
`1. Bowes (Ex. 1003)
`Bowes describes a memory bus arbiter for a computer system having
`a DSP co-processor. Ex. 1003, Title. According to Bowes,
`In prior art computer systems, because of the high bandwidth
`required for real-time processing by a DSP, it has not been
`possible for the DSP to run off of the computer system's DRAM
`in the way the CPU 10 utilizes it without adversely affecting the
`rest of the computer system. Thus, there has been provided a
`large block of SRAM 24 for use by the DSP 20. . . .
`
`13
`
`Apple Exhibit 1015
`Page 13 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`
`A significant disadvantage to the prior art computer
`
`architecture of FIG. 1 is the requirement of a substantial block
`of static random access memory 24. SRAMs are significantly
`more expensive than DRAM which greatly increases the cost of
`computer systems which incorporate SRAM.
`Id. at 2:36–48. Thus, it is an object of Bowes “to provide method for
`arbitrating the memory bus bandwidth to efficiently allow the use of a
`digital signal processor and a CPU over a common memory bus
`sharing the system’s dynamic random access memory subsystem
`without requiring an expensive block static random access.” Id. at
`2:57–63.
`
`Figure 2 of Bowes is reproduced below.
`
`
`Figure 2 illustrates a block diagram of a computer architecture incorporating
`the arbitration scheme described in Bowes. Id. at 3:62–64. “The scheme is
`implemented such that the DSP is provided with sufficient bandwidth to
`perform real-time digital signal processing using the system’s dynamic
`
`14
`
`Apple Exhibit 1015
`Page 14 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`random access memory (DRAM) and not requiring the incorporation of an
`expensive block of static random access memory (SRAM).” Id. at 4:55–60.
`As shown in Figure 2, the system includes CPU 10, memory
`controller and arbiter (MCA) 200, main memory 14, and DSP 20. Id. at Fig.
`2. “Unlike prior art computer systems, the [system of Bowes] provides for
`the DSP 20 to reside on the system’s memory bus and operate from the
`computer systems’ main memory subsystem 14.” Id. at 6:22–26. “[T]his
`greatly reduces system cost by eliminating the need for an expensive block
`of SRAM.” Id. at 6:26–29. In a preferred embodiment, MCA 200 “is an
`application specific integrated circuit (ASIC) for arbitrating the memory bus
`110 between the various bus masters subject to the constraints each imposes
`to provide optimal bandwidth for each, particularly the DSP which is
`responsible for a significant amount of real-time signal processing.” Id. at
`6:46–52.
`2. MPEG (Ex. 1004)
`MPEG describes the coded representation of video for digital storage
`media and specifies the decoding process for the MPEG-2 standard. Ex.
`1004, 1.
`3. Analysis
`In light of the arguments and evidence of record, Petitioner has
`established a reasonable likelihood that claims 1, 5, 7, 13, 15, 18, and 20 are
`unpatentable as obvious over Bowes and MPEG.
`With respect to independent claim 1, for example, we are persuaded
`by Petitioner’s citations that the combination of Bowes and MPEG teaches
`each of the recited limitations. Pet. 35–51. Petitioner contends that a person
`
`15
`
`Apple Exhibit 1015
`Page 15 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`of ordinary skill in the art would have found it obvious to combine Bowes
`and MPEG:
`To the extent Bowes does not explicitly describe transferring
`and processing data in the MPEG format, it would have been
`obvious to combine Bowes with the MPEG Standard (Ex.
`1004), in light of the knowledge of one of ordinary skill in the
`art in 1996, given that the ’368 patent acknowledges that
`MPEG was a “coding standard currently in use.” Ex. 1001 at
`1:60-61. The ’368 patent describes the MPEG standards,
`including MPEG-1 and MPEG-2, as being “well accepted
`standards for one-way communication.” Id. at 2:13-14. Given
`Bowes’ aim to “support a broad range of new multimedia (i.e.,
`voice, video and traditional data) applications,” Ex. 1003 at
`1:32-34, as well as its use of a digital signal processor (DSP 20)
`for “image processing,” id. at 6:33-35, incorporating the known
`MPEG standard into Bowes’ system would yield predictable
`results. Moreover, the MPEG Standard describes a protocol of
`interpolated and predicted image frames resulting in “high
`compression ratio while preserving good picture quality.” Ex.
`1004 at 4 (§ 0.2). Because Bowes acknowledges DSPs “require
`a large amount of bandwidth to memory” for real-time
`processing, Ex. 1003 at 1:51-53, an ordinary artisan would have
`been motivated to combine the MPEG Standard’s highly
`address Bowes’
`efficient
`compression
`to
`bandwidth
`requirement. See Ex. 1030, Stone Decl. at ¶¶ 205-208.
`Id. at 35–36.
`
`Patent Owner argues that Petitioner has not articulated sufficiently a
`reason to combine Bowes and MPEG, and that Bowes is incompatible with
`MPEG. Prelim. Resp. 43–49. Specifically, Patent Owner argues that “the
`available bandwidth for the DSP (20) of Bowes at 2.4 microseconds is
`orders of magnitude less than the required bandwidth for implementing
`encoding/decoding using the MPEG Standard.” Id. at 46. Patent Owner’s
`argument, however, relies on a description in Bowes of “Alternative DSP
`Operation Modes.” Moreover, we are not convinced, based on the current
`
`16
`
`Apple Exhibit 1015
`Page 16 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`record, that the “required bandwidth for implementing encoding/decoding
`using the MPEG Standard” is “orders of magnitude” (Prelim. Resp. 46)
`greater than what is available in Bowes. On the record before us, therefore,
`we are persuaded that Petitioner has provided an articulated reasoning with
`some rational underpinning sufficient to support the legal conclusion of
`obviousness. See KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007)
`(citing In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006)).
`Patent Owner also argues that MPEG was considered during
`prosecution. Prelim. Resp. 33–34. Although we consider the fact that the
`Examiner considered MPEG during prosecution of the application that led to
`the ’368 patent, we are not precluded from considering it as a basis for
`unpatentability in an inter partes review.
`We also are not persuaded by Patent Owner’s argument that the
`proposed combination does not disclose a decoder receiving an image to be
`decoded and a previously decoded image from main memory. Prelim. Resp.
`34–40. Patent Owner argues that Bowes’ “block read” operation relates
`only to instructions, not to image data. Id. at 36–37. Bowes teaches that
`“the DSP will utilize the memory bus 110 [] to read a large block memory
`from the DRAM 14 into its internal SRAM.” Ex. 1003, 7:3–5. It does not
`follow from Bowes’ discussion of whether “code” is divisible into discrete
`blocks for block read operations that such “blocks” may contain only code,
`and not data. Moreover, a “block read” is only one mode of operation
`described in Bowes. Bowes also states that “there may be situations in
`which the DSP requires only a single piece of data from the DRAM. These
`types of read operation[s] are referred to as ‘scattered-single reads.’” Id. at
`
`17
`
`Apple Exhibit 1015
`Page 17 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`7:23–26. We, therefore, are persuaded on this record that Bowes discloses
`reading image data from main memory.
`Patent Owner also argues that the chip of the preferred embodiment—
`an AT&T DSP3210—has an 8K cache, and that image data is read from that
`cache rather than from main memory. Id. at 38–39. This argument is also
`unavailing. Petitioner identifies DSP 20 as the decoder and Bowes explicitly
`describes DSP 20 accessing the DRAM—i.e., the recited “main memory.”
`See, e.g., id. at 7:3–5 (“[T]he DSP will utilize the memory bus 110 [] to read
`a large block memory from the DRAM 14 into its internal SRAM.”). Thus,
`even assuming that the decoder subsequently uses the data in its cache to
`decode an image, it can do so only because it previously received that
`“image to be decoded . . . from main memory.”
`We also are not persuaded by Patent Owner’s argument that the
`proposed combination does not disclose an arbiter that controls access to the
`main memory. Prelim. Resp. 40–42. Patent Owner argues that “MCA (200)
`merely controls access to the memory bus (110) of Bowes, not the
`main/system memory as recited in the claims.” Id. at 40. Patent Owner does
`not explain, however, why controlling access to the memory bus does not, in
`turn, control access to the main/system memory. Specifically, Patent Owner
`asserts that “Bowes’ alleged disclosure of an arbiter that controls access to
`the bus does not teach accessing the main/system memory,” but does not
`explain why. On this record, Patent Owner’s arguments are not persuasive.
`Finally, we also are not persuaded by Patent Owner’s argument with
`respect to claim 5 that the proposed combination does not disclose an
`arbitration circuit that receives signals from the microprocessor. Prelim.
`Resp. 42–43. Patent Owner’s argument relies on Bowes’ teaching that “to
`
`18
`
`Apple Exhibit 1015
`Page 18 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`save a pin on the CPU, the CPU does not utilize the means for requesting the
`memory bus” (id. at 42 (citing Ex. 1003, 3:34–36)), but that description
`relates only to a preferred embodiment. Elsewhere, Bowes discloses that
`MCA 200 receives a request to access memory bus from CPU 10. See, e.g.,
`Ex. 1003, 7:64–8:3, 8:45–56.
`4. Conclusion
`On this record, we are persuaded that Petitioner has established a
`reasonable likelihood that it would prevail in showing that claims 1, 5, 7, 13,
`15, 18, 20, 24, and 25 are unpatentable as obvious over the combination of
`Bowes and MPEG.
`
`D. Claims 17, 19, and 23 — Obviousness over
`Bowes, MPEG, and Rathnam (Ground C)
`Petitioner argues that claims 17, 19, and 23 are unpatentable under
`35 U.S.C. § 103(a) as obvious over Bowes, MPEG, and Rathnam. Pet. 51–
`55.
`1. Analysis
`In light of the arguments and evidence, Petitioner has established a
`reasonable likelihood that claims 17, 19, and 23 are unpatentable as obvious
`over the combination of Bowes, MPEG, and Rathnam.
`We are persuaded by the disclosures in Petitioner’s citations that the
`combination of Bowes, MPEG, and Rathnam teaches each of the recited
`limitations. Pet. 51–55. Petitioner contends that a person of ordinary skill in
`the art would have found it obvious to combine Bowes, MPEG, and
`Rathnam.
`To the extent Patent Owner argues that Bowes does not disclose
`integrating the disclosed components on a single chip, it would
`have been obvious to do so in light of Rathnam (Ex. 1005).
`
`19
`
`Apple Exhibit 1015
`Page 19 of 25
`
`

`
`IPR2015-01500
`Patent 7,321,368 B2
`
`
`Rathnam describes a “single-chip video conferencing solution
`that runs all current video codecs across all common transport
`mechanisms.” Ex. 1005 at 19. Like Bowes, Rathnam’s chip
`“easily implements popular multimedia standards such as
`MPEG-1 and MPEG-2, but its orientation around a powerful
`general-purpose CPU makes it capable of implementing a
`variety of multimedia algorithms, whether open or proprietary.”
`Id. at 12. Rathnam’s single-chip implementation makes it
`appropriate for “low-cost, stand alone systems such as video
`phones to programmable, multipurpose plug-in cards for
`traditional computers.” Id. Rathnam’s chip “can serve as a
`multi-function PC enhancement vehicle.” Id. at 13. Like
`Bowes, Rathnam
`is designed for processing multimedia
`applications, but Rathnam’s chip “far surpasses the capabilities
`of fixed-function multimedia chips.” Id. Like Bowes, Rathnam
`includes “DMA-driven multimedia input/output units that
`operate independently and that properly format data to make
` Id.
` The implementation of the
`processing efficient.”
`components on a single chip, as in Rathnam, rather than as
`disparate and discrete components, as in Bowes, was a well-
`understood design choice. By the mid-1990s, single chip
`integration had been widely adopted and applied in multimedia
`processing chips. See, e.g., Ex. 1006 at 1 (discussing the MVP,
`a video chip from Texas Instruments). In addition to enabling
`small packaging sizes and large-scale low-cost manufacturing,
`chip integration yields shorter interconnects, and thus faster
`Id.
`communications,
`between
`electronic
`components.
`(describing the MVP as providing “single-chip integration
`without slower chip-to-chip communications”). This can lead
`to faster, cheaper, and more capable multimedia processing
`chips. Bow