throbber
Paper No. 32
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`––––––––––––––––––
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`––––––––––––––––––
`
`HTC CORPORATION, HTC AMERICA, INC., and LG ELECTRONICS, INC.,
`Petitioners,
`
`v.
`
`PARTHENON UNIFIED MEMORY ARCHITECTURE LLC,
`Patent Owner.
`
`––––––––––––––––––
`
`Case No. IPR2015-01501
`U.S. Patent No. 7,777,753
`
`––––––––––––––––––
`
`PETITIONERS’ REPLY
`
`
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`Table of Contents
`
`I.
`
`II.
`
`INTRODUCTION ........................................................................................... 1
`
`BOWES AND MPEG SATISFY THE CLAIMS ........................................... 1
`
`A.
`
`B.
`
`C.
`
`D.
`
`The Combined System Includes The Idle State Limitation .................. 1
`
`The Combined System Discloses the Claimed Video Circuit. ............. 3
`
`1.
`
`2.
`
`3.
`
`Bowes Discloses a Video Circuit. ............................................... 3
`
`The Bowes/MPEG Combination Uses Shared Memory ............. 9
`
`Bowes Can Retrieve The Data It Stores. ................................... 13
`
`Bowes and MPEG Disclose the Claimed Arbiter ............................... 14
`
`Reasons To Combine Bowes And MPEG ........................................... 17
`
`III. CERTAIN DEPENDENT CLAIMS ............................................................. 23
`
`IV. CONCLUSION .............................................................................................. 23
`
`
`
`
`
`
`
`i
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`Exhibit List
`
`1005
`[NEW]
`
`1006
`
`1007
`1008
`1009
`
`Exhibit # Reference Name
`1001
`U.S. Patent No. 7,777,753 (“the ’753 patent”)
`1002
`File History for U.S. Patent No. 7,777,753
`1003
`U. S. Patent No. 5,546,547 (“Bowes”)
`1004
`ISO/IEC 11172-2:1993: Information technology—Coding of moving
`pictures and associated audio for digital storage media at up to about
`1,5 Mbit/s—Part 2: Video,” (1st ed. August 1, 1993) (“MPEG
`Standard”)
`S. Rathnam et al., “An Architectural Overview of the Programmable
`Multimedia Processor, TM-1,” IEEE Proceedings of COMPCON ’96,
`pp. 319-326 (1996) (“Rathnam”)
`R.J. Gove, “The MVP: A Highly-Integrated Video Compression
`Chip,” Proceedings of the IEEE Data Compression Conference (DCC
`‘94), pp. 215-224 (March 29-31, 1994) (“Gove”)
`U.S. Patent No. 5,774,676 (“Stearns”)
`Declaration of Dr. Santhana Chari (“Chari Decl.”)
`International Organization for Standardization, Website of ISO/IEC
`11172-2
`WorldCat Entry for Rathnam
`
`1010
`[NEW]
`1011
`1012
`1013
`1014
`1015
`1016
`1017
`1018
`1019
`
`RESERVED
`RESERVED
`RESERVED
`Brad Hansen, The Dictionary of Multimedia, 1997
`RESERVED
`RESERVED
`U.S. Patent No. 5,748,983 (“Gulick 983”)
`WO 96/11440, PCT/US95/12933, Shared Memory System (“Whai”)
`Shanley, et al., “PCI System Architecture,” Addison-Wesley
`Publishing Company, 1995 (3rd ed.) (“Shanley”)
`ii
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`1021
`1022
`1023
`1024
`
`1025
`
`Exhibit # Reference Name
`1020
`Stone, H., “Microcomputer Interfacing,” Addison-Wesley Publishing
`Company, 1982
`RESERVED
`RESERVED
`U.S. Patent No. 5,797,028 (“Gulick 028”)
`“Accelerated Graphics Port Interface Specification,” Intel
`Corporation, July 31, 1996 (Revision 1.0) (“AGP”)
`VESA Unified Memory Architecture Hardware Specifications
`Proposal,” Version 1.0p (“VUMA”)
`RESERVED
`RESERVED
`U.S. Patent No. 5,432,900 (“Rhodes”)
`
`1026
`1027
`1028
`[NEW]
`1029
`1030
`1031
`1032
`[NEW]
`1033
`[NEW]
`1034
`[NEW]
`1035
`[NEW]
`1036
`[NEW]
`
`1037
`[NEW]
`1038
`[NEW]
`
`Curriculum Vitae of Dr. Harold Stone
`Expert Declaration of Dr. Harold Stone (“Stone ’753 Decl.”)
`Settlement Agreement
`Reply Declaration of Dr. Harold Stone (“Stone Reply Decl.”)
`
`U.S. Patent No. 5,682,484 (“Lambrecht ’484”)
`
`U.S. Patent No. 5,375,068 (“Palmer”)
`
`U.S. Patent No. 5,557,538 (“Retter”)
`
`K. Konstantinides and V. Bhaskaran, “Recent Developements in the
`Design ofImage and Video Processing ICs,” Chapter 2 - VLSI Signal
`Processing Technololgy, Kluwer Academic Press, 1994
`Deposition Transcript of Dr. Mitchell A. Thornton, Ph.D. (June 17,
`2016)
`Information technology – Generic Coding of Moving Pictures and
`Associated Audio Information: Systems, ISO/IEC 13818-1:1996,
`iii
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`1039
`[NEW]
`
`Exhibit # Reference Name
`ITU-T Rec. H.222.0 (1996) (“MPEG-2 Standard”)
`Srinath V. Ramaswamy and Gerald D. Miller, “Efficient
`Implementation of the Two Dimensional Discrete Cosine Transform
`for Image Coding applications on the DSP96002 Processor,” Proc. of
`the Midwest Conf. on Circuits and Systems, (IEEE 1993)
`U.S. Patent No. 6,081,750 (“Hoffberg”)
`
`1040
`[NEW]
`1041
`[NEW]
`1042
`[NEW]
`1043
`[NEW]
`
`U.S. Patent No. 5,495,481 (“Duckwall”)
`
`Microsoft Press Computer Dictionary (3d Ed. 1997)
`
`Curriculum Vitae of Dr. Harold Stone (Revised)
`
`iv
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`I.
`
`INTRODUCTION
`
`The Petition demonstrated it would have been obvious to combine the video
`
`decoding techniques of the MPEG-1 Standard with the system of Bowes and that
`
`such a combined system satisfied the claims, including the requirement that a
`
`decoder receive image data from the main memory. Pet. at 38-49; Ex. 1030 at
`
`¶¶153-179. As Dr. Stone explained, “a person having ordinary skill in the art
`
`would have understood that Bowes’ DSP 20, as modified by MPEG Standard,
`
`would be configured to receive data from main memory subsystem 14
`
`corresponding to a current video image to be MPEG-video decoded and to output
`
`video data corresponding to the current video image to be displayed via video
`
`controllers 131, the current video image to be displayed adapted to be stored in
`
`main memory subsystem 14.” Ex. 1030 at ¶163. Patent Owner’s formal response
`
`presents nothing to overcome this showing. The claims at issue should therefore
`
`be held unpatentable.
`
`II. BOWES AND MPEG SATISFY THE CLAIMS
`
`A. The Combined System Includes The Idle State Limitation
`
`Claim 1 of the ‘753 Patent requires “an arbiter circuit … configured … to
`
`control access to the main memory by: providing access to the main memory for a
`
`request for access to the main memory when the arbiter circuit is in an idle state
`
`1
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`…”. Patent Owner asserts the Bowes/MPEG combination does not satisfy this
`
`claim element because Bowes does not disclose an “idle state.” Resp. at 3-5.
`
`Patent Owner has never asked for a construction of “idle state,” so it must be
`
`given its customary meaning to a person of ordinary skill in the art. See Microsoft
`
`Corp. v. Proxyconn, Inc., 789 F.3d 1292, 1297 (Fed. Cir. 2015). Such a person
`
`would understand “idle state,” in the context of the 753 Patent, to mean a state in
`
`which no component is accessing the memory, or requesting access to the memory.
`
`See, e.g., Ex. 1001 at 13:4-6 (“The first state is idle when there is no device
`
`accessing the memory and there are no requests to access the memory.”); see also
`
`Microsoft Press Computer Dictionary (3d Ed. 1997) (Ex. 1042) (“idle state … n.
`
`The condition in which a device is operating but is not being used.”); U.S. Patent
`
`No. 5,495,481 at 2:59-61 (Ex. 1041) (“All inactive nodes stay in the idle state A0
`
`until the occurrence of an internal or external event.”); Ex. 1032 (Dr. Stone: “[A]n
`
`idle state” is, e.g., “when no requests are pending.”).
`
`Bowes discloses exactly such a state. In particular, Bowes discloses an
`
`arbitration scheme in which, whenever the non-CPU components of the system are
`
`not accessing the memory, or requesting access to the memory “the state of the
`
`memory bus assignment defaults to the CPU and remains parked on the CPU until
`
`other resources request the memory bus.” Ex. 1001 at 8:30-33; Ex. 1032 at ¶90.
`
`Of course, in such a state where the CPU is also not accessing the memory, no
`
`2
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`component would be accessing the memory, or requesting access to the memory.
`
`Ex. 1032 at ¶¶91-93.
`
`Patent Owner’s mistake is to assume that the system is not idle because the
`
`“assignment” of the bus defaults to the CPU, but never explains why a system
`
`cannot be in a default state that is idle. Moreover, Patent Owner’s argument is
`
`based on its expert’s opinions that the arbiter of Bowes monopolizes the bus,
`
`employs a statically fixed priority schedule, and “allows a device to control the bus
`
`for a '’time slice’ period.” Resp. at 4-5. All of these assertions are irrelevant, since
`
`the claim language does not preclude any of them, but also erroneous, as Dr. Stone
`
`explains. Ex. 1032 at ¶¶90-93. Moreover, these characterizations of Bowes’
`
`disclosure are flawed for the reasons explained below with respect to Patent
`
`Owner’s obviousness arguments. See infra § II.D; Ex. 1032 at ¶¶ 75-82.
`
`B.
`
`The Combined System Discloses the Claimed Video Circuit.
`
`1.
`
`Bowes Discloses a Video Circuit.
`
`Patent Owner asserts that the DSP 20 disclosed in Bowes is not a “video
`
`circuit” as claimed, Resp. at 11-19, that Bowes “does not state that the DSP is
`
`suitable for video compression and decompression,” id. at 11, and that “a POSA
`
`would recognize that a DSP used for image processing is not suitable for video
`
`compression and decompression,” id. at 12.
`
`3
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`However, the Board’s interpretation of the claimed “decoder” is “hardware
`
`and/or software that translates data streams into video or audio information.”
`
`Paper 14 at 10-11. “Suitability” for decompression is not part of that
`
`interpretation, and neither Patent Owner nor its expert dispute that the prior art
`
`included “off the shelf” DSPs capable of video compression and decompression
`
`pursuant to the MPEG Standard or that a skilled artisan could have implemented
`
`the Bowes/MPEG combination using such prior art DSPs. Ex. 1032 (Reply Dec. of
`
`Dr. Stone) at ¶¶8-10; see, e.g., Ex. 1006 at Fig. 1; Ex. 2008 at 2; Ex. 1039 at 25.
`
`Indeed, at least one commercially available prior art DSP specifically
`
`designed for decompressing MPEG video data was the Texas Instruments MVP.
`
`See Robert J. Gove, “The MVP: A Highly-Integrated Video Compression Chip,”
`
`DCC ’94, Data Compression Conference, Mar. 29-31, 1994, pp. 215-224 (Ex.
`
`1006); Ex. 1032 at ¶10. Thus, the skilled artisan implementing the combination of
`
`Bowes and MPEG could have simply purchased a suitable DSP “off the shelf,” and
`
`would have known to do so. Ex. 1032 at ¶10; see, e.g., U.S. Patent No. 6,081,750
`
`(Ex. 1040) at 66:41-49 (filed in June 1995 and noting that a board containing the
`
`MVP chip “is available from General Imaging Corp., Billerica Mass….[and] …
`
`also available from Wintriss Engineering Corp., San Diego, Calif.”).
`
`Bowes, moreover, is directed to a system for carrying out various types of
`
`real-time digital signal processing, including “compressed audio (both high fidelity
`
`4
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`audio and speed), high resolution still images, [and] video ….” Ex. 1003 at 1:35-
`
`37. And Bowes states that such technologies “will allow for collaboration at a
`
`distance such as by video conferencing,” id. at 1:39-41, which a person of skill
`
`would understand to require the translation, including decompression, of data
`
`streams into video and audio, Ex. 1032 at ¶¶5-7.
`
`Bowes also explains that “[e]ach of these aspects of real-time information
`
`processing may require dedicated processors designed for their implementation.
`
`However, it is becoming more and more common to use programmable digital
`
`signal processors (DSP) available on the market today.” Ex. 1003 at 1:42-43.
`
`Bowes then explains the DSP 20 used with his invention “may be an off-the-shelf
`
`DSP such as the AT&T® DSP3210.” Id. at 2:21-22 (emphasis added). Thus, the
`
`DSP of Bowes is not limited to an audio or image decoder, but is an “off the shelf”
`
`DSP capable of decoding various types of data, including audio and video data
`
`used for video conferencing, and intended to be used in a technological context
`
`requiring the decompression of video data. Ex. 1032 at ¶¶4-7. Such a device
`
`clearly satisfies the claimed “video circuit” and the Board’s interpretation of
`
`“decoder.”
`
`Patent Owner seeks to avoid these facts by focusing instead on the specific
`
`chip Bowes discloses as used in his “preferred embodiment implementation,” the
`
`AT&T DSP3210. See Ex. 1003 at 6:28-30; Resp. at 11-18. But the obviousness
`
`5
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`combination advanced in the Petition and on which the Board instituted trial is not
`
`limited to the preferred embodiment of Bowes, but rather relied on the more
`
`general description in Bowes of a generic processor referred to as “DSP 20,” see
`
`Pet. at 38-40, a fact the Board recognized in its Institution Decision, Paper 14 at 18
`
`(noting, in response to Patent Owner’s preferred embodiment argument, that
`
`“Petitioner identifies DSP 20 as the decoder …”). Indeed, Bowes explicitly
`
`contemplates using DSPs other than DSP3210. Ex. 1003 at 6:40-44 (“[Bowes’
`
`system design] provides for flexibility as newer technology and faster DSPs are
`
`developed.”).
`
`Moreover, Patent Owner cites no evidence that the DSP3210 could not be
`
`used in the system of Bowes to decode MPEG-1 video and the undisputed evidence
`
`on this record is that it could. For example, Dr. Stone testifies that “the DSP3210
`
`is a high performance computation engine, suitable for numerically intensive
`
`algorithms like those required to decode MPEG,” that the internal circuitry of the
`
`chip “yield[s] 33.4 MFLOP performance” based on “fast conversion between
`
`floating-point and fixed-point representations” and “is therefore perfectly suitable
`
`for decoding MPEG-1 data streams.” Ex. 1032 at ¶¶18-19.
`
`Patent Owner’s expert, Dr. Thornton, never testified otherwise. Rather,
`
`while Dr. Thornton testified that he thought the DSP3210 was not “suitable” or
`
`“appropriate,” see, e.g., Ex. 2009 at ¶49, he pointedly refused to testify that it did
`
`6
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`not satisfy the Board’s interpretation of “decoder” or that it could not be used to
`
`decode MPEG video:
`
`Q. … Your position is that the DSP disclosed in Bowes is an image
`processor, not a video processor, right?
`
`A. I never said that.
`
`*
`
`
`
`*
`
`
`
`*
`
`You said: It's not appropriate for that because of its architecture.
`
`A. Right.
`
`Q. But that's different from saying: No, it could not be a video MPEG
`decoder. Right? That is a different statement?
`
`A. Yes, that's a different statement.
`
`Ex. 1037 at 66:5-12; 67:8-14; 69:2-8 (emphasis added). Thus, the undisputed
`
`record before the Board is that the DSP3210 could be used to decode MPEG-1
`
`video in the cited combination.
`
`Patent Owner does assert, based on the testimony of its expert, that the
`
`DSP3210 would not be “suitable” for MPEG decoding because it has a floating
`
`point capability and because its fixed point core would supposedly be too slow to
`
`decode MPEG data. Resp. at 13-16; Ex. 2009 at ¶54. As Petitioners’ expert
`
`explains, however, “there are several errors” in Dr. Thornton’s analysis, including
`
`(1) focusing on a supposed processing requirement for MPEG-2 even though the
`
`Board instituted trial on Bowes in view of MPEG-1 (a standard requiring a much
`
`7
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`lower maximum data rate), Ex. 1032 at ¶21(b); (2) relying on a data rate (524
`
`MIPS) inconsistent with the document from which it comes and completely
`
`missing from the citation provided to support it, id. at ¶21(a) & (c); (3)
`
`understating the capabilities of the DSP3210 by at least 100%, id. at ¶21(f); and (4)
`
`ignoring that the processing requirements for converting MPEG data to fixed-point
`
`format are “comparable” to the processing requirements for converting MPEG data
`
`to floating-point format, id. at ¶¶12-17. As Dr. Stone further explains, a skilled
`
`artisan would reasonably have expected the DSP3210 to adequately decode
`
`MPEG1 data based on Prof. Thornton’s own exhibits. Id. at ¶¶22-23.
`
`Finally, Patent Owner contends that its assertions are confirmed because
`
`Apple once produced a product that employed the DSP3210, but used some other
`
`chip for decoding video. Resp. at 17-19. However, Patent Owner cites no
`
`evidence the Apple Quandra was intended to decode MPEG video, and the
`
`document Patent Owner cites demonstrates that Apple did contemplate that the
`
`DSP3210 used in that product would decompress video. Ex. 2005 at 82; Ex. 1032
`
`at ¶¶22-23.
`
`But Patent Owner’s assertions regarding the DSP3210 are beside the point.
`
`As demonstrated above, the obviousness combination at issue is not limited to the
`
`DSP3210, and there is no question that prior art “off the shelf” devices could
`
`decode MPEG-1, such as the prior art Texas Instruments MVP chip, which was
`
`8
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`specifically designed for decoding MPEG video, Ex. 1006, and the HP chip
`
`identified by Prof. Thornton, Ex. 2008. See Ex. 1032 at ¶¶10-11.
`
`2.
`
`The Bowes/MPEG Combination Uses Shared Memory
`
`Patent Owner next argues that even if one would have combined MPEG
`
`with the system of Bowes, a person of ordinary skill in the art would not have
`
`stored previously decoded images in the main memory of Bowes, but instead
`
`would have stored them in the 8K cache memory of the Bowes’ preferred
`
`embodiment chip, the AT&T DSP3210. Resp. at 19. Patent Owner then points out
`
`that the “8K SRAM cache [] is insufficient to store a previously decoded image
`
`frame, [so] if a POSA were to combine Bowes with the MPEG Standard, he would
`
`have used a larger dedicated memory with sufficient space to store an image frame
`
`and the DSP would retrieve the previously decoded image from this dedicated
`
`memory.” Resp. at 20 (emphasis added).
`
`But the obviousness combination on which the Board instituted trial is not
`
`limited to the preferred embodiment DSP3210 disclosed in Bowes, so Patent
`
`Owner’s arguments, limited as they are to a fictional modification of the DSP3210,
`
`do not address that combination. Patent Owner is not entitled to change the
`
`obviousness combination on which the Board instituted trial. The system of Bowes
`
`was specifically designed so that his DSP used the main memory for real time
`
`digital signal processing, such as for decoding video data. Ex. 1003 at 4:55-64;
`
`9
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`6:58-62. This was the system, combined with the MPEG standard, that was the
`
`basis for the Board’s institution of trial and against which Patent Owner was
`
`required to argue the patentability of its claims. Its arguments directed to some
`
`other system are irrelevant.
`
`In any event, a skilled artisan would not have modified Bowes as Patent
`
`Owner argues, and Patent Owner cites no evidence to the contrary. For example,
`
`Patent Owner cites the testimony of Petitioner’s expert Dr. Stone (Resp. at 20), but
`
`in the cited passages Dr. Stone opines that a skilled artisan would not use a cache
`
`memory to hold image data as Patent Owner contends, no matter how large,
`
`because such a system would “not guarantee that you could retrieve it” (Ex. 2006
`
`at 159:22-23) and that even if one did the image data “will also be backed up to
`
`main memory,” (id. at 163:22-23). Dr. Stone confirms Patent Owner’s error, and
`
`explains that “[s]uch a modification of Bowes in that situation would be entirely
`
`unreasonable and impractical for several reasons.” Ex. 1032 at ¶¶24-28.
`
`Patent Owner cites testimony from its expert Prof. Thornton to putatively
`
`support its point, but the cited passage merely parrots Patent Owner’s own
`
`response, word-for-word, and cites only the same testimony by Dr. Stone in
`
`support. Compare Ex. 2009 at ¶60 with Resp. at 20. Prof. Thornton’s ipse dixit
`
`opinion, citing only testimony that contradicts that opinion, cannot support the
`
`Board’s fact-finding and should be given little, if any, weight. Cadiocom, LLC v.
`
`10
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`Robert Bosch Healthcare Sys., Inc., IPR2013-00451, Paper 65 at 28-29 (Jan. 15,
`
`2015); 37 C.F.R. § 42.65(a).
`
`And there were good reasons why a skilled artisan would not modify Bowes
`
`as Patent Owner contends. For example, the cache memory of the DSP3210 is on
`
`the same silicon as the chip’s other circuitry, Ex. 2006 (Stone Dep. Tr.) at 149:5-6;
`
`Ex. 2001 at 2-2 (Figure 2-1: “On-chip RAM used for kernel storage and
`
`program/data cache”), the cache would have to be made several orders of
`
`magnitude larger to accomplish what Patent Owner suggests, Ex. 1032 at ¶26
`
`(“The sheer complexity and expense of such a redesign, including finding
`
`sufficient space on the DSP die to hold such a massive cache, would be
`
`prohibitive. A person of ordinary skill in the art would not even consider it.”), and
`
`the whole point of the Bowes invention is to use the main memory, Ex. 1003 at
`
`4:55-64; 6:58-62; Ex. 1032 at ¶ 27 (citing Ex. 1003 at 2:52-63, 4:49-60). Patent
`
`Owner’s argument therefore rests on the implausible assertion that a skilled artisan
`
`would have redesigned the entire DSP3210 chip — without any attempt to explain
`
`what would motivate such a massive expense and effort, or how one could even
`
`find space on the chip for such additional cache memory — when the alternative
`
`would be to do exactly what Bowes already says should be done and for which he
`
`specifically designed his system: use the main memory.
`
`11
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`Indeed, Patent Owner’s theory is based on the erroneous analysis of its
`
`expert, Prof. Thornton, which concludes that the Bowes DSP 20 includes its own
`
`local RAM (it doesn’t; he was looking at the wrong figure, Ex. 1032 at ¶¶33-35),
`
`and must have an unmentioned larger memory for bus synchronization purposes
`
`and into which it would have stored decoded video frames (it doesn’t, and, even if
`
`it did, it need only store a small multiple of the bus width, Ex. 1032 at ¶¶36-41).
`
`Moreover, as Dr. Stone explained, one would not use a cache memory alone
`
`— of any size — as the only storage for previously decoded MPEG images
`
`because one could not be sure the images would remain in the cache until needed,
`
`since the cache is also used for other types of data. Ex. 2006 (Stone Dep. Tr.) at
`
`158:5-159:23. As Dr. Stone explains:
`
`One could enlarge the cache in the AT&T DSP3210, but could not
`reliably store image data in that cache without also storing it in main
`memory and retrieving it from main memory when necessary. My
`deposition testimony was that if you stored the data in the DSP cache,
`you could not reliably retrieve it from the cache because it could have
`been evicted from the cache when you attempted to retrieve it at a
`later time. Accessing another copy in main memory would be
`necessary.
`
`Ex. 1032 at ¶32. Thus, the claims would still be satisfied even if the preferred
`
`embodiment DSP of Bowes were modified as Patent Owner suggests, since the
`
`12
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`ability to access image data in main memory would necessarily have been part of
`
`such a modified system.
`
`3.
`
`Bowes Can Retrieve The Data It Stores.
`
`Patent Owner also argues that the Bowes DSP can not retrieve from main
`
`memory the same data that it stores to main memory. Resp. at 24-26. This
`
`extraordinary interpretation of the Bowes DSP — that it is not capable of retrieving
`
`data that it had previously written into memory — is based on a single passage in
`
`Bowes which describes how a “block write mode” can be used to store data into
`
`main memory “so that some other parts of the computer system can utilize it.”
`
`Resp. at 25. But the cited sentence actually says that “[i]n many cases it will be
`
`necessary to push that data back out to the DRAM so that some other parts of the
`
`computer system can utilize it,” and that the block write mode could be used for
`
`that purpose. Ex. 1003 at 7:6-12 (emphasis added). Thus, Bowes does not state
`
`that his DSP cannot retrieve data it previously wrote to main memory, but instead
`
`merely states that the bock write mode can be used “in many cases” where data
`
`needs to be written to main memory so other parts of the system can use it. Id.; see
`
`Ex. 1032 at ¶¶ 43-44.
`
`Patent Owner also argues that Petitioner has not identified any portion of the
`
`MPEG Standard that discloses reading image data from memory. Resp. at 26. But
`
`the MPEG Standard discloses that previously decoded images must be used to
`
`13
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`decode at least some video images consistent with the MPEG standard, Ex. 1004 at
`
`8, 42-48, 66-67; Fig. 4, and the Petition demonstrated that Bowes discloses a DSP
`
`20 that will access main memory as needed to carry out real time signal processing,
`
`such as the processing required for video conferencing, Pet. at 40-42. To a person
`
`of ordinary skill in the art, the combination therefore discloses a video decoder that
`
`writes and reads image data to and from main memory in order to decompress
`
`video images pursuant to MPEG. Pet. at 41-42; Ex. 1030 at ¶¶157-163; Ex. 1032
`
`at ¶¶ 43-44. That is sufficient to show obviousness, as the Board recognized in its
`
`Institution Decision. Paper 12 at 25-28; see also KSR Int’l Co. v. Teleflex Inc., 550
`
`U.S. 398, 418 (2007), (“As our precedents make clear, however, the analysis need
`
`not seek out precise teachings directed to the specific subject matter of the
`
`challenged claim …”).
`
`C. Bowes and MPEG Disclose the Claimed Arbiter
`
`Patent Owner next argues that “[i]ndependent claim 1 recites an arbiter
`
`circuit configured to control access to the main memory …” and that the “memory
`
`controller and arbiter (MCA) 200” of Bowes does not control access to memory.
`
`Resp. at 26-32. According to Patent Owner, the MCA of Bowes instead controls
`
`access to the memory bus. Id.
`
`But the Petition demonstrated that the “memory controller and arbiter
`
`(MCA) 200” of Bowes controls access to the memory by controlling access to the
`
`14
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`bus, Pet. at 43-44; Ex. 1030 at ¶¶166-167; Ex. 1003 at 5:28-29, 6:45-54, 9:64-65,
`
`10:2-8, and claim 1 does not recite how access to the memory is controlled, so any
`
`technique of controlling access to the memory would satisfy that claim language.
`
`Indeed, the Board rejected Patent Owner’s argument in the Institution Decision,
`
`noting that “Patent Owner does not explain, however, why controlling access to the
`
`memory bus does not, in turn, control access to the main/system memory,” Paper
`
`12 at 26, and Patent Owner provides no further explanation on this point in its
`
`formal response.
`
`Moreover, Patent Owner has never requested a narrowing interpretation of
`
`this claim language; nor could it consistent with the specification. As Dr. Stone
`
`explains, the arbiter disclosed in the specification controls access to memory by
`
`controlling access to the bus. Ex. 1032 at ¶¶46-51, 54-61. This is confirmed by,
`
`for example, claim 7 of the related 368 Patent, which requires “an arbiter circuit …
`
`for controlling access to the bus,” IPR2015-01500, Ex. 1001 at 17:9-11 (emphasis
`
`added), and which the Board must assume is supported by the only arbiter
`
`disclosed in the patent. Ex. 1032 at ¶¶63-69. Thus, just as in Bowes, the way the
`
`arbiter disclosed in the specification controls access to the memory is by
`
`controlling access to the memory bus. Even under Phillips, the claims must be
`
`construed broadly enough to cover that functionality. Phillips v. AWH
`
`Corporation, 415 F.3d 1303, 1313 (Fed. Cir. 2005) (“Importantly, the person of
`
`15
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`ordinary skill in the art is deemed to read the claim term not only in the context of
`
`the particular claim in which the disputed term appears, but in the context of the
`
`entire patent, including the specification.”).
`
`Patent Owner also argues that in Bowes “a device can be allowed to access
`
`the peripheral bus without being granted access to the main memory.” Resp. at 28.
`
`But controlling access to the memory bus is still one way to control access to the
`
`memory, even if the bus may be used for non-memory accessing operations as
`
`well. Indeed, as Dr. Stone explains, the specification describes that the bus is also
`
`used for non-memory accesses, Ex. 1032 at ¶48 (citing Ex. 1001 at 12:13-14), so
`
`the claims cannot be fairly read to distinguish such a system. Vitronics Corp. v.
`
`Conceptronic, Inc., 90 F.3d 1576, 1583 (Fed. Cir. 1996) (a claim interpretation that
`
`excludes a preferred embodiment “is rarely, if ever, correct”).
`
`Patent Owner also asserts that the MCA of Bowes grants access to bus
`
`cycles, not to memory requests, Resp. at 28-29, but the claims recite neither. All
`
`that is required is an arbiter for controlling access to the memory, and whether that
`
`is accomplished by granting access to bus cycles or memory requests is beside the
`
`point.
`
`Finally, Patent Owner argues that granting access to memory is supposedly
`
`more efficient than granting access to a bus, Resp. at 29-31, but that also is
`
`irrelevant, even if one were to incorrectly accept it as a distinction from Bowes.
`
`16
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`The claims recite an arbiter for controlling access to the memory—they do not
`
`require that such controlling be carried out in any particular manner.
`
`D. Reasons To Combine Bowes And MPEG
`
`The Petition demonstrated it would have been obvious to combine Bowes
`
`and MPEG because to do would have been the use of known techniques to achieve
`
`predictable results, and also because there was a “‘growing need for a common
`
`format representing compressed video on various digital storage media,’ which
`
`would have motivated on[e] skilled in the art to modify” Bowes to “perform MPEG
`
`video decoding.” Pet at 41-42. Patent Owner does not dispute these two reasons to
`
`combine included in the Petition. See Resp. at 32-41.
`
`Rather, Patent Owner asserts that “the DSP of Bowes is not suitable for
`
`video decoding,” citing its earlier argument. Resp. at 33. However, as
`
`demonstrated above, Patent Owner’s suitability arguments are focused solely on
`
`the preferred embodiment DSP3210 of Bowes, not on the more general “DSP 20”
`
`on which trial was instituted, the prior art included other DSPs capable of decoding
`
`MPEG video, and the DSP3210 was also capable of performing that function. See
`
`supra § II.B.1; Ex. 1032 at ¶¶8-23.
`
`Patent Owner also argues that “[a] POSA would not deem using shared
`
`memory between a decoder and another device as being advantageous,” Resp. at
`
`32-34, citing its expert’s unsupported assertion relating to “power consumption and
`
`17
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`space saving benefits,” Ex. 2009 at ¶77. Patent Owner is mistaken. Whether
`
`“using shared memory between a decoder and another device [is] advantageous” is
`
`irrelevant, since Bowes already discloses that functionality. See, e.g., Ex. 1003 at
`
`2:50-64; 6:22-26. The issue here is whether there was a reason to combine Bowes
`
`and MPEG, which the Petition demonstrated and Patent Owner does not dispute,
`
`not whether there was a reason to combine Bowes, MPEG and shared memory.
`
`In any event, Bowes discloses that the advantage obtained from using shared
`
`memory is avoiding the cost of adding “an expensive block of static random access
`
`memory (SRAM)” which “greatly reduces the cost of computer systems.” Ex.
`
`1003 at 4:55-64; see also Ex. 1032 at ¶¶72-74. Neither Patent Owner nor its expert
`
`dispute this advantage to the use of shared memory.
`
`Patent Owner also asserts, block citing seven full pages of testimony, that
`
`“Dr. Stone testified, at the time of the filing of the ’753 Patent, a POSA would not
`
`have concluded that using a shared memory for video decoding is advantageous as
`
`compared to using a dedicated memory.” Resp. at 34. The cited Stone testimony
`
`says nothing of the sort. Rather, Dr. Stone explained that a skilled artisan would
`
`consider many factors when deciding to use a shared memory and that counsel’s
`
`incomplete hypotheticals did not provide enough information to give definitive
`
`answers to those questions. See Ex. 2006, 134:23-141:22; see also Ex. 1032 at
`
`¶¶31-32. The testimony is irrelevant, in any event, since the question is whether to
`
`18
`
`

`
`IPR2015-01501
`
`
`
`Petitioners’ Reply
`
`combine Bowes and MPEG, not whether to combine Bowes and a sha

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket