`
`Paper No.
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_____________________
`
`
`
`
`
`APPLE INC., HTC CORPORATION, AND HTC AMERICA INC.,
`Petitioners,
`
`v.
`
`PARTHENON UNIFIED MEMORY ARCHITECTURE LLC,
`Patent Owner
`
`_____________________
`
`
`
`Case IPR2016-00924
`Patent No. 5,960,464
`
`_____________________
`
`
`
`PETITIONER’S REPLY
`
`
`
`

`

`
`
`
`
`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`
`
`
`
`
`TABLE OF CONTENTS
`
`I.
`
`II.
`
`Introduction ...................................................................................................... 1
`
`Notarianni anticipates each and every limitation recited in
`claims 1, 3, 4, 8-10, 12, 13, 16-21, 23, 24, 32, 33, 35, 36, and
`40. .................................................................................................................... 2
`
`A. Notarianni discloses a control circuit “configured to
`request continuous use of several portions of the main
`memory from the operating system” as recited in claims
`1, 10, 19, and 32. ................................................................................... 2
`
`1.
`
`2.
`
`Notarianni teaches a “request for continuous use”
`as recited in the claim. ................................................................ 2
`
`Patent Owner seeks to improperly import a “static
`allocation” requirement into the claim limitation. ...................... 3
`
`B.
`
`Notarianni discloses a control circuit “configured to
`translate the noncontiguous addresses to contiguous
`addresses of a block of memory.” ......................................................... 8
`
`1.
`
`2.
`
`Notarianni’s linked list implementation teaches the
`express claim language. .............................................................. 9
`
`to
`the noncontiguous address
`The “translate
`contiguous addresses” limitation does not require a
`“table.” ......................................................................................12
`
`C.
`
`Notarianni discloses a “control circuit.” .............................................14
`
`D. Notarianni discloses a decoding circuit “configured to
`request at least some of the contiguous addresses of the
`block of memory.” ...............................................................................18
`
`Notarianni discloses a decoding circuit that is “a video
`decoding circuit” [claims 3, 20] or an “audio decoding
`circuit” [claims 4, 21]. .........................................................................20
`
`Notarianni discloses a control circuit that includes “a
`memory management unit that is configured to translate
`i
`
`E.
`
`F.
`
`
`
`

`

`
`
`
`
`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`the noncontiguous addresses to the contiguous addresses”
`[claim 16]. ...........................................................................................21
`
`
`
`
`
`III. Notarianni renders obvious claims 7 and 22. ................................................21
`
`IV. Notarianni in view of Moore renders obvious claims 2 and 11. ...................23
`
`V. Notarianni in view of Rathnam renders obvious claim 34. ...........................24
`
`VI. Conclusion .....................................................................................................25
`
`VII. Certificate of Word Count .............................................................................26
`
`
`
`
`
`ii
`
`

`

`
`
`
`
`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`PETITIONER’S UPDATED EXHIBIT LIST
`
`
`
`
`
`February 24, 2017
`
`Description
`Exhibit
`Ex. 1001 U.S. Patent No. 5,969,464 (“the ’464 patent”)
`Ex. 1002 File History for U.S. Patent No. 5,960,464
`Ex. 1003 Reserved
`Ex. 1004 Reserved
`Ex. 1005 S. Rathnam et al., “An Architectural Overview of the Programmable
`Multimedia Processor, TM-1,” IEEE Proceedings of COMPCON ’96,
`pp. 319-326 (1996) (“Rathnam”)
`Ex. 1006 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)
`Ex. 1007 Reserved
`Ex. 1008 Reserved
`Ex. 1009 Reserved
`Ex. 1010 WorldCat Entry for Rathnam
`Ex. 1011 Reserved
`Ex. 1012 Reserved
`Ex. 1013 Reserved
`Ex. 1014 Reserved
`Ex. 1015 Reserved
`Ex. 1016 Reserved
`Ex. 1017 Reserved
`Ex. 1018 Reserved
`Ex. 1019 Reserved
`Ex. 1020 Reserved
`Ex. 1021 Reserved
`Ex. 1022 Reserved
`Ex. 1023 Reserved
`
`
`
`iii
`
`

`

`
`
`
`
`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`
`
`
`
`
`Description
`Exhibit
`Ex. 1024 “Accelerated Graphics Port Interface Specification,” Intel Corporation,
`July 31, 1996 (Revision 1.0) (“AGP Specification”)
`Ex. 1025 Reserved
`Ex. 1026 Reserved
`Ex. 1027 Reserved
`Ex. 1028 U.S. Patent No. 5,432,900 (“Rhodes”)
`Ex. 1029 Curriculum Vitae of Dr. Harold Stone
`Ex. 1030 Expert Declaration of Dr. Harold Stone (“Stone Decl.”)
`Ex. 1031 U.S. Patent No. 5,404,511 (“Notarianni”)
`Ex. 1032 Reserved
`Ex. 1033 Reserved
`Ex. 1034 Reserved
`Ex. 1035 G. Moore, “Cramming more components onto integrated circuits,”
`Electronics, Vol. 38, No. 8, Apr. 19, 1965 (“Moore”)
`Ex. 1036 Reserved
`Ex. 1037 Reserved
`Ex. 1038 P.R. 4-5(d) - Joint Claim Construction Chart in Case No. 2: 14-cv-902
`Ex. 1039
`Intel, Press Release: “INTEL ANNOUNCES ACCELERATED
`GRAPHICS PORT 1.0 SPECIFICATION,” August 5, 1996
`Ex. 1040 U.S. Patent No. 5,303,378 to Cohen
`Ex. 1041 Declaration of Curt Holbreich in Support of Motion for Pro Hac Vice
`Admission
`Ex. 1042 Declaration of Yakov Zolotorev in Support of Motion for Pro Hac
`Vice Admission
`Ex. 1043 Deposition Transcript of Dr. Mitchell A. Thornton
`Ex. 1044 Second Expert Declaration of Dr. Harold Stone
`Ex. 1045 Dictionary of Computer Terms (3rd ed. 1992)
`Ex. 1046 Errata sheet for Deposition of Dr. Stone included as Ex. 2004
`
`
`
`iv
`
`

`

`
`
`
`Introduction
`
`I.
`
`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`
`
`
`
`
`The Petition provides detailed reasons, based on the prior art evidence, for
`
`why a person of skill in the art (“POSITA”) would have understood Notarianni
`
`(either alone or in combination) to teach each and every limitation of the
`
`challenged claims of the ’464 patent. None of Patent Owner’s arguments overcome
`
`the express teachings of Notarianni as shown in the Petition.
`
`First, Patent Owner argues that Notarianni does not allocate memory at the
`
`outset of an application process and does not translate or convert scattered memory
`
`fragments into a contiguous memory block. Such arguments, however, contradict
`
`the teachings in Notarianni and are unpersuasive.
`
`Second, Patent Owner argues that the claims should be limited to a “look-up
`
`table” for translating addresses. However, the independent claims in question recite
`
`no such language. Notably, though, multiple dependent claims do include such
`
`language, which highlights that the independent claims are not so limited. Patent
`
`Owner’s argument is an improper attempt to import limitations into the
`
`independent claims.
`
`In sum, Patent Owner’s arguments fail. Notarianni anticipates claims 1, 3, 4,
`
`8-10, 12, 13, 16-21, 23, 24, 32, 33, 35, 36, and 40 and renders obvious claims 7
`
`and 22, 2 and 11 (in combination with Moore), and 34 (in combination with
`
`Rathnam). For the reasons shown in the Petition and below, the challenged claims
`
`
`
`1
`
`

`

`
`of the ’464 patent are unpatentable.
`
`
`
`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`
`
`
`
`
`II. Notarianni anticipates each and every limitation recited in claims 1, 3, 4,
`8-10, 12, 13, 16-21, 23, 24, 32, 33, 35, 36, and 40.
`
`Patent Owner argues that Notarianni does not anticipate each and every
`
`limitation of claims 1, 3, 4, 8-10, 12, 13, 16-21, 23, 24, 32, 33, 35, 36, and 40. As
`
`discussed below, however, Patent Owner only argues that Notarianni fails to
`
`disclose certain limitations of independent claims 1, 10, 19, and 32. As a result,
`
`since Notarianni anticipates the independent claims, Notarianni also anticipates the
`
`above listed dependent claims.
`
`A. Notarianni discloses a control circuit “configured to request
`continuous use of several portions of the main memory from the
`operating system” as recited in claims 1, 10, 19, and 32.
`
`1.
`
`Notarianni teaches a “request for continuous use” as recited
`in the claim.
`
`Notarianni discloses a “request for continuous use of several portions of the
`
`main memory from the operation system” as recited in the ’464 patent. Ex. 1044 ¶
`
`2. Notarianni is directed “[a]n application module of a data processing apparatus
`
`[that] requires various quantities of memory space for the buffering of data to be
`
`processed.” Ex. 1031, Abstract. Notarianni uses a “fragmented memory manager
`
`module [that] secures at the outset an allocation of buffer space sufficient for all
`
`requirements of the application module.” Id. (emphasis added).
`
`More specifically, when the application module in Notarianni is initiated, it
`
`
`
`2
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`“first finds at 702 the maximum amount of memory it will require in each plane.”
`
`
`
`
`
`
`
`Id. at 7:8-10. This maximum amount is “passed as a parameter to FRAGM, the
`
`fragmented memory manager module 212, in a call to the function FRAG_INIT.”
`
`Id. at 7:12-16. Next, the “FRAG_INIT is activated by the application, in respect of
`
`a specific memory plane (A, B, FMV etc.)” and “requests CDRTOS memory
`
`manager 210 to allocate at once the memory space required MAXN fragments.” Id.
`
`at 7:18-25 (emphasis added). Finally, when the application module “is preparing to
`
`cease its operation, and wishes to release the memory allocated to it via FRAGM,”
`
`if calls “function FRAG_SHUTDOWN of FRAGM with no parameters necessary .
`
`. . .” Id. at 9:49-54. “This memory now becomes free for use by the operating
`
`system, by other application modules or whatever.” Id. at 9:59-61.
`
`Thus, the fragmented memory manager module of Notarianni that secures, at
`
`the outset, memory sufficient for all requirements of the application module and
`
`releases the memory at the end for use by other applications discloses the recited
`
`request continuous use of several portions of the main memory. Ex. 1044 ¶ 3.
`
`2.
`
`Patent Owner seeks to improperly import a “static
`allocation” requirement into the claim limitation.
`
`Patent Owner argues that Notarianni fails to disclose a control circuit that
`
`“requests continuous use of several portions of the main memory” as recited in
`
`claim 1 and similarly recited in claims 10, 19, and 32 because, according to Patent
`
`
`
`3
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`Owner, “requests continuous use of several portions of the main memory” requires
`
`
`
`
`
`
`
`that free memory (i) be “statically” allocated (ii) “at the initiation of the MPEG
`
`application” and (iii) be “retained for use and not available for other purposes until
`
`the MPEG decoding operations are complete and the application terminates.”
`
`Response at 8-9. This argument fails for two reasons—first, it improperly attempts
`
`to import limitations into claims and, second, it relies on a non-existent distinction
`
`between the memory allocation method in the ’464 patent and the memory
`
`allocation method in Notarianni.
`
`First, Patent Owner’s argument relies on improperly importing limitations
`
`from an embodiment shown in Fig. 4 of the ’464 patent, “where the free memory
`
`that is anticipated to be used by the MPEG application as being ‘locked down’
`
`immediately following the initiation of the Windows MPEG application processing
`
`in step 202.” Response at 7 (citing Ex. 2003 (Thornton Decl. ¶ 38)); see also Ex.
`
`1043 at 34:6-21, 41:17-42:14. However, “it is improper to read limitations from a
`
`preferred embodiment described in the specification—even if it is the only
`
`embodiment—into the claims absent a clear indication in the intrinsic record that
`
`the patentee intended the claims to be so limited.” Liebel-Flarsheim Co. v.
`
`Medrad, Inc., 358 F. 3d 898, 913 (Fed. Cir. 2004); see also Phillips v. AWH Corp.,
`
`415 F. 3d 1303, 1323 (Fed. Cir. 2005) (there exists a “danger of reading limitations
`
`from the specification into the claims”).
`
`
`
`4
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`Here, Patent Owner’s reliance on this embodiment from the specification
`
`
`
`
`
`
`
`clearly violates the prohibition against importing limitations into the claims. See
`
`Phillips, 415 F. 3d at 1323. Patent Owner argues that, in the embodiment of Fig. 4,
`
`“[t]he system retains the multiple pages of memory, and their page descriptors, so
`
`as to lock down these portions of memory and prohibit the operating system or
`
`other applications from using them.” Ex. 1001 at 3:16-19; see also Response at 7.
`
`“This locked down memory is permanently allocated to the MPEG application for
`
`the duration of active processing.” Response at 7 (citing Ex. 2003 ¶ 39); see also
`
`Ex. 1001 at 3:33-36.
`
`Yet, the claim language merely states “request continuous use of several
`
`portions” of memory. The claims do not recite any language requiring that all of
`
`the memory be allocated in a particular way (i.e., static v. dynamic). The claims do
`
`not recite any language requiring that all of the memory be allocated at a particular
`
`time (i.e., at initiation v. while processing). The claims do not recite any language
`
`requiring that all of the memory be allocated using a particular technique (i.e.,
`
`locked down v. some other memory reservation technique).
`
`Moreover, Patent Owner has not pointed to a single instance of a clear
`
`indication in the intrinsic record that the claims are to be so limited. See Liebel-
`
`Flarsheim, 358 F. 3d at 913. In fact, the specification of the ’464 patent states the
`
`opposite—that the claims should not be limited to the specific embodiments
`
`
`
`5
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`disclosed in the specification. See Ex. 1001 at 9:30-34 (“Although specific
`
`
`
`
`
`
`
`embodiments of, and examples for, the present invention have been described
`
`herein for purposes of illustration, various equivalent modifications can be made
`
`without departing from the spirit and scope of the invention, as will be known by
`
`those skilled in the relevant art.”). Consequently, the “request continuous use”
`
`limitation in the independent claims cannot be construed solely to a static
`
`allocation of memory, as Patent Owner argues. See Phillips, 415 F. 3d at 1323;
`
`Liebel-Flarsheim, 358 F. 3d at 913.
`
`Second, even if the claims are limited to include a “static” allocation
`
`requirement, as Patent Owner alleges and as discussed above, Notarianni discloses
`
`such an allocation. Notarianni’s memory allocation has the same effect and works
`
`in the same manner as the “static” allocation in the ’464 patent. Id. ¶ 4. According
`
`to Patent Owner, memory is allocated in the ’464 patent such that “the free
`
`memory that is anticipated to be used by the MPEG application as being ‘locked
`
`down’ immediately following the initiation of the Windows MPEG application
`
`processing in step 202.” Response at 7 (citing Ex. 2003 (Thornton Decl. ¶ 38)).
`
`Likewise, as discussed above, Notarianni specifically teaches locking down
`
`memory anticipated to be used, as disclosed in the ‘464 patent. Ex. 1044 ¶ 4. In
`
`fact, the Patent Owner’s expert admits that the FRAGM module in Notarianni
`
`requests all of the memory from the operating system that may be used for
`
`
`
`6
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`decoding at the beginning of the decoding process, and that the memory remains
`
`
`
`
`
`
`
`“locked down” for the duration of decoding, resulting in a “static” allocation of
`
`memory under the expert’s own definition. See Ex. 1043 at 60:16-61:9, 62:5-18,
`
`64:18-65:4, 65:23-66:5; see also Ex. 1044 ¶ 4. Thus, Notarianni teaches what
`
`Patent Owner purports to be “static” allocation of memory. Ex. 1044 ¶ 4.
`
`Rather than point to Notarianni’s “static” memory allocation in its Response,
`
`Patent Owner instead argues that “in Notarianni free memory is dynamically
`
`allocated during the operation of the disclosed system” and that “Notarianni
`
`discloses dynamic allocation of free memory . . . rather than statically allocating
`
`memory at the initiation of an application as is required by the ‘continuous use’
`
`limitation of the claims of the ’464 Patent.” Response at 10-12. This argument,
`
`however, references the use of the memory by Notarianni’s decoder, not the
`
`allocation of the memory at the beginning of an application process as discussed
`
`above. Ex. 1044 ¶ 5; See Ex. 1043 at 69:3-9
`
`This distinction is important because Patent Owner’s expert admits that to
`
`determine whether Notarianni discloses the request for a “continuous use” of
`
`memory requires looking at what happens before decoding starts. Ex. 1043 at
`
`78:22-79:12; see also id. at 75:9-76:5 (acknowledging the difference between
`
`requests for initial memory allocation and requests for memory use during
`
`decoding in the ’464 claims). As described above, and as agreed to by the Patent
`
`
`
`7
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`Owner’s expert, the point at which all of the memory is requested by FRAGM
`
`
`
`
`
`
`
`prior to decoding is step 804. Ex. 1043 at 62:5-18. But Patent Owner and its expert
`
`never address step 804 and only address the later memory requests during decoder
`
`operation, which are not relevant to the limitation at issue. Ex. 1043 at 80:10-
`
`81:19.
`
`Accordingly, Patent Owner’s argument that there is some purported
`
`difference between the claims and Notarianni is merely a mischaracterization of
`
`Notarianni. Notarianni’s disclosure of allocating and securing buffer space at the
`
`outset that is sufficient for all requirements of the application module anticipates a
`
`control circuit “configured to request continuous use of several portions of the
`
`main memory from the operating system” as recited in the independent claims. Ex.
`
`1044 ¶ 6.
`
`B. Notarianni discloses a control circuit “configured to translate the
`noncontiguous addresses to contiguous addresses of a block of
`memory.”
`
` Patent Owner argues that Notarianni does not disclose translating
`
`noncontiguous memory address to contiguous memory addresses primarily
`
`because Notarianni uses a linked list instead of a table. See Response at 12-26.
`
`While Patent Owner attempts to raise a number of distinctions between using a
`
`linked list for memory mapping over using a table, none of Patent Owner’s alleged
`
`distinctions are actually recited in the claim and amount to nothing more than
`
`
`
`8
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`Patent Owner attempting to import a limitation into the claims.
`
`
`
`
`
`
`
`1.
`
`Notarianni’s linked list implementation teaches the express
`claim language.
`
`As set forth in the Petition, Notarianni’s linked-list implementation is
`
`“configured to translate the noncontiguous address to contiguous addresses” as
`
`recited in the independent claims. See Petition, Paper No. 2, at 12-13; see also Ex.
`
`1044 ¶ 7. This “translating” is done in Notarianni by creation of a linked list that
`
`maps the noncontiguous memory fragments to nodes of the list. Ex. 1044 ¶ 7. More
`
`specifically, Notarianni teaches that the fragmentation module (FRAGM) “requests
`
`CDRTOS memory manager 210 to allocate at once the memory space required for
`
`MAXN fragments.” Ex. 1031 at 7:23-25. If the requested number of fragments is
`
`allocated, “[t]he allocated space is ‘formatted’ to create a linked list of empty
`
`FRAG structures.” Id. at 7:29-31. “[T]he formatting of memory into a linked list of
`
`small fragments allows the use of all available memory for real-time buffers, even
`
`if such memory is severely fragmented and dispersed at random throughout the
`
`physical memory space.” Id. at 9:67-10:3. In this way, Notarianni “translates” the
`
`noncontiguous memory fragment addresses into contiguous nodes of a linked list.
`
`Ex. 1044 ¶ 7. An example of the linked list created in Notarianni is provided
`
`below:
`
`
`
`9
`
`

`

`
`
`
`
`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`
`
`
`
`
`
`
`Ex. 1031, Fig. 8.
`
`Patent Owner argues that Notarianni’s “creation of a ‘linked list’ of memory
`
`fragments is not the same as ‘translating’ or ‘converting’ the addresses of the
`
`memory fragments to create a memory block having contiguous addresses.”
`
`Response at 18. A linked list is defined as “a way of organizing data items in the
`
`computer so that they are retrievable in a particular order that is not necessarily the
`
`same order of the physical locations in which they are stored.” Ex. 1045 at 187.
`
`Notarianni’s link list performs the same function of translating noncontiguous
`
`addresses to continuous addresses as stated in the claim. Ex. 1044 ¶ 8. This is
`
`evident from comparing Patent Owner’s own figure provided in its Response,
`
`reproduced below, to a linked list implementation as described in Notarianni:
`
`
`
`10
`
`

`

`
`
`
`
`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`
`
`
`
`
`Table Embodiment from
`’464 patent according to
`Dr. Thornton
`(Ex. 2003 ¶ 60).
`
`Linked List Embodiment
`from Notarianni
`
`
`
`
`Ex. 1044 ¶ 8. Notarianni shows physically noncontiguous blocks of memory as
`
`forming one contiguous memory space F1 through F12, thus Notarianni teaches
`
`that memory requestors (such as the decoder) perceive the allocated memory as
`
`contiguous. Id.
`
`As seen in the figure above, the “Actual Addresses” correspond to
`
`noncontiguous addresses and the “Translated Addresses” correspond to the
`
`contiguous addresses. Id. ¶ 9. Accordingly, while the table implementation uses an
`
`index or table position as the continuous address that holds the translation of a
`
`noncontiguous address, the linked list implementation uses the link position (node
`
`1-4) to hold the result of the same translation. Id. For both implementations, the
`
`
`
`11
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`data structures are later used to translate the contiguous addresses (table index or
`
`
`
`
`
`
`
`node position) to the actual addresses of noncontiguous memory blocks. Id.
`
`Consequently, Patent Owner is incorrect that Notarianni’s “linked list of
`
`actual non-contiguous free memory block addresses is not equivalent to the lookup
`
`table” in the ’464 patent. See id. ¶ 10. Instead, because the memory fragments in
`
`Notarianni are not contiguous, the creation of the linked list serves to translate the
`
`noncontiguous addresses to contiguous addresses. See Ex. 1031 at 9:66-10:3; see
`
`also Ex. 1044 ¶ 10. Thus, both implementations (i.e., lookup table and linked list)
`
`translate noncontiguous addresses to contiguous addresses by creating their
`
`respective data structures illustrated above. Ex. 1044 ¶ 10.
`
`2.
`
`The “translate the noncontiguous address to contiguous
`addresses” limitation does not require a “table.”
`
`Patent Owner’s argument—that the translation taught in Notarianni via a
`
`linked list does not anticipate the claim (see Response at 12-26)—primarily relies
`
`on incorporating an embodiment from the specification of the ’464 patent where a
`
`controller creates “a lookup table to translate or map the 500 pages to a contiguous
`
`string of memory locations beginning at a set address and increasing contiguously
`
`therefrom to an address 2 megabytes later (the “2 megabyte contiguous
`
`addresses”).” Ex. 1001 at 7:46-50.
`
`Based on this embodiment, Patent Owner argues that the independent claims
`
`
`
`12
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`require “the construction of what appears to be a single contiguous block of
`
`
`
`
`
`
`
`memory such that the decoder perceives the available non-contiguous smaller
`
`memory blocks to be a larger contiguous block of memory through use of the
`
`created ‘lookup table.’” Response at 23.
`
`The independent claims, however, recite no explicit language that a table be
`
`created for this purpose. Ex. 1044 ¶ 12. Not only do the words “lookup table” or
`
`“what appears to be a single continuous block of memory” not appear in the
`
`independent claims, but claims 6, 15, and 37 that depend from independent claims
`
`1, 10, and 32, respectively, each recite “a look up table, the look up table mapping
`
`the noncontiguous addresses to the contiguous addresses.” See Ex. 1001; see also
`
`Ex. 1044 ¶ 12.
`
`Thus, because the independent claims do not recite language a specific type
`
`of data structure, while the dependent claims specifically set forth a “table”
`
`limitation, it would be improper to construe the independent claims as narrowly
`
`requiring a lookup table. See Liebel-Flarsheim, 358 F. 3d at 909-10; Ecolab, Inc. v.
`
`Paraclipse, Inc., 285 F. 3d 1362, 1375-76 (Fed. Cir. 2002); see also Ex. 1044 ¶ 13.
`
`Patent Owner’s expert is in agreement that the independent claims are not limited
`
`to a look-up table implementation. Ex. 1043 at 24:23–25:2 (“Q. . . . So you would
`
`agree with me that claim 1 is not limited to a lookup table implementation? A.
`
`Yes.”).
`
`
`
`13
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`Consequently, Patent Owner’s purported differences between an
`
`
`
`
`
`
`
`embodiment using a table to translate and an embodiment using a linked-list to
`
`translate (as disclosed in Notarianni) are predicated upon an improper construction
`
`of the claims. Ex. 1044 ¶ 14. Likewise, Patent Owner’s assertions that the claims
`
`require creation of some sort of contiguous block of memory using a lookup table
`
`is also not relevant as no such requirement is recited in the independent claims. Id.
`
`C. Notarianni discloses a “control circuit.”
`
`Notarianni discloses a control circuit as recited in the claim. As originally set
`
`forth in the Petition, Notarianni discloses an access controller that is coupled to the
`
`decoding circuit, the processor, and the main memory. Petition at 12-13 (citing Ex.
`
`1030 ¶ 47). This is shown in Fig. 1 of Notarianni, reproduced below:
`
`
`
`14
`
`

`

`
`
`
`
`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`
`
`
`
`
`
`
`Ex. 1031, Fig. 1 (annotated); see also Ex. 1030 at p.21.
`
`The access controller executes the FRAGM program, which performs the
`
`address translation. See, e.g., Ex. 2004 at 78:20–79:1; Ex. 1046 at 1 (“Q So does
`
`the access controller perform the translation? A The access controller is configured
`
`to execute a program: FRAGM. And when FRAGM executes this program, the
`
`translation is done.”). Notarianni’s access controller and its FRAGM software
`
`disclose the control circuit according to the claims.
`
`Further, the FRAGM software configures the access controller to request
`
`continuous use of several portions of the main memory from the operating system.
`
`See Ex. 1031 at 7:23-25 (“804: FRAGM requests CDRTOS memory manager 210
`15
`
`
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`to allocate at once the memory space required for MAXN fragments.”). The
`
`
`
`
`
`
`
`FRAGM software also configures the access controller to translate the
`
`noncontiguous addresses to contiguous addresses of a block of memory by creating
`
`the linked list of fragmented memory. See id. at 7:29-30 (“808: The allocated space
`
`is ‘formatted’ to create a linked list of empty FRAG structures.”). Thus, the access
`
`controller in Notarianni controlled by the FRAGM software discloses each and
`
`every element of the claimed control circuit.
`
`However, Patent Owner argues that Notarianni does not disclose a “control
`
`circuit” as recited in the claim because no single component in Notarianni is (1)
`
`“coupled to the decoding circuit, the processor and the main memory,” (2)
`
`“configured to request continuous use of several portions of the main memory
`
`from the operating system,” and (3) “configured to translate the noncontiguous
`
`addresses to contiguous addresses of a block of memory.” See Response at 26. This
`
`argument is not persuasive.
`
`First, as shown in Fig. 1 of Notarianni, above, the access controller is
`
`coupled to the decoding circuit, the processor, and the main memory. Ex. 1031,
`
`Fig. 1 (annotated); see also Ex. 1030 at p.21. Second, the access controller
`
`executes the FRAGM software, which, as discussed above in Section II.A, is
`
`configured to request continuous use of several portions of the main memory from
`
`
`
`16
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`the operating system.1 Third, the access controller executes the FRAGM software,
`
`
`
`
`
`
`
`which uses a linked list implementation to translate the noncontiguous addresses to
`
`contiguous addresses of a block of memory, as discussed above in Section II.B.
`
`Patent Owner also argues that “the Petition seems to rely on the application
`
`module (202) not the access controller.” See Response at 29. This is a
`
`mischaracterization of the Petition. The Petition points to the FRAGM software as
`
`performing the software component of the control circuit. See Petition at 12-13.
`
`Moreover, the application module uses the FRAGM software to interface with the
`
`memory aspects of the operating system. See Ex. 1031, Fig. 5 (showing the
`
`components of FRAGM); id., Fig. 7 (showing the application module calling
`
`various functions of FRAGM). Thus, as stated in the Petition, the access controller
`
`of Notarianni controlled by the FRAGM software discloses the “control circuit” as
`
`recited in the independent claims.
`
`
`1 Patent Owner Response makes several arguments regarding the access controller
`
`of the Philips reference (incorporated by reference into Notarianni (Ex. 1031 at
`
`1:33-37)) See Response at 26-28. These arguments ignore the fact that Notarianni
`
`is an improvement upon the device in Philips. See Ex. 1031 at 1:56-59. These
`
`arguments also do not address the FRAGM software that controls the access
`
`controller as fully described in Notarianni.
`
`
`
`17
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`Lastly, Patent Owner argues that Notarianni’s access controller that executes
`
`
`
`
`
`
`
`the FRAGM software is not a “single element.” See Response at 26. Patent Owner,
`
`however, is contradicting the teachings of the specification of the ’464 patent. In
`
`the ’464 specification, the microcontroller 120 carries out the function of the
`
`control circuit. See Ex. 1043 at 116:10-14 (“Q. And you agree that the
`
`microcontroller that’s discussed here at column 7, line 40, is -- corresponds to an
`
`embodiment of the control circuit? A. Yes.”). Notably, the microcontroller 120
`
`includes “a memory management unit 122 (MMU) [that] operates under a routine
`
`described below to decode audio and video from the DVD CD-ROM player 112.”
`
`Ex. 1001 at 4:43-46 (emphasis added). Accordingly, the specification contemplates
`
`that the recited control circuit includes a hardware component that executes a
`
`software routine. Notarianni discloses precisely the same single element (a
`
`hardware component, i.e., the access controller that executes a software routine,
`
`i.e., the FRAGM software).
`
`D. Notarianni discloses a decoding circuit “configured to request at
`least some of the contiguous addresses of the block of memory.”
`
`Patent Owner argues that Notarianni does not disclose the claimed decoder
`
`circuit because the decoders in Notarianni are not “configured to request at least
`
`some of the contiguous addresses of the block of memory.” See Response at 31-34.
`
`Notarianni, however, discloses both a video decoder and an audio decoder that
`
`
`
`18
`
`

`

`Petitioner’s Reply
`IPR2016-00924 (Patent No. 5,960,464)
`
`
`perform this function because they use the linked list of memory fragments to
`
`
`
`
`
`
`
`generate video and audio presentations. Ex. 1044 ¶ 15.
`
`As stated in the Petition, Notarianni discloses a decoder 206 that reads audio
`
`and video data from the memory “for the generation of the desired audio and video
`
`presentation.” See Petition at 13-14; Ex. 1031 at 4:20-24; see also Ex. 1044 ¶ 16.
`
`As discussed above, the memory in Notarianni is organized as a linked list of
`
`noncontiguous fragments. Ex. 1031 at 7:29-30 (“808: The allocated space is
`
`‘formatted’ to create a linked list of empty FRAG structures.”). This linked list is
`
`used in Notarianni’s system to store the audio and video data utilized by the
`
`decoders. Id. at 7:58-59 (“FRAGM allocates the first four free fragments F1 to
`
`F4”); id. at 8:34-36 (“all four sectors of the image file are eventually loaded into
`
`the buffer sectors IM1.1 to IM1.4”); see id., Fig. 8 (showing I