Monterey Research, LLC

Patent Trials and Appeals Board

Jan 21, 2022

IPR2020-01124 (P.T.A.B. Jan. 21, 2022)

Trials@uspto.gov Paper 32 571-272-7822 Entered: January 21, 2022 UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD ADVANCED MICRO DEVICES, INC., Petitioner, v. MONTEREY RESEARCH, LLC, Patent Owner. IPR2020-01124 Patent 6,629,226 B1 Before KRISTEN L. DROESCH, JOHN F. HORVATH, and JASON W. MELVIN, Administrative Patent Judges. DROESCH, Administrative Patent Judge. JUDGMENT Final Written Decision Determining All Challenged Claims Unpatentable 35 U.S.C. § 318(a) Dismissing Motion to Exclude 37 C.F.R. § 42.64(c) IPR2020-01124 Patent 6,629,226 B1 2 I. INTRODUCTION We have authority to hear this inter partes review under 35 U.S.C. § 6. This Final Written Decision is issued pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73. For the reasons that follow, we determine that Advanced Micro Devices, Inc. (“Petitioner”) establishes by the preponderance of the evidence that claims 1-19 of U.S. Patent No. 6,629,226 B1 (Ex. 1001, “’226 Patent”) are unpatentable. A. Procedural History Petitioner filed a Petition requesting an inter partes review of claims 1-19 of the ’226 Patent. Paper 1 (“Pet.”). Monterey Research, LLC (“Patent Owner”) timely filed a Preliminary Response. Paper 8. Pursuant to 35 U.S.C. § 314, we instituted trial on January 27, 2021. Paper 10 (“Dec.”). After institution of trial, Patent Owner filed a Response (Paper 15, “PO Resp.”), to which Petitioner filed a Reply (Paper 18, “Pet. Reply”), to which Patent Owner filed a Sur-reply (Paper 20, “PO Sur-reply”). Petitioner relies on a Declaration of Stephen Melvin, Ph.D. (Ex. 1003) to support its Petition. Patent Owner relies on a Declaration of Nader Bagherzadeh, Ph.D. (Ex. 2003) to support its Patent Owner Response. Petitioner relies on a second Declaration of Stephen Melvin, Ph.D. (Ex. 1013) to support its Reply. Dr. Melvin and Dr. Bagherzadeh were cross-examined during trial, and transcripts of Dr. Melvin’s depositions (Exs. 2005, 2018) and Dr. Bagherzadeh’s deposition (Ex. 1012) are included in the record. Petitioner filed a Motion to Exclude Evidence (Paper 25, “Mot.”) to which Patent Owner filed an Opposition (Paper 26, “Opp.”), to which Petitioner filed a Reply (Paper 27, “Reply Opp.”). IPR2020-01124 Patent 6,629,226 B1 3 Oral argument was held on October 28, 2021. A transcript of the oral argument is included in the record. Paper 31 (“Tr.”). B. Related Matters The parties indicate the ’226 Patent is the subject of litigation in Monterey Research, LLC v. Advanced Micro Devices Inc., Case No. 1:19- cv-02149 (D. Del.), Monterey Research, LLC v. Marvell Tech. Grp, Ltd., No. 1.20-cv-00158 (D. Del.), and Marvell Semiconductor, Inc. v. Monterey Research, LLC, No. 3-20-cv-03296 (N.D. Cal.). See Pet. 5-6; Paper 4, 1. C. The ’226 Patent (Ex. 1001) The ’226 Patent relates to a method and architecture for implementing a multiqueue first-in-first-out (MQFIFO) memory read interface protocol. See Ex. 1001, 1:16-18. Figure 3 of the ’226 Patent is reproduced below. Figure 3 depicts a block diagram of system or circuit 100 comprising MQFIFO storage device 102 and external read device 104. See Ex. 1001, 3:22-34. MQFIFO 102 has output 110 that presents an address request (ADDR_REQ) signal to input 112 of read device 104. See id. at 3:35-38. Read device 104 has output 132 that presents queue address (ADDRESS) signal to input 134 of MQFIFO 102 and output 128 that presents valid address indication (ADDR_VALID) signal to input 130 of MQFIFO 102. IPR2020-01124 Patent 6,629,226 B1 4 See id. at 3:40-46 MQFIFO 102 has output 106 that presents a DATA signal to input 108 of read device 104 and output 114 that presents a DATA_VALID signal to input 116 of read device 104. See id. at 3:35-40. Read device 104 has output 120 that presents read clock (READ_CLOCK) signal to input 122 of MQFIFO 102, and output 124 that presents read enable (READ_EN) signal to input 126 of MQFIFO 102. See id. at 3:40-43, 3:47-49. The ’226 Patent discloses that the signals ADDR_VALID, ADDR_REQ and DATA_VALID may allow for variable size data packets and asynchronous operation. See id. at 3:56-58. Circuit 100 implements a handshaking protocol to transfer data. See Ex. 1001, 4:1-2, 7:39-41, Fig. 8. Signal ADDR_REQ requests a next queue address, and signal ADDR_VALID is asserted in response to ADDR_REQ to indicate that the queue address ADDRESS is valid in the current cycle. See id. at 4:2-5, 4:14-16, 7:44-51, 8:58-64, Fig 8. In response, DATA_VALID and DATA are asserted. See id. at 4:5-7, 4:23-29, 7:51-56, 8:64-66, Fig. 8. Read enable signal READ_EN may be modified to indicate whether read device 104 has space to continue with the read, thereby providing a pause feature of circuit 100 and enabling read device 104 to efficiently control reading of data from MQFIFO 102. See id. at 4:7-13, 7:56-64, 8:10-12, Fig. 8. IPR2020-01124 Patent 6,629,226 B1 5 Figure 4 of the ’226 Patent is reproduced below. Figure 4 depicts a detailed block diagram of circuit 100, including read device 104 and MQFIFO 102. See Ex. 1001, 4:40-41. Read device 104 comprises queue scheduler 105 or read control device. See id. at 4:42-43. MQFIFO 102 comprises synchronization circuit 150, address circuit 152, read interface circuit 154, controller circuit 156, and memory circuit 158. See id. at 4:51-65. Dotted line 159 illustrates a division between components operating in an interface clock domain and components operating in a system clock domain. See id. at 4:66-5:3. Controller 156 sends ADDR_REQ@SYSCLK to synchronization circuit 150 and address circuit 152, and synchronization circuit 150 presents ADDR_REQ@INFCLK to read device 104. See id. at 5:3-9. Address circuit 152 receives ADDRESS@INFCLK and ADDR_VALID in response to ADDR_REQ@INFCLK. See id. at 5:31-47. Address circuit 152 uses event driven variable state pipelining of ADDRESS. See id. at 5:35-38, Figs. 5, 7. Address circuit 152 presents ADDRESS@SYSCLK to controller 156, and in response, controller 156 sends PHY_ADDR to IPR2020-01124 Patent 6,629,226 B1 6 memory 158. See id. at 5:10-14, 6:56-59, 6:64-67, Fig. 6. Controller 156 computes ADDR_REQ@SYSCLK based on end of packet information (e.g., EOP) or if a packet needs to be transferred (e.g., FIRST_PKT). See id. at 6:67-7:11, Fig. 6. Memory 158 sends PKT_INFO to controller 156 and sends DATA@SYSCLK to read interface 154 while operating in the system clock domain. See id. at 5:14-17. Read interface 154 synchronizes the clock domain of read data to the interface clock domain. See id. at 5:17-20. D. Illustrative Claim Claims 1, 11, 12, 18, and 19 are independent, claims 2-10 depend from claim 1, and claims 13-17 depend from claim 12. Claim 1 is illustrative and reproduced below: 1. An interface coupled to a multiqueue storage device and configured to interface said multiqueue storage device with one or more handshaking signals, wherein said multiqueue storage device and said interface are configured to transfer variable size data packets and said multiqueue storage device is configured to generate an address request signal. IPR2020-01124 Patent 6,629,226 B1 7 E. Asserted Challenges to Patentability and Asserted Prior Art Petitioner asserts that claims 1-19 would have been unpatentable on the following grounds: Claim(s) Challenged 35 U.S.C. § Reference(s) 1-19 102(b)1 Joshi2 1-4, 7-19 102(b) Chang3 1-4, 7-10, 14, 15, 19 103(a) Chang and the Admitted Prior Art (APA)4 5, 6, 16 103(a) Chang, Joshi, and optionally the APA II. ANALYSIS A. Level of Ordinary Skill in the Art Petitioner asserts: A POSITA [person of ordinary skill in the art] as of December 8, 2000, would have had a bachelor of science degree in computer science, electrical engineering, computer engineering, or a related field, and approximately two years of experience in the design, development, and/or testing of systems with memory devices, related hardware design, or the equivalent, with additional education and/or research substituting for experience and vice versa. Pet. 19-20 (citing Ex. 1003 ¶¶ 24-25). Patent Owner adopts Petitioner’s definition of a person of ordinary skill in the art. See PO Resp. 11 (citing Pet. 19-20; Ex. 2003 ¶¶ 71-72). We adopt Petitioner’s definition of a 1 The Leahy-Smith America Invents Act, Pub. L. No. 112-29, 125 Stat. 284 (2011), amended 35 U.S.C. §§ 102, 103 effective March 16, 2013. Because the filing date of the ’226 Patent is prior March 16, 2013, we refer to the pre-AIA versions of §§ 102, 103. 2 Ex. 1007, US 4,949,301 A, issued Aug. 14, 1990 (“Joshi”). 3 Ex. 1006, US 5,367,643 A, issued Nov. 22, 1994 (“Chang”). 4 Admitted Prior Art (“APA”) IPR2020-01124 Patent 6,629,226 B1 8 person of ordinary skill in the art, as it is consistent with the level of skill reflected by the Specification and the asserted prior art references. B. Claim Construction The Board applies the same claim construction standard as that applied in federal courts. See 37 C.F.R. § 42.100(b). The claim construction standard used in a civil action under 35 U.S.C. § 282(b) is generally referred to as the Phillips standard. See Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc). Under the Phillips standard, “words of a claim ‘are generally given their ordinary and customary meaning.’” Phillips, 415 F.3d at 1312 (quoting Vitrionics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (1996)). In determining the ordinary and customary meaning, “the specification ‘is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term.’” Phillips, 415 F.3d at 1315 (quoting Vitrionics, 90 F.3d at 1582). Extrinsic evidence may be useful, but it is unlikely to result in a reliable interpretation of patent claim scope unless considered in the context of the intrinsic evidence. Phillips, 415 F.3d at 1319. 1. Multiqueue Storage Device Initially, neither party provides an explicit claim construction for “multiqueue storage device.” See Pet. 17-19; PO Resp. 11-17. In any event, Patent Owner offers several implicit constructions for the term when addressing the merits of the Petition’s patentability challenges. Patent Owner initially contends in its Response that a multiqueue storage device “is a storage element or memory device that organizes data into multiple queues.” PO Resp. 10 (citing Ex. 2005, 15:3-14; Ex. 2003 ¶ 43); see also id. at 1-3 (similar argument, citing Ex. 2003 ¶¶ 48-49), 47 (similar IPR2020-01124 Patent 6,629,226 B1 9 argument, citing Ex. 2003 ¶ 140; incorporating by reference Pet. 10). Based on arguments addressing the disclosures of Joshi, Patent Owner further asserts that a multiqueue storage device must manage and control accesses to the queues in the multiqueue storage device. See PO Resp. 49 (citing Ex. 2003 ¶ 145), 50-51 (citing Ex. 2003 ¶ 147); see also PO Sur-reply 11 (similar argument). Based on arguments addressing the disclosures of Joshi and the ’226 Patent, Patent Owner contends that a multiqueue storage device must control reading and writing data. See PO Resp. 56-57 (quoting Ex. 1001, 5:26-29; citing Ex. 2003 ¶¶ 158, 161); see also PO Sur-reply 12, 17 (similar argument). Petitioner asserts that there is no basis for importing limitations into the claims requiring the multiqueue storage device, including limitations requiring the device to organize the data into queues. See Pet. Reply 3. Petitioner contends that Patent Owner’s construction is improper and should be rejected. See id. at 7-8 (quoting PO Resp. 10, 24; citing PO Resp. 47). Petitioner contends that Patent Owner cites only to the testimony of both parties’ witnesses without explanation to support its construction. See id. at 8 (citing PO Resp. 10; Ex. 2003 ¶ 43; Ex. 2005, 15:3-14). Petitioner asserts that Dr. Melvin testifies that a First-In-First-Out (FIFO) storage device can be externally managed by logic outside of the device, and further contends that Patent Owner and Dr. Bagherzadeh concede this point. See id. (quoting PO Resp. 10; Ex. 2003 ¶ 41; citing Ex. 2005, 53:24-55:20); see also id. at 9-10 (similar argument, citing PO Resp. 10; Ex. 2003 ¶ 41; Ex. 2005, 20:10-21, 46:24-47:12, 55:6-20). According to Petitioner, “Patent Owner provides no explanation or support for its unstated premise that [multiqueue storage devices] with externally-managed read and write IPR2020-01124 Patent 6,629,226 B1 10 pointers do not fall within the ambit of the claims.” Id. at 9. Petitioner contends that the multiqueue storage device limitation does not require organizing capability inside the MQSD itself. See id. at 10. According to Petitioner, “Dr. Melvin’s construction that a [multiqueue storage device] is ‘a storage element that contains . . . multiple queues[,]’ . . . is correct.” Id. at 8 (quoting Ex. 2005, 15:8-9; Ex. 1001, 1:50-52). As to the additional limitations implicitly argued by Patent Owner, Petitioner contends that “nothing in the claims or in the ordinary meaning of ‘multiqueue storage device’ requires any minimum level of access or communication between the components that make up the [multiqueue storage device].” Pet. Reply 10; see id. at 10-11 (case citations omitted). Petitioner asserts that Patent Owner fails to tie its assertions regarding control of reading and writing data to the multiqueue storage device to any claim limitation and instead attempts to import limitations into the claim from a disclosed embodiment of the multiqueue storage device that Patent Owner concedes is optional and does not control reading and writing in all cases. See id. at 12 (quoting PO Resp. 13). Petitioner urges the Board to reject Patent Owner’s attempt to import limitations from the Specification into the claims. See id. (citing TomTom, Inc. v. Adolph, 790 F.3d 1315, 1328 (Fed. Cir. 2015)). In the Sur-reply, Patent Owner contends that Petitioner’s interpretation of a “queue” is inconsistent with the ordinary and customary meaning of the term and Dr. Melvin’s admissions. See PO Sur-reply 2-6. Patent Owner asserts that the ’226 Patent discloses that without the queue address circuit 152, block 102 of MQFIFO would be reduced to a simple memory. See id. at 2-3 (reproducing Ex. 1001, Fig. 4; citing Ex. 1001, IPR2020-01124 Patent 6,629,226 B1 11 4:56-57). In any event, Patent Owner also asserts that “[t]he implementation details of the queue address circuit 152, e.g., whether it is internal or external to the [multiqueue storage device], are not as important.” Id. at 3. Patent Owner contends that a person of ordinary skill in the art “would . . . have understood that without a queue manager, the storage device cannot implement a queue.” Id. at 5; see also id. at 3-4 (addressing Dr. Melvin’s discussion of the Chang and Joshi disclosures), 5-6 (providing illustrative examples). Patent Owner also contends that Dr. Melvin’s interpretation of multiqueue storage device is circular, and that Dr. Melvin did not provide a claim construction analysis or evidence to support his understanding of the term. See PO Sur-reply 6-7 (quoting Pet. Reply 8; Ex. 2005, 15:3-20). Patent Owner asserts that Dr. Melvin admitted that without a queue manager the queue would not work. See id. at 6-10 (reproducing Ex. 1011, Fig. 3; quoting Ex. 2018, 78:7-79:9, 80:25-81:15, 82:4-10). According to Patent Owner, a person of ordinary skill in the art “would therefore have understood that the queue manager should be understood as coextensive to the queue itself.” Id. at 7. Patent Owner also contends that Petitioner’s interpretation would not have been consistent with the understanding of a person of ordinary skill in the art. See id. at 6. More specifically, Patent Owner asserts that a person of ordinary skill in the art “would not have understood a queue to merely consist [of] a physical memory that holds queue data without any information or organizational structure that instantiates the actual queue.” Id. at 10. Turning first to the intrinsic evidence, as pointed out by Patent Owner, the ’226 Patent Specification discloses a multiqueue storage device or IPR2020-01124 Patent 6,629,226 B1 12 multiqueue FIFO 102 that may include address circuit 152 and controller circuit 156. See PO Resp. 7-9; PO Sur-reply 2-3; Ex. 1001, Figs. 3-5, 4:51-59, 5:10-20, 5:31-6:55. Although the ’226 Patent discloses a multiqueue storage device that itself (i.e., internally) includes circuits that organize, manage, and control access to the data in multiqueue storage device, we decline to import limitations into the claim from the ’226 Patent Specification that would require the multiqueue storage device to include internal management, organization, access control, and control of reading and writing of data in the multiqueue storage device. Though understanding the claim language may be aided by the explanations contained in the written description, it is important not to import into a claim limitations that are not a part of the claim. For example, a particular embodiment appearing in the written description may not be read into a claim when the claim language is broader than the embodiment. SuperGuide Corp. v. DirecTV Enters., Inc., 358 F.3d 870, 875 (Fed. Cir. 2004); see also Leibel-Flarsheim Co. v. Medrad, Inc., 358 F.3d 898 (Fed. Cir. 2004) (when the patent specification discloses a single embodiment, the claims of a patent will not be read constrictively unless the patentee has demonstrated a clear intention to limit the claim scope using words or expressions of manifest exclusion or restriction.). Turning to the extrinsic evidence, we agree that a multiqueue storage device implicitly requires some component or logic that organizes or manages the queues. See Ex. 1003 ¶¶ 53, 67, 104, 144, 145, 171; Ex. 2005, 54:22-55:6, 55:16-20; Ex. 2018, 82:4-10. The evidence, however, does not support Patent Owner’s position that the multiqueue storage device itself is required to contain the logic or component that manages or organizes queues in the storage device. Patent Owner and Dr. Bagherzadeh acknowledge, and IPR2020-01124 Patent 6,629,226 B1 13 Dr. Melvin confirms, that queues within a FIFO memory device may be internally managed by the FIFO memory device, or externally managed by logic or a component outside the memory device. See PO Resp. 10; PO Sur- reply 3; Ex. 2005, 53:24-55:20; Ex. 2003 ¶ 41; see also Tr. 30:1-19 (similar assertion by Patent Owner’s counsel). For this same reason, Patent Owner’s arguments that the multiqueue storage device itself must control access to and reading and writing data to the queues in the multiqueue storage device are not supported by the extrinsic evidence. See id. For the foregoing reasons, we agree with neither Patent Owner’s implicit constructions nor Petitioner’s witness Dr. Melvin’s explicit construction for “multiqueue storage device.” Instead, we construe a multiqueue storage device as “a storage device having data organized into multiple queues,” without any limitation on the logic or component that organizes or manages the queues--whether that logic or component is internal or external to the multiqueue storage device. 2. “Means for Interfacing a Multiqueue Storage Device” and “Means for Interfacing With One or More Handshaking Signals” Claim 11 is reproduced below: An interface comprising: means for interfacing a multiqueue storage device; and means for interfacing with one or more handshaking signals, wherein said multiqueue storage device and said interface are configured to allow back-to-back reads of variable size data packets. Ex. 1001, 10:22-27. Petitioner asserts the phrase “means for interfacing a multiqueue storage device” creates a presumption that it is a means-plus- function limitation. See Pet. 17 (citing Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1348 (Fed. Cir. 2015) (en banc)). Petitioner asserts that “an IPR2020-01124 Patent 6,629,226 B1 14 interface” is the only structure in the specification clearly linked to the “interfacing” function. See id. at 17-18 (quoting Ex. 1001, code (57) 2:30- 33, 9:52-53; MobileMedia Ideas LLC v. Apple Inc., 780 F.3d 1159, 1169 (Fed. Cir. 2015); citing Ex. 1003 ¶¶ 36-37). Petitioner contends that the phrase “means for interfacing with one or more handshaking signals” should also be construed to mean an “interface” for the same reasons. See Pet. 19. According to Petitioner, “[t]he same specification passages associate this function ‘interfacing with one or more handshaking signals’ with an ‘interface.’” Id. (quoting Ex. 1001, code (57), 2:30-33, 9:52-53; citing Ex. 1003 ¶¶ 39-40). Petitioner further asserts “[t]here is no reason that this limitation cannot be construed to refer to the same structure as the first means limitation, especially where the specification clearly links the same arguable structure to the performance of this function as well.” Id. (citing In re Kelley, 305 F.2d 909, 914 (CCPA 1962)). Patent Owner contends that the corresponding structure for “means for interfacing a multiqueue storage device” “is an ‘interface,’ including all necessary control circuitry.” PO Resp. 4 (citing Ex. 2003 ¶ 79); see also id. at 12-14 (supporting arguments, reproducing Ex. 1001, Fig. 4 (with annotations); quoting Ex. 1001, 1:16-23, 2:30-34, 3:26-29, 3:54-56, 4:43-44, 4:59-60, 5:22-27; citing Ex. 2003 ¶¶ 76-78; Ex. 2005, 10:14-19, 106:2-18). Patent Owner asserts that the corresponding structure for “means for interfacing with one or more handshaking signals” “is an ‘interface,’ including all necessary control circuitry for providing a handshake protocol.” Id. at 17 (citing Ex. 2003 ¶ 84); see also id. at 15-16 (supporting arguments, reproducing Ex. 1001, Fig. 4 (with annotations); quoting Ex. 1001, 2:30-33, 3:54-56; citing Ex. 2003 ¶¶ 81-83; Ex. 2005, 106:2-18). IPR2020-01124 Patent 6,629,226 B1 15 In the Reply, Petitioner disputes Patent Owner’s constructions, asserting that Patent Owner seeks to add to the corresponding structure. See Pet. Reply 3-7. Petitioner contends that the constructions of the two “means for interfacing” limitations beyond simply an “interface” is unnecessary and immaterial to this proceeding because Patent Owner does not contend that either limitation, however construed, provides any distinction over the prior art, and because the prior art discloses interfaces including supporting protocols and circuitry in more detail that the ’226 Patent. See id. at 2 (citing Pet. 10-16, 20-27, 53-59). As demonstrated in the analysis below, we need not provide explicit claim construction for the means-plus-function limitations beyond the undisputed corresponding structures of an “interface” offered by both parties. See Nidec Motor Corp. v. Zhongshan Broad Ocean Motor Co., 868 F.3d 1013, 1017 (Fed. Cir. 2017) (“[W]e need only construe terms ‘that are in controversy, and only to the extent necessary to resolve the controversy.’” (quoting Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999))). C. Principles of Law “Under 35 U.S.C. § 102 a claim is anticipated ‘if each and every limitation is found either expressly or inherently in a single prior art reference.’” King Pharm., Inc. v. Eon Labs, Inc., 616 F.3d 1267, 1274 (Fed. Cir. 2010) (quoting Celeritas Techs. Ltd. v. Rockwell Int’l Corp., 150 F.3d 1354, 1360 (Fed. Cir. 1998)). IPR2020-01124 Patent 6,629,226 B1 16 D. Challenge to Claims 1-19 Based on Joshi 1. Overview of Joshi (Ex. 1007) Joshi is directed to a buffer controller for managing the address input lines of a random access memory (RAM) buffer to simulate the operation of two independent first-in first-out (FIFO) buffers operating therein. See Ex. 1007, code (57), 1:9-13, 3:57-59. Figure 1 of Joshi is reproduced below. Figure 1 depicts a block diagram of the system in which RAM buffer controller (RBC) 44 resides. See Ex. 1007, 7:14-15, 7:55-57. The system includes fiber optic transmission medium 20, fiber optic transceiver 22, encoder/decoder (ENDEC) 28, media access controller circuit (FORMAC) 34, host system 36, RBC 44, data path controller (DPC) 43, buffer memory (BM) 38, and node processor 52. See id. at 7:57-10:7. Host system 36 transmits and receives data packets to or from other host systems on a network. See id. at 8:26-28. Packets to be transmitted can be stored temporarily in BM 38 until transmission medium 20 is available for use. See id. at 8:37-44. DPC 34 is coupled to BM 38 and serves to control the data transmission to and from BM 38. See id. at 8:52-55. RBC 44 is coupled to BM 38, arbitrates requests for access to BM 38, selects one request to be IPR2020-01124 Patent 6,629,226 B1 17 honored, and outputs an address pointer to BM 38 to cause it to output data from, or store data in, the proper address. See id. at 8:55-64. RBC 44 maintains a set of pointer addresses stored in registers therein, which can cause BM 38 to simulate the operation of two independently operating FIFO buffer memories. See id. at 8:64-9:1. Node processor 52 talks to BM 38 by making service requests to RBC 44 and transmitting data to, or receiving data from, BM 38. See id. at 9:48-52. Figure 2 of Joshi is reproduced below. Figure 2 depicts a block diagram of RBC 44. See Ex. 1007, 7:16-17, 10:8-9. RBC 44 includes request arbitration logic 62 that arbitrates requests from node processor 52, DPC 43, and host system 36 for access to or from BM 38. See id. at 10:8-15. DPC 43 requests for access to BM 38 are made using handshake signals exchanged between RBC 44 and DPC 43 on bus 64. See id. at 10:15-18. DPC handshake logic 66 receives DRDREQS and DRDREQA signals from DPC 43, which represent synchronous and IPR2020-01124 Patent 6,629,226 B1 18 asynchronous read requests, respectively. See id. at 10:37-41, 15:49-64. Arbitration logic 62 selects the highest priority currently pending request and DPC requests have the highest priority. See id. at 13:34-37. The assertion of a DPC read request causes control logic to generate the proper select signal to the G multiplexer to select the RPX pointer, which is the read pointer for the transmit buffer. See id. at 15:56-60, Fig. 4. Joshi discloses three algorithms executed by the control logic for receiving a normal data packet, totally flushing undesired packets, and aborting received packets without losing status and length information. See Ex. 1007, 5:23-30, 22:67-29:2, Figs. 8-10. “The algorithm for storing normally received packets allows status and length information to be written in the memory location just preceding the first byte of the received packet. This is true regardless of how long the packet is and whether or not its length is known.” Id. at 5:31-35. This information indicates whether the received packet is a valid packet and the length of the packet. See id. at 26:48-51. Joshi further discloses that it is useful to put the status and length information at the beginning of the packet rather than at the end of the packet because it simplifies the software overhead of the node processor. See id. at 26:53-57. Putting the status and length information at the beginning of the packet allows the node processor to know exactly where to look for the status and length information in each packet without having to know how long the packet is, which it would have to know if the status and length information was stored at the end of the packet. See id. at 26:53-60. Joshi also discloses that, in some applications, it is useful to allow two systems that need to access a RAM to share a single RBC 38, whether or not the two systems are running synchronously with each other. See Ex. 1007, IPR2020-01124 Patent 6,629,226 B1 19 32:57-60. “Where a single clock drives all the systems and is coupled to RAM buffer controller, there is no problem.” Id. at 32:61-62. Such a system is shown in Fig. 1 of Joshi, where a single clock is derived from the incoming data stream and the clock signal is applied to all units of the system so all units are running synchronously. See id. at 32:63-66. Joshi further discloses that there are some applications where two systems need access to the buffer memory and run asynchronously, i.e., each has its own clock. See id. at 33:67-34:23. Joshi discloses that another useful feature is pipelined arbitration. See Ex. 1007, 32:30-31. Figure 15 of Joshi is reproduced below. Figure 15 depicts a timing diagram of pipelined arbitration of service requests. See Ex. 1007, 7:34-36, 32:31-33. “The basic idea is to overlap the arbitration cycle with the second service cycle of each two cycle transfer just preceding the service cycle.” Id. at 32:33-35. Using pipelined arbitration, the winning request for the next memory access will have been determined by the arbitration circuitry by the completion of the service cycle for the winning request from the previous arbitration, i.e., by the completion of the service cycle for the current memory access. See id. at 7:5-8. Joshi discloses that packets may be transferred in a back-to-back fashion without IPR2020-01124 Patent 6,629,226 B1 20 the need for waiting for arbitrations to be completed between packets. See id. at 7:9-11. 2. Analysis a. Claim 1 1. An interface coupled to a multiqueue storage device and; Petitioner contends that Joshi discloses “[a]n interface coupled to a multiqueue storage device,” as recited in claim 1, based on Joshi’s disclosure of RBC 44 and FORMAC 34, which constitute an interface, coupled with DPC 43 and BM 38, which constitute a multiqueue storage device. See Pet. 53-55 (reproducing Ex. 1007, Fig. 1 (with annotations); quoting Ex. 1007, 8:52-55, 8:57-64, 8:68-9:1; citing Ex. 1001, 3:35-40, 3:52-53, 5:3-5; Ex. 1003 ¶¶ 144-147, 151-153; Ex. 1007, Fig. 2, 3:60-63, 9:32-38, 10:1-7, 10:15-18, 10:37-41, 10:58-60, 10:62-11:14, 11:18-22, 15:49-56, 16:6-9, 20:21-21:3). Patent Owner contends that Joshi does not disclose a multiqueue storage device because DPC 43 does not organize BM 38 or data stored within BM 38 into queues, DPC 43 does not manage BM 38, and DPC 43 does not provide functionality similar to that provided by the ’226 Patent’s controller 156. See PO Resp. 47-57 (citations omitted). Patent Owner asserts that neither DPC 43 nor BM 38 organizes BM 38, or data stored within BM 38, into queues because “BM 38 simulates the operation of two buffer memories based on a data structure found solely within the RAM buffer controller (RBC) 44.” Id. at 48-49 (emphasis omitted, citing Ex. 2003 ¶ 142); see id. at 49 (citing Ex. 1007, 8:64-67; Ex. 2003 ¶¶ 142- 143). According to Patent Owner, “RBC 44 ‘maintains a set of pointer addresses stored in registers therein which can cause the buffer memory 38 IPR2020-01124 Patent 6,629,226 B1 21 to simulate the operation of two independently operating buffer memories.’” Id. at 49 (quoting Ex. 1007, 8:64-67 (Patent Owner’s emphasis omitted); citing Ex. 2003 ¶ 142). Patent Owner argues that, “[a]t most, Joshi discloses a buffer memory that is logically organized by the RBC 44--not the DPC 43 or BM 38--to simulate two buffer memories.” Id. (emphasis omitted, citing Ex. 2003 ¶ 142). Patent Owner contends that RBC 44 is the only entity that stores and implements data structures for organizing BM 38 into multiple buffers, but Petitioner does not allege that the RBC 44 forms the multiqueue storage device. See id. (citing Ex. 2003 ¶ 143; Pet. 53). Patent Owner also contends that DPC 43 does not manage BM 38 because DPC 43 only “controls the transmission of data over the shared data bus 46.” PO Resp. 51 (quoting Ex. 1007, 8:52-55; Ex. 2003 ¶ 147); see id. at 49-51 (reproducing Ex. 1007, Fig. 1 (with annotations); quoting Ex. 1007, 8:52-55, 9:8-12; citing Ex. 2003 ¶¶ 145-147; Ex. 2005, 160:25-161:9, 161:12-14); PO Sur-reply 16-17 (reproducing Ex. 1007, Fig. 1 (with annotations); quoting Ex. 1007, 9:8-12; citing Ex. 2003 ¶ 147). Patent Owner further asserts that DPC 43 does not manage BM 38 because “the DPC 43 itself must request access to perform read and write operations on data stored in the BM 38.” PO Resp. 51; see id. at 51-53 (quoting Ex. 1007, 10:26-27, 20:63-66, 25:16-17; Ex. 2005, 166:11-25, 172:14-173:7; citing ¶¶ 148-151); PO Sur-reply 11 (citing PO Resp. 51; Ex. 2003 ¶ 148). Patent Owner contends that Joshi discloses that DPC 43 must make requests to RBC 44 in order to access BM 38, and the access requests are arbitrated by logic in RBC 44. See PO Resp. 53-55 (quoting Ex. 1007, 8:57-64, 10:10-21; citing Ex. 2003 ¶¶ 152-155; Ex. 2005, 161:15-22, 168:1-5, IPR2020-01124 Patent 6,629,226 B1 22 172:14-173:7); see PO Sur-reply 11-12 (similar arguments, citing PO Resp. 54; Ex. 2003 ¶ 154). Patent Owner also asserts that DPC 43 does not provide the same functionality as the ’226 Patent’s controller 156 because DPC 43 serves the purpose of transferring data stored in BM 38 for transmission over shared data bus 46 and over medium 20 out of Joshi’s device. See PO Resp. 55-56 (quoting Pet. 54; Ex. 1003 ¶ 56; Ex. 1007, 8:20-28, 8:50-51; citing Ex. 1007, 8:52-55; Ex. 2003 ¶¶ 156-157). Patent Owner contends that DPC 43 does not control reading and writing to BM 38, but must request access to BM 38 to perform reads and writes of data stored in BM 38. See id. at 56-57 (quoting Ex. 1007, 20:63-66, 25:13-17; citing Ex. 1007, 10:16-21; Ex. 2003 ¶¶ 159-160; Ex. 2005, 172:14-173:7; incorporating by reference PO Resp. 47-57). Patent Owner contends that a person of ordinary skill in the art would not have understood DPC 43, which must request access to perform read and write operations in a memory, to control reads and writes to that memory. See id. at 57 (citing Ex. 2003 ¶ 161); see also PO Sur-reply 11 (similar argument). Petitioner asserts that Patent Owner’s arguments should be rejected because Patent Owner fails to tie its arguments distinguishing Joshi to any claim limitation. See Pet. Reply 9, 12. Petitioner contends that the claims do not require the multiqueue storage device to organize data into queues or to include logic for organizing data into queues. See id. Petitioner further contends that “nothing in the claims or in the ordinary meaning of ‘multiqueue storage device’ requires any minimum level of access or communication between the components that make up the [multiqueue storage device].” Id. at 10; see id. at 10-11 (case citations omitted). IPR2020-01124 Patent 6,629,226 B1 23 We are persuaded by Petitioner’s arguments that Joshi discloses an interface to a multiqueue storage device. We do not agree with Patent Owner’s arguments to the contrary, because, as explained above in § II.B.1., we do not adopt Patent Owner’s implicit constructions for “multiqueue storage device.” As such, it is immaterial whether Joshi’s DPC 43 itself organizes, manages, controls access to, or controls reads and writes to BM 38. Consistent with our construction of “multiqueue storage device” as “a storage device having data organized into multiple queues,” discussed above in § II.B.1., we are persuaded by Petitioner’s showing that Joshi’s BM 38 and DPC 43 constitute “a storage device that has data organized into multiple queues” because BM 38 is configured to hold two FIFO queues. See Pet. 54 (quoting Ex. 1007, 8:68-9:1; citing Ex. 1007, 3:60-63). Indeed, Patent Owner acknowledges that Joshi’s BM 38 is organized into multiple buffers. See PO Resp. 49 (“RBC 44 ‘maintains a set of pointer addresses stored in registers therein which can cause the buffer memory 38 to simulate the operation of two independently operating buffer memories,’” and “RBC 44 . . . stores and implements the data structures for organizing the BM 38 into multiple buffers.” (quoting Ex. 1007, 8:64-67 (Petitioner’s emphasis omitted); citing Ex. 2003 ¶¶ 142-143)). Based on the entire trial record, we find that Joshi discloses “[a]n interface coupled to a multiqueue storage device,” as recited in claim 1. 2. configured to interface said multiqueue storage device with one or more handshaking signals Petitioner contends that Joshi discloses this limitation based on Joshi’s disclosures of: (1) starting the reading of packets from BM 38 based on a valid data signal; (2) RBC 44 exchanging address request, address valid, and IPR2020-01124 Patent 6,629,226 B1 24 other handshake signals with DPC 43 and BM 38 via buses 64 and 41; and (3) the depiction in Figure 2 of handshake signals between DPC 43 and RBC 44. See Pet. 55-56 (reproducing Ex. 1007, Fig. 2 (with annotations); quoting Ex. 1007, 9:33-38; citing Ex. 1007, 10:15-18, 10:58-60, 10:62- 11:4; Ex. 1003 ¶¶ 148-149). Patent Owner does not dispute Petitioner’s assertions addressing this limitation. See PO Resp. 47-68. Nonetheless, the burden remains on Petitioner to demonstrate unpatentability. See Dynamic Drinkware, LLC v. Nat’l Graphics, Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015). Based on the entire trial record, we find that Joshi discloses the interface is “configured to interface said multiqueue storage device with one or more handshaking signals,” as recited in claim 1 for the reasons discussed in the Petition. See Pet. 55-56. 3. wherein said multiqueue storage device and said interface are configured to transfer variable size data packets and Petitioner contends that Joshi discloses this limitation based on Joshi’s disclosure of an algorithm for storing normally received packets that allows status and length information to be written to the memory location preceding the first byte of the received packet, regardless of how long the packet is or whether the length is known, and Joshi’s disclosure that received packets could contain one or more bytes of data. See Pet. 56-57 (reproducing Ex. 1007, Fig. 1 (with annotations); quoting Ex. 1007, 5:31-35, 20:18-21; citing Ex. 1007, 11:1-4, 16:6-9, 23:7-11, 23:14-16; Ex. 1003 ¶¶ 62, 150). Petitioner further asserts that BM 38 is configured to transfer variable size data packets to DPC 43, which then transfers them to FORMAC 34. See id. at 57 (citing Ex. 1007, 11:1-4, 16:6-9, Fig. 1; Ex. 1003 ¶ 150). IPR2020-01124 Patent 6,629,226 B1 25 Patent Owner contends that Petitioner’s identified disclosures of Joshi do not disclose variable data size packets. See PO Resp. 65 (quoting Pet. 56; Ex. 1007, 5:31-35, 20:18-20; citing Ex. 1003 ¶ 150; Ex. 2003 ¶ 176). According to Patent Owner, a person of ordinary skill in the art “in December 2000 would not understand a mechanism for storing length information, or the mere existence of single- or multiple-byte packets, to disclose variable size packets.” Id. at 65-66 (citing Ex. 2003 ¶ 176). Patent Owner asserts that a length field merely provides a single place where length information is stored and “does not mean that each packet[] may have a different length, any more than merely providing everyone at a party with a nametag means that every attendee may have a different name.” Id. at 66 (quoting Ex. 1007, 5:31-34; citing Ex. 2003 ¶ 177). According to Patent Owner, “the value in the length field may be the same if every packet is the same length.” Id. (quoting Ex. 2005, 199:21-24; citing Ex. 2003 ¶ 178). Patent Owner further contends that a person of ordinary skill in the art “in December 2000 would not understand Joshi’s provision of a length field at the beginning of a packet in order ‘to simplify software overhead’ . . . to mean that all packets passing through Joshi’s device comprise different sizes.” Id. at 66-67 (quoting Dec. 19; citing Ex. 2003 ¶ 178). Patent Owner further contends that a person of ordinary skill in the art “would understand Joshi’s recitation that packets may include ‘one or more bytes’ to mean merely that the packets may have a length of a single byte, or a length of multiple bytes.” PO Resp. 67 (citing Pet. 56; Ex. 2003 ¶ 179; Ex. 2005, 202:10-17); see PO Sur-reply 23 (similar argument). Patent Owner asserts that the phrase “one or more bytes” by itself does not imply that each packet processed by Joshi is a different length. See PO Resp. 67 IPR2020-01124 Patent 6,629,226 B1 26 (citing Ex. 2003 ¶ 180); see also PO Sur-reply 23-24 (similar argument). According to Patent Owner, “[e]very single packet processed by Joshi’s system could be the same size.” PO Resp. 67 (citing Ex. 2003 ¶ 180; Ex. 2005, 204:16-205:6). Patent Owner further asserts that Petitioner does not show that Joshi discloses all elements of the claims within the four corners of the document. See PO Resp. 67 (quoting Microsoft Corp. v. Biscotti, Inc., 878 F.3d 1052, 1068 (Fed. Cir. 2017)). Patent Owner contends that: (1) Petitioner “does not show that Joshi explicitly discloses the capability to transfer or allow for variable size data packets”; and (2) “Joshi is silent as to whether packets can vary in size, or whether Joshi’s system is configured to allow for packets that vary in size.” Id. (citing Ex. 2003 ¶ 181); see PO Sur-reply 24 (similar argument, citing PO Resp. 66-67; Ex. 2003 ¶¶ 176-181). Patent Owner asserts that Petitioner and Dr. Melvin do not “allege that Joshi inherently or implicitly discloses the ‘variable sized data packets’ limitation.” PO Resp. 67-68 (citing Ex. 2005, 70:7-14). In the Reply, Petitioner contends that “a person of ordinary skill in the art reviewing Joshi would have understood that it disclosed a system that was configured to transfer and configured to allow reads of variable size data packets.” Pet. Reply 16 (quoting Ex. 2005, 214:11-15; citing Ex. 1003 ¶ 150; Ex. 2005, 198:20-199:2, 200:10-23, 213:20-214:17, 214:24-215:24, 216:13-16). Petitioner asserts that Patent Owner’s contention that every single packet processed by Joshi’s system could be the same size is not a distinction over the ’226 Patent claims and is irrelevant because, as explained by Dr. Melvin, Joshi is capable of handling variable size data IPR2020-01124 Patent 6,629,226 B1 27 packets, which satisfies the relevant claim limitations. See id. (quoting PO Resp. 67; Ex. 2005, 205:2-3). In the Sur-reply, Patent Owner contends that Petitioner points to no disclosure in Joshi that supports Petitioner’s conclusion regarding the understanding of a person of ordinary skill in the art. See PO Sur-reply 23 (quoting Pet. Reply 16). According to Patent Owner, “the length of a packet is information that the receiver needs to know when the data of a particular packet ends. It does not mean--and Joshi does not disclose--that the information in the length field (i.e., length of a packet) will change.” Id. We find Petitioner has shown how Joshi meets this limitation for the reasons stated in the Petition and Petitioner’s Reply. We do not agree with Patent Owner’s arguments. Patent Owner’s arguments focus on whether Joshi discloses “variable size data packets,” instead of the full claim language “configured to transfer variable size data packets,” and “configured to allow . . . reads of variable size data packets,” as pointed out by Petitioner. The claim language requires RBC 44, FORMAC 34, DPC 43, and BM 38 to be configured, or have the capacity, to transfer or allow reads of variable size data packets. Petitioner’s showing that Joshi’s algorithm for storing normally received packets allows status and length information to be written to the memory location preceding the first byte of the received packet, regardless of how long the packet is or whether the length is known, and that Joshi discloses receiving and transmitting packets that could contain one or more bytes of data is sufficient to demonstrate that Joshi’s RBC 44, FORMAC 34, DPC 43, and BM 38 are configured to transfer and allow reads of data packets that can have variable size. See Ex. 1007, 5:31-35, 11:1-4, 16:6-9, 20:18-21, 23:7-11, 23:14-16, Fig. 1. IPR2020-01124 Patent 6,629,226 B1 28 Based on the entire trial record, we find that Joshi discloses “wherein said multiqueue storage device and said interface are configured to transfer variable size data packets,” as recited in claim 1. 4. said multiqueue storage device is configured to generate an address request signal. Petitioner asserts that Joshi discloses this limitation based on Joshi’s disclosure of DPC 43 sending DRDREQS (read request synchronous), DRDREQA (read request asynchronous) signals to RBC 44, which causes RBC 44 to send the next packet address to BM 38. See Pet. 57-58 (reproducing Ex. 1007, Fig. 13 (with annotations); quoting Ex. 1007, 15:57-59, 16:3-6; citing Ex. 1007, 10:37-41, 15:49-56, 32:1-15, Fig. 2; Ex. 1003 ¶¶ 151-152). Patent Owner initially argues, based on its previous arguments addressing Joshi’s disclosure of a multiqueue storage device (see § II.D.2.a.1.), that because Joshi’s DPC 43 does not comprise a multiqueue storage device, Joshi does not disclose “said multiqueue storage device is configured to generate an address request signal.” See PO Resp. 57-58 (quoting Ex. 2005, 174:13-20; citing Pet. 57; Ex. 1003 ¶ 151; Ex. 2003 ¶¶ 162-164; Ex. 2005, 174:9-12; incorporating by reference PO Resp. 47-57); PO Sur-reply 19 (incorporating by reference PO Sur-reply 2-10). Petitioner asserts that Patent Owner’s argument should be rejected because Joshi does teach a multiqueue storage device. See Pet. Reply 13 (citing PO Resp. 58; incorporating by reference Pet. Reply 9-13). For the same reasons as those explained above in § II.D.2.a.1., we do not agree with Patent Owner’s argument that Joshi does not disclose a multiqueue storage device. Therefore, Patent Owner’s additional argument IPR2020-01124 Patent 6,629,226 B1 29 premised on its previous multiqueue storage device argument is unavailing for the same reason. Patent Owner also argues that DRDREQS and DRDREQA signals do not disclose an address request signal because the DRDREQS and DRDREQA signals do not request an address. See PO Resp. 58-59 (quoting Ex. 2005, 97:15-18; citing Ex. 2003 ¶¶ 165-166). According to Patent Owner, Joshi clearly discloses that the DRDREQS, DRDREQA are read requests, not address requests: “This request from the data path controller takes the form of assertion of the signal DRDREQS or DRDREQA in FIG. 2. These two signals stand for data path controller read request synchronous and data path controller read request asynchronous.” PO Resp. 59 (quoting Ex. 1007, 15:52-56; citing Ex. 2003 ¶ 166). Patent Owner further contends that DRDREQS and DRDREQA are service requests that request data to be read from BM 38. See id. (quoting Ex. 1007, 15:49-52; citing Ex. 2003 ¶ 167). Patent Owner asserts that DRDREQS and DRDREQA are not address request signals because they are exchanged with RBC 44 for arbitration among other access requests. See PO Resp. 60-61 (reproducing Ex. 1007, Fig. 2 (with annotations); quoting Ex. 1007, 10:15-21, 10:37-44; citing Ex. 2003 ¶ 168). Patent Owner contends that assertion of DRDREQS and DRDREQA does not result in a return of an address at all, but results in an award of priority for requests. See id. at 61-62 (quoting Ex. 1007, 29:58-66; citing Ex. 2003 ¶ 169). Patent Owner asserts that after DPC 43 is awarded priority, RBC 44 asserts the data path controller read request acknowledge signal (DRDACKS). See id. at 62 (citing Ex. 1007, 30:3-6; Ex. 2003 ¶ 170). According to Patent Owner, IPR2020-01124 Patent 6,629,226 B1 30 it is the read request acknowledge signal DRDACKS, not the read request signal DRDREQS, that causes control logic 125 in the RBC 44 to return an RPC pointer: “The assertion of the data path controller acknowledge signal, DRDACKS, at 234 causes the control logic to send a select signal to the G multiplexer, causing it to select the contents of the RPX pointer storage register for output on the address bus 40.” PO Resp. 62 (quoting Ex. 1007, 30:12-16; citing Ex. 2003 ¶ 170). Patent Owner contends that Joshi discloses multiple intervening steps between the assertion of the read request signals DRDREQS and DRDREQA and the eventual output of the RPX pointer. See id. at 62-63 (quoting Ex. 2005, 184:12-15; citing Ex. 2003 ¶¶ 171-172; Ex. 2005, 191:9-24); see also PO Sur-reply 22 (similar argument, quoting Ex. 2003 ¶ 171; Ex. 2005, 191:9-24; citing PO Resp. 61-64). According to Patent Owner, “[g]iven these intervening steps between a signal Joshi itself describes as a read request signal and the output of an RPX pointer, a POSITA in December 2000 would not understand the DRDREQS or DRDREQA read request signals to disclose address request signals.” PO Resp. 64 (citing Ex. 2003 ¶ 173). Patent Owner asserts that if DRDACKS and DRDACKA are never asserted, the RPX pointer will never be output. See id. (citing Ex. 2003 ¶ 173); PO Sur-reply 20 (citing Ex. 2003 ¶ 173). Patent Owner contends that the generation of the RPX pointer is dependent upon the assertion of the DRDACKS and DRDACKA, not DRDREQS and DRDREQA. See PO Resp. 64 (citing Ex. 2003 ¶ 173); PO Sur-reply 20 (citing Ex. 2003 ¶ 173), 22. In the Reply, Petitioner contends that Dr. Melvin explained repeatedly that each of DRDREQS and DRDREQA signals is a request for an address for a read. See Pet. Reply 13-14 (quoting Ex. 2005, 193:1-4; citing IPR2020-01124 Patent 6,629,226 B1 31 Ex. 2005, 176:11-177:20, 179:13-21, 185:25-188:4, 192:15-193:4). According to Petitioner, “Joshi disclosed the DRDREQS and DRDREQA signals were address request signals and need not further label them as such.” See id. at 14 (quoting VirtnetX Inc. V. Apple Inc., 655 F. App’x 880, 886 (Fed. Cir. 2016); In re Gleave, 560 F.3d 1331, 1334 (Fed. Cir. 2009)). Petitioner further argues that Dr. Melvin explains that the DRDACKS and DRDACKA signals are generated in response to the DRDREQS and DRDREQA signals, which initiate a sequence of steps that is guaranteed to result in an address being generated one cycle later. See id. at 14 (citing Ex. 2005, 182:6, 188:6-190:20, 192:1-13). According to Petitioner, “Patent Owner’s own expert agreed that absent interrupts or a power failure, the address will issue in response to DRDREQS or DRDREQA.” Id. (citing Ex. 2005, 190:6-11, 190:15-20; Ex. 1012, 107:20-109:20) In the Sur-reply, Patent Owner contends that Petitioner points to no disclosure in Joshi that supports Petitioner’s conclusion that DRDREQS and DRDREQA are requests for an address for a read. See PO Sur-reply 20 (citing Pet. Reply 13-14). Patent Owner asserts that Dr. Melvin testifies that DRDREQS results in an award of priority and Petitioner and Dr. Melvin admit that DRDACKS and DRDACKA are generated in response to DRDREQS and DRDREQA. See id. at 20-21 (quoting Ex. 2005, 180:7-22; Pet. Reply 14). According to Patent Owner, “the undisputed fact that interrupts, which are amongst the most common occurrences in computer systems, will prevent the issuance of [an address] is a dispositive fact that would inform a [person of ordinary skill in the art] that an RPX pointer is not generated in response to the DRDACKS and DRDACKA signals.” Id. at 21. Patent Owner asserts that Petitioner misrepresents Dr. Bagherzadeh’s IPR2020-01124 Patent 6,629,226 B1 32 testimony because Dr. Bagherzadeh explains that there are multiple other events that would prevent the issuance of an RPX pointer address. See id. at 21-22 (quoting Ex. 1012, 107:20-109:1). We are persuaded by a preponderance of the evidence that Joshi’s DRDREQA and DRDREQS signals asserted by DPC 43 disclose address request signals because they cause RBC 44 to send the next packet address to BM 38.5 See Ex. 1007, 10:37-41, 15:49-59, 16:3-6, 31:18-22, 32:1-15, Figs. 2, 14. Contrary to Patent Owner’s suggestions, the claim language requiring the interface to be “configured to generate an address request signal” does not require an address to be returned in direct response to the request signal. Nor does the claim language preclude intervening steps between the generation of a request signal and the return of an address responsive to the request signal. Indeed, the ’226 Patent discloses multiple intervening steps between when controller 156 sends ADDR_REQ (@SYSCLK) signal and the return of ADDRESS@SYSCLK signal to controller 156. See Ex. 1001, 5:3-14, 5:31-6:55, Figs. 5-6. Based on the entire trial record before us, we find that Joshi discloses “said multiqueue storage device is configured to generate an address request signal,” as recited in claim 1. 5 We need not address Petitioner’s position that Joshi’s LDRPXS (load synchronous RPX (read points)) and LDRPXA (load asynchronous RPX (read points)) signals also disclose this claim limitation because we are persuaded by Petitioner’s showing based on Joshi’s DRDREQA and DRDREQS signals. See Pet. 57-59; PO Resp. 64-65; Pet. Reply 15; PO Sur-reply 23. IPR2020-01124 Patent 6,629,226 B1 33 5. Summary For the foregoing reasons, and after having analyzed the entirety of the record and assigning appropriate weight to the cited supporting evidence, we determine that Petitioner has established by a preponderance of the evidence that claim 1 is unpatentable under 35 U.S.C. § 102(b) as anticipated by Joshi. b. Independent Claim 19 Claim 19 is a method claim similar in scope to claim 1. Compare Ex. 1001, 10:59-65, with Ex. 1001, 9:52-58. Petitioner asserts that, if the preamble is considered limiting, Joshi teaches a hardware configuration and how to provide a read data protocol for a multiqueue storage device that uses handshaking signals. See Pet. 75 (citing Ex. 1003 ¶ 184; incorporating by reference Pet. 53-59 (claim 1), 63 (claim 4), 67-68 (claim 9), 70-73 (claim 11)). Aside from its arguments addressing “multiqueue storage device,” “said multiqueue storage device is configured to generate an address request signal,” and “variable length data packets,” common to independent claims 1 and 19, Patent Owner does not specifically address any additional limitations of claim 19. See PO Resp. 47-68. Nonetheless, the burden remains on Petitioner to demonstrate unpatentability. See Dynamic Drinkware, 800 F.3d at 1378. For the same reasons as those explained above addressing claim 1, based on the entire trial record, we determine that Petitioner has established by a preponderance of the evidence that claim 19 is unpatentable under 35 U.S.C. § 102(b) as anticipated by Joshi. IPR2020-01124 Patent 6,629,226 B1 34 c. Dependent Claim 2 Dependent claim 2 recites “wherein said multiqueue storage device and said interface are configured to allow back-to-back reads of said variable size data packets.” Ex. 1001, 9:52-58. Petitioner asserts that Joshi discloses this limitation based on the following disclosures: (1) RBC 44 arbitrates pipelined requests from node processor 52, DPC 43, and host system 36 for access by way of a DMA transfer to or from BM 38; (2) pipelining allows RBC 44 to process the current request while simultaneously arbitrating the next request; and (3) arbitrating pipelined requests allows packets to be transferred back-to-back without waiting for arbitrations to be completed between packet transfers. See Pet. 59 (citing Ex. 1007, 7:9-11, 10:9-15, 32:30-54, Fig. 15; Ex. 1003 ¶¶ 61, 154). Petitioner contends that pipelined (i.e., back-to-back) DPC 43 requests are always processed back-to-back because DPC 43 requests have highest priority in Joshi’s arbitration scheme. See id. at 59-60 (citing Ex. 1007, 13:35-36). Petitioner further asserts that pipelined DPC 43 requests cannot be interrupted by requests from other system elements because they are processed immediately upon completion of service of the prior request. See id. at 60 (quoting Ex. 1007, 32:53-54; citing Ex. 1003 ¶ 155). Petitioner further asserts that Joshi depicts back-to- back processing in Figure 13. See id. (reproducing Ex. 1007, Fig. 13 (with annotations); citing Ex. 1007, 31:53-32:13, Fig 14; Ex. 1003 ¶ 156). We find Petitioner has shown how Joshi discloses this limitation for the reasons stated in the Petition. Other than its arguments addressing “multiqueue storage device,” “said multiqueue storage device is configured to generate an address request signal,” and “variable length data packets,” Patent Owner does not specifically dispute Petitioner’s challenge of claim 2 IPR2020-01124 Patent 6,629,226 B1 35 based on Joshi. See PO Resp. 47-68. Nonetheless, the burden remains on Petitioner to demonstrate unpatentability. See Dynamic Drinkware, 800 F.3d at 1378. Therefore, in addition to the reasons explained above addressing claim 1, based on the entire trial record, we determine that Petitioner has established by a preponderance of the evidence that claim 2 is unpatentable under 35 U.S.C. § 102(b) as anticipated by Joshi. d. Independent Claims 12 and 18 Independent claim 12 is a method claim, and independent claim 18 is a device claim. Ex. 1001, 10:28-34; 10:54-58. Independent claims 12 and 18, similar to dependent claim 2, each recite “wherein said multiqueue storage device and said interface are configured to allow back-to-back reads of said variable size data packets.” Id. Petitioner’s assertions addressing the limitations of claims 12 and 18 are similar to Petitioner’s assertions addressing claims 1 and 19, and further incorporate by reference Petitioner’s assertions addressing dependent claim 2. See Pet. 73-75 (citing Ex. 1007, 20:6-21:49, 31:10-32:29; Ex. 1003 ¶¶ 177, 183). We find these assertions persuasively demonstrate how Joshi discloses all the limitations of claims 12 and 18 for the reasons stated above regarding claims 1, 2, and 19. See §§ II.D.2a-2c, supra. Aside from its arguments addressing “multiqueue storage device,” “said multiqueue storage device is configured to generate an address request signal,” and “variable size data packets,” Patent Owner does not specifically dispute Petitioner’s challenges to claims 12 and 18 based on Joshi. See PO Resp. 47-68. Nonetheless, the burden remains on Petitioner to demonstrate unpatentability. See Dynamic Drinkware, 800 F.3d at 1378. IPR2020-01124 Patent 6,629,226 B1 36 For the same reasons as those explained above addressing claims 1, 2, and 19, based on the entire trial record, we determine that Petitioner has established by a preponderance of the evidence that claims 12 and 18 are unpatentable under 35 U.S.C. § 102(b) as anticipated by Joshi. e. Dependent Claims 3-10 and 13-17 Claims 3-10 depend from independent claim 1, and claims 13-17 depend from independent claim 12. Ex. 1001, 9:62-10:21, 10:35-53. We have reviewed Petitioner’s contentions and supporting evidence addressing how Joshi discloses the additional limitations recited in dependent claims 3-10 and 13-17. See Pet. 61-70, 73-74 (citations omitted). Based on the record before us, Petitioner establishes sufficiently that Joshi discloses each of the additional limitations recited in dependent claims 3-10 and 13-17 for the reasons stated in the Petition. Patent Owner does not address substantively Petitioner’s patentability challenges to dependent claims 3-10 and 13-17 based on Joshi. See PO Resp. 47-68. Nonetheless, the burden remains on Petitioner to demonstrate unpatentability. See Dynamic Drinkware, 800 F.3d at 1378. For these reasons, in addition to those explained above addressing independent claims 1 and 12, based on the entire trial record, we determine that Petitioner has established by a preponderance of the evidence that claims 3-10 and 13-17 are unpatentable under 35 U.S.C. § 102(b) as anticipated by Joshi. f. Independent Claim 11 Independent claim 11 is a device claim that recites two means-plus- function limitations. Ex. 1001, 10:22-27. As explained above in § II.B.2., we need not construe “means for interfacing a multiqueue storage device” IPR2020-01124 Patent 6,629,226 B1 37 and “means for interfacing with one or more handshaking signals,” beyond finding the corresponding structure to be an “interface.” Petitioner’s assertions addressing the limitations of claim 11 are similar to its assertions addressing the limitations of claim 1, and further incorporate by reference its assertions addressing “configured to transfer variable size data packets” of claim 1 and “configured to allow back-to-back reads of said variable size data packets” of dependent claim 2. See Pet. 70-73 (reproducing Ex. 1001, Fig. 4 (with annotations); Ex. 1007, Fig. 1 (with annotations); citing Ex. 1007, 10:15-18, 11:18-22, 15:45-49, 16:6-9, 20:18-21, 26:48-53, 27:40-43, 31:55-32:13; Ex. 1003 ¶¶ 173-175; incorporating by reference Pet. 56-57, 59-60). Specifically, Petitioner contends that Joshi’s disclosure of RBC 44 and FORMAC 34 disclose the claimed “means for interfacing a multiqueue storage device” and “means for interfacing with one or more handshaking signals,” and Joshi’s DPC 43 and BM 38 disclose a multiqueue storage device. See id. at 70-72. Other than its arguments addressing “multiqueue storage device,” and “variable size data packets,” also recited in claim 11, Patent Owner does not specifically dispute Petitioner’s challenge to claim 11 based on Joshi. See PO Resp. 47-68. Nonetheless, the burden remains on Petitioner to demonstrate unpatentability. See Dynamic Drinkware, 800 F.3d at 1378. We are persuaded by a preponderance of the evidence that Joshi’s DPC 43 and BM 38 disclose a multiqueue storage device and Joshi’s RBC 44 and FORMAC 34 disclose “means for interfacing a multiqueue storage device” and “means for interfacing with one or more handshaking signals.” See Ex. 1007, 10:15-18, 11:18-22, 15:45-49, 16:6-9, 20:18-21, 26:48-53, 27:40-43, 31:55-32:13, Fig. 1. We also are persuaded by a IPR2020-01124 Patent 6,629,226 B1 38 preponderance of the evidence that Joshi discloses DPC 43, BM 38, RBC 44, and FORMAC 34 are configured to allow back-to-back reads of variable size data packets. See Ex. 1007, 5:31-35, 7:9-11, 10:9-15, 11:1-4, 13:35-36, 16:6-9, 20:18-21, 23:7-11, 23:14-16, 31:53-32:13, 32:30-54, Figs. 1, 13, 14, 15. For these reasons, including the reasons explained above addressing claims 1 and 2, based on the entire trial record, we determine that Petitioner has established by a preponderance of the evidence that claim 11 is unpatentable under 35 U.S.C. § 102(b) as anticipated by Joshi. E. Challenges to Claims 1-19 Based on Chang, Chang and APA, and Chang, Joshi, and optionally APA Petitioner also challenges claims 1-4 and 7-19 under 35 U.S.C. § 102(b) as anticipated by Chang, claims 1-4, 7-10, 14, 15, and 19 under 35 U.S.C. § 103(a) as obvious over Chang and APA, and claims 5, 6, and 16 under 35 U.S.C. § 103(a) as obvious over Chang, Joshi, and optionally APA. See Pet. 20-52. We need not determine the merits of those challenges because, as explained above, Petitioner has demonstrated the unpatentability of those claims as anticipated by Joshi. See Beloit Corp. v. Valmet Oy, 742 F.2d 1421, 1423 (Fed. Cir. 1984) (finding an administrative agency is at liberty to reach a decision based on a single dispositive issue because doing so “can not only save the parties, the [agency], and [the reviewing] court unnecessary cost and effort,” but can “greatly ease the burden on [an agency] faced with a . . . proceeding involving numerous complex issues and required by statute to reach its conclusion within rigid time limits”). IPR2020-01124 Patent 6,629,226 B1 39 III. PETITIONER’S MOTION TO EXCLUDE EVIDENCE Petitioner moves to exclude Exhibits 2006-2017 under 37 C.F.R. § 42.23(b) and Rules 401-403 of the Federal Rules of Evidence. See Mot. 1-2; Reply Opp. 1-2. Patent Owner opposes the Motion. See Opp. It is unnecessary to resolve this evidentiary dispute because we have determined that Petitioner prevails even when considering Exhibits 2006- 2017. Thus, we dismiss as moot Petitioner’s Motion to Exclude Exhibits 2006-2017. IV. CONCLUSION6 For the reasons explained above, we conclude: Claim(s) 35 U.S.C. § Reference(s)/Basis Claim(s) Shown Unpatentable Claim(s) Not Shown Unpatentable 1-19 102(b) Joshi 1-19 1-4, 7-19 102(b) Chang 1-4, 7-10, 14, 15, 19 103(a) Chang and the APA 5, 6, 16 103(a) Chang and Joshi, and optionally the APA Overall Outcome 1-19 6 Should Patent Owner wish to pursue amendment of the challenged claims in a reissue or reexamination proceeding subsequent to the issuance of this decision, we draw Patent Owner’s attention to the April 2019 Notice Regarding Options for Amendments by Patent Owner Through Reissue or Reexamination During a Pending AIA Trial Proceeding. See 84 Fed. Reg. 16,654 (Apr. 22, 2019). If Patent Owner chooses to file a reissue application or a request for reexamination of the challenged patent, we remind Patent Owner of its continuing obligation to notify the Board of any such related matters in updated mandatory notices. See 37 C.F.R. § 42.8(a)(3), (b)(2). IPR2020-01124 Patent 6,629,226 B1 40 V. ORDER In consideration of the foregoing, it is hereby: ORDERED that claims 1-19 are unpatentable; FURTHER ORDERED that Petitioner’s Motion to Exclude Exhibits 2006-2017 is dismissed as moot; and FURTHER ORDERED that, because this is a Final Written Decision, parties to the proceeding seeking judicial review of the decision must comply with the notice and service requirements of 37 C.F.R. § 90.2. IPR2020-01124 Patent 6,629,226 B1 41 PETITIONER: Douglas R. Wilson Michelle E. Armond Forrest M. McClellen ARMOND WILSON LLP doug.wilson@armondwilson.com michelle.armond@armondwilson.com forrest.mcclellen@armondwilson.com PATENT OWNER: Theodoros Konstantakopoulos Kevin McNish Ryan G. Thorne DESMARAIS LLP tkonstantakopoulos@desmaraisllp.com kkm-ptab@desmaraisllp.com rthorne@desmaraisllp.com