throbber
Trials@uspto.gov
`571-272-7822
`
`
`Paper 8
`Date: March 14, 2024
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`TCL INDUSTRIES HOLDINGS CO. LTD,
`Petitioner,
`v.
`ATI TECHNOLOGIES ULC,
`Patent Owner.
`
`IPR2024-00366
`Patent 8,760,454 B2
`
`
`
`
`
`
`
`
`
`Before JAMES P. CALVE, BRIAN J. McNAMARA, and
`KEVIN W. CHERRY, Administrative Patent Judges.
`McNAMARA, Administrative Patent Judge.
`
`DECISION
`Granting Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`
`
`
`
`
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`
`I.
`INTRODUCTION
`On January 2, 2024, TCL Industries Holdings Co., Ltd. (“Petitioner”)
`filed a petition, Paper 1 (“Petition” or “Pet.”), to institute an inter partes
`review (“IPR”) of claims 1–11 (the “challenged claims”) of U.S. Patent No.
`8,760,454 B2 (“the ’454 patent”). 35 U.S.C. § 311. Petitioner also filed a
`Motion For Joinder with Realtek Semiconductor Corp. v. ATI Technologies
`ULC, IPR2023-00922 (“the Realtek IPR”). Paper 3 (“Motion For Joinder”
`or “Mot.”).1 Petitioner’s Motion for Joinder states that Petition relies on the
`identical arguments and grounds and the same expert opinions and testimony
`as those asserted by the petitioner (Realtek) in the petition filed in the
`Realtek IPR. Mot. 3–4. We instituted trial in the Realtek IPR on December
`1, 2023 and entered a scheduling Order in the Realtek IPR on December 5,
`2023. Realtek IPR, Papers 10, 11.
`In this proceeding, a Notice of Filing Date Accorded was entered on
`January 18, 2024, setting the due date for Patent Owner’s Preliminary
`Response to April 18, 2024. On February 2, 2024, ATI Technologies ULC
`(“Patent Owner”) filed a Response to Petitioner’s Motion for Joinder in
`which Patent Owner did not object to the joinder, given Petitioner’s
`agreement to assume an understudy role in a joined proceeding. Paper 7.
`We recognize Patent Owner’s acquiescence to joinder as effectively
`acknowledging that the challenges asserted by TCL are identical to those in
`
`
`1 In this Decision, citations to papers in the Realtek IPR are preceded with
`“Realtek IPR,” e.g., the Decision to Institute in the Realtek IPR is cited as
`“Realtek IPR Dec. to Inst.,” the Preliminary Response in the Realtek IPR is
`cited as “Realtek IPR Prelim. Resp.,” and the Petition in the Realtek IPR is
`cited as “Realtek IPR Pet.”
`
`2
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`the Realtek IPR and waiving the filing of a Preliminary Response in this
`proceeding. Therefore, we proceed to this Decision.
`We have jurisdiction under 35 U.S.C. § 6. This Decision on
`Institution is issued pursuant to 35 U.S.C. § 314, which provides that an
`inter partes review may not be instituted unless the information presented in
`the Petition “shows that there is a reasonable likelihood that the Petitioner
`would prevail with respect to at least 1 of the claims challenged in the
`petition.”
`A decision to institute under § 314 may not institute on fewer than all
`claims challenged in the petition. SAS Inst., Inc. v. Iancu, 138 S. Ct. 1348,
`1359–60 (2018). In addition, per Board practice, if the Board institutes trial,
`it will institute “on all of the challenged claims and on all grounds of
`unpatentability asserted for each claim.” See 37 C.F.R. § 42.108(a).
`Having considered the arguments and the associated evidence
`presented in the Petition and in the Realtek IPR, we institute inter partes
`review.
`
`II.
`REAL PARTIES IN INTEREST
`The Petition identifies TCL Industries Holdings Co., Ltd. (“TCL”)
`and TCL Industries Holdings (H.K.) Limited; TCL Electronics Holdings
`Limited; TCL Technology Group Corporation; TTE Corporation; TCL
`Holdings (BVI) Limited; TCL King Electrical Appliances (Huizhou) Co.,
`Ltd.; Shenzhen TCL New Technology Co., Ltd.; TCL MOKA International
`Limited; TCL Smart Device (Vietnam) Co., Ltd., Manufacturas Avanzadas
`SA de CV; TCL Electronics Mexico, S de RL de CV; TCL Overseas
`Marketing Ltd., and TTE Technology, Inc. as real parties-in-interest. Pet. 1–
`2.
`
`3
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`Patent Owner identifies ATI Technologies ULC as its real party-in-
`interest. Paper 5, 1.
`
`III. RELATED MATTERS
`Petitioner and Patent Owner identify the following proceedings as
`ones that may affect or be affected by a decision in this proceeding:
`Advanced Micro Devices, Inc. et al v. TCL Industries Holdings
`Co., Ltd. et al, C.A. No. 2:22-cv-00134 (E.D. Tex. May 5, 2022)
`(“the AMD Litigation”); and
`Certain Graphics Systems, Components Thereof, and Digital
`Televisions Containing the Same, Inv. No. 337-TA-1318 (“the
`ITC Investigation”);
`Realtek Semiconductor Corp. v. ATI Technologies ULC, No.
`IPR2023- 00922;
`Pet. 2–3, Paper 5, 1. Petitioner states that “the asserted patent claims were
`terminated by Order No. 10 on July 14, 2022 upon motion of ATI” and “the
`target date for completion of the investigation is January 23, 2024.” Pet. 2–
`3. AMD litigation is stayed pending final resolution of the ITC
`Investigation, expected on or about November 7, 2023. Id.
`IV. THE ’454 PATENT
`The ’454 patent concerns a graphics processing architecture that
`employs a single or “unified shader,” i.e., a shader that “is configured to
`perform both vertex and pixel operations.” Ex. 1001, 1:32–33, 3:10–12.
`The ’454 patent explains that, in computer graphics, complex shapes and
`structures are formed by sampling, interconnecting, and rendering simpler
`objects, e.g., triangles or other suitable polygons, called primitives. Id. at
`1:38–42. Primitives are formed by interconnecting individual pixels. Id. at
`1:42–43. In order to render an object for display, based on the location of
`the pixels within the primitives and the primitives’ orientation with respect
`
`4
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`to the desired shape, color and texture are applied to the individual pixels
`that make up the shape to be generated. Id. at 1:42–48.
`Graphics processors that interconnect the primitives and apply color
`and textures to the generated shapes include a series of shaders that specify
`how a final image is drawn on a display device and its corresponding
`attributes. Id. at 1:49–54. A shader receives shape data in object space (x,
`y, z), color information, texture information, luminance information, and
`viewing angle information and produces output data (x´, y´, z´) that
`represent the object with texture and other appearance properties applied to
`it. Id. at 1:55–60. Figs. 2A, 2B of the ’454 patent show vertex data Vx, Vy,
`Vz of a cube applied to a vertex shader that outputs angularly oriented
`vertices Vx´, Vy´, Vz´ and appearance attributes of a corresponding cube. Id.
`at 2:3–7. A pixel shader operating at the pixel level provides the color value
`associated with each pixel of a rendered object. Id. at 2:8–12.
`According to the ’454 patent, in a conventional graphics processor,
`the vertex shader and pixel shader are “separate components that are
`configured to perform only a single transformation or operation. Ex. 1001,
`2:12–15. “In conventional graphics processors, the vertex shader and the
`pixel shader are juxtaposed in a sequential, pipelined fashion, with the vertex
`shader being positioned before and operating on vertex data before the pixel
`shader can operate on individual pixel data.” Id. at 2:25–29, 4:5–7. Figure
`3, reproduced below, is a schematic of such a conventional shader.
`
`
`5
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`
`
`In graphics processer 40 of Figure 3, on line 41 vertex fetch block 42
`receives from off-chip memory 55 vertex information relating to primitives
`to be rendered. Id. at 3:23–27. The fetched vertex data (e.g., object shape,
`color and texture information, viewing angle) is stored in vertex cache (V-
`cache) 44 and, upon request, is transmitted on line 45 to vertex shader 46.
`Id. at 3:26–30. Vertex shader 46 typically is programmed to apply a
`transformation position matrix to the input position information supplied
`from V-cache 44 and thereby provide data representing a perspectively
`corrected image of the object to be rendered, as well as texture and color
`coordinates for the image. Id. at 3:30–39. Vertex shader 46 transmits the
`transformed vertices to vertex store 48, which then transmits the modified
`
`6
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`vertex information to primitive assembly block 50, where the input vertex
`information is converted to primitives using well known techniques. Id. at
`3:40–49. Rasterization engine 52 receives and converts the previously
`assembled primitives into pixel data that is then transmitted to pixel shader
`54. Id. at 3:49–53. Pixel shader 54 generates color and additional
`appearance attributes for each pixel and applies the attributes to respective
`pixels. Pixel shader 54 can fetch texture data from texture map 57, as
`indexed by pixel data from rasterization engine 52, and apply logical or
`arithmetic operations on the received texture data to generate the pixel color
`or other appearance attributes of interest. Id. at 3:54–66. The pixel
`appearance attribute is also combined with a base color provided by
`rasterization engine 54 to provide a pixel color corresponding to the position
`of interest. Id. at 3:66–4:4.
`To avoid the computational inefficiency and space requirements of
`separate vertex and pixel shaders, the ’454 patent incorporates into the
`graphics processor a unified shader that performs both pixel and vertex
`operations, as shown in Figures 4A and 4B. Ex. 1001, 2:45–46, 4:5–28.
`Figure 4A, reproduced below, is an exemplary embodiment of a graphics
`processor with a unified shader. Id. at 3:47–48, 4:13.
`
`7
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`
`
`Ex. 1001, Fig. 4A. As Figure 4A illustrates, graphics processor 60 includes
`arbiter 64, multiplexer (mux) 66, and unified shader 62. A control signal on
`line 63 from arbiter 64 to mux 66 determines which of two inputs mux 66
`supplies to unified shader 62. Id. at 4:19–21. Mux 66 sends unified shader
`62 vertex data (e.g., indices) from a first mux input if there are enough
`resources available in the shader to operate on the vertex data; otherwise,
`mux 66 sends unified shader 62 interpolated pixel parameter data from
`rasterization engine 74 on line 75. Id. at 4:13–28.
`Figure 5, reproduced below, is a schematic of unified shader 62.
`Ex. 1001, 4:31–32.
`
`8
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`
`
`Id. at Fig. 5. Shader 62 includes (i) register block 92 (comprising 64 general
`purpose registers), (ii) source registers A, B, and C (reference designators
`94, 95, and 97, respectively), (iii) CPU 96 (adapted to perform 32-bit
`floating point arithmetic operations and logical operations on corresponding
`operands and, in section 96A scalar operations, e.g., log, exponent), and (iv)
`sequencer 99. Id. at 4:40–52. Sequencer 99, which includes instruction
`store 98, determines whether the next instruction to be executed from
`instruction store 98 on data maintained in general purpose register 92, as
`provided by the source registers, is an arithmetic instruction, or a logical
`instruction or a memory instruction, e.g., a texture fetch. Id. at 4:52–66.
`Sequencer 99 also includes constants block 91—constants block 91 includes
`transformation matrices used in connection with vertex manipulation
`operations. Id. at 4:53–55. Instruction store 98 maintains both vertex
`manipulation and pixel manipulation instructions, enabling the shader to
`
`9
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`perform both vertex and pixel operations, and to execute memory fetch
`operations based on the information received from mux 66. Id. at 5:19–27.
`In application, when vertex data (e.g., indices) to be processed is
`transmitted to general purpose register block 92 from mux 66, instruction
`store 98 passes corresponding control signals on line 101 to processor 96 to
`perform vertex operations. If general purpose block 92 does not have
`enough space available to store the incoming vertex data, arbiter 64 will not
`instruct mux 66 to transmit vertex data. Id. at 5:31–44. Instead, any pixel
`calculations currently being performed by processor 96 are continued based
`on instructions from instruction store 98, until enough registers in block 92
`become available to accommodate the vertex data. Id. at 5:45–49. Unified
`shader 62 can switch from executing vertex to pixel instructions, regardless
`of the degree of completion, reducing the down time of processor 96. See id.
`at 5:32–52.
`Pixel based output from the unified shader on line 85 is sent to cache
`block 70 that includes parameter cache 70A and position cache 70B. Ex.
`1001, 5:54–58, Fig. 4A. Pixel information in cache block 70 is transmitted
`to primitive assembly block 72, where the information is assembled into a
`series of triangles or other primitives and transmitted to rasterization engine
`block 74. Rasterization block 74 converts the primitives to individual pixel
`data, e.g., through a walking process, and interpolated pixel data is
`transmitted to the second input of the mux on line 75. Id. at 5:63–6:4.
`Vertex data output from shader 62 on line 85 is transmitted to back
`end block 76, where the vertex data is converted to a format suitable for
`display on display device 84, and transmitted to memory 82 and display
`controller 80, where the formatted information is routed to display 84.
`Ex. 1001, 6:5–18.
`
`10
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`
`V.
`ILLUSTRATIVE CLAIMS
`Independent claim 1 is drawn to a method carried out by a unified
`shader. Ex. 1001, 6:52–7:11. Independent claims 2, 3, 4, 5, and 11 are
`drawn to a “unified shader,” a term in the preambles that limits the claims to
`shaders that can perform both vertex and pixel processing. Ex. 1001, 7:13–
`8:30. See Section VIII.B herein. Claims 6–9 depend from claim 5. Claim
`10 depends from claim 7.
`Independent claim 2, reproduced below using Petitioner’s paragraph
`designations, is illustrative:
`2. [pre] A unified shader, comprising:
`[a] a general purpose register block for maintaining data;
`[b] a processor unit;
`[c] a sequencer, coupled to the general purpose register block and
`the processor unit, the sequencer maintaining instructions
`operative to cause the processor unit to execute vertex
`calculation and pixel calculation operations on selected data
`maintained in the general purpose register block; and
`[d] wherein the processor unit executes instructions that generate
`a pixel color in response to selected data from the general
`purpose register block and generates vertex position and
`appearance data in response to selected data from the general
`purpose register block.
`Ex. 1001, 6:65–7:11. Independent claim 2 recites that the processor unit
`executes instructions in response to selected data, but does not include a
`limitation reciting the selection of operations based on the amount of space
`available in a data store. Independent claim 5, reproduced below, is
`illustrative of a claim with such an express limitation.
`5. A unified shader comprising:
`a processor unit;
`a sequencer coupled to the processor unit, the sequencer
`maintaining instructions operative to cause the processor unit
`to execute vertex calculation and pixel calculation operations
`
`11
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`on selected data maintained in a store depending upon an
`amount of space available in the store.
`Ex. 1001, 8:1–8; see also claims 1, 3, 4.
`In the Realtek IPR, Patent Owner characterizes the ’454 patent as
`having several salient features discussed below that are embodied in the
`claims. Realtek IPR Prelim. Resp. 9–17.
`First, Patent Owner asserts that all of claims 1–11 require a unified
`shader, i.e., a shader the Specification defines as one that is capable of
`executing both vertex and pixel threads to transform both vertex and pixel
`data, respectively2. Id. at 9–11 (citing Ex. 1001, 2:58–61; Ex. 2001,
`Mangione-Smith Decl. ¶ 29), 15. The embodiment of the unified shader in
`the ’454 patent includes a register that stores vertex and pixel data that are to
`be transformed by the unified shader, a sequencer that stores individual
`instructions that form vertex and pixel threads that the unified shader uses to
`manipulate and transform the store vertex and pixel data, and a processor
`that can execute the threads. See id. at 10–11.
`Second, Patent Owner asserts that the unified shader in the ’454 patent
`allocates the unified shader’s resources to switch between unfinished threads
`to prevent downtime and data backlogs. See id. at 11–13; Ex. 1001, 8:22–30
`(claim 11).
`Third, Patent Owner states that, unlike prior art systems that use pre-
`determined priorities or balance workloads based on how many of a
`particular task is in the queue to execute, the ’454 patent selects specific data
`based on the availability of space in the data storage for particular types of
`data. Realtek IPR Prelim. Resp. 13, 15–16. For example, Patent Owner
`
`
`2 We more fully address the construction of the term “unified shader” in
`Section VIII.B herein.
`
`12
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`notes that if there is insufficient room in the data storage for vertex data, the
`processor continues pixel operations until enough registers within the
`general purpose register block become available to store vertex data. Id. at
`13–14 (citing, e.g., Ex. 1001, code (57)) 15 (asserting that claims 1 and 3–11
`require performing operations based on this dynamically-monitored data
`storage capacity).
`Fourth, Patent Owner asserts that, unlike the prior art, in which a
`shader performs tasks based on received instructions, the unified shader of
`the ’454 patent is data-driven, such that the receipt of particular selected data
`dictates the execution of instructions, e.g., the unified shader performs one
`of the vertex operations or pixel operations based on the selected one of the
`plurality of inputs. Id. at 14 (citing Ex. 1001, 2:58–3:17; Ex. 2001,
`Mangione-Smith Decl. ¶ 39), 17 (noting that claim 2 recites executing
`instructions to generate a pixel color and vertex instructions that generate
`vertex and appearance data in response to selected data).
`VI. ASSERTED GROUNDS
`Petitioner asserts the same challenge grounds as those asserted in the
`Realtek IPR. Pet. 18–85. Petitioner asserts that claims 1–11 would have
`been unpatentable on the following grounds:
`
`Claim(s) Challenged
`1–11
`
`Reference(s)
`Lindholm ’6853, Lindholm
`’9134
`
`35 U.S.C. §
`103
`
`
`3 U.S. Patent No. 7,038,685 to Lindholm et al. issued May 2, 2006 (Ex.
`1005).
`4 U.S. Patent No. 7,015,913 to Lindholm et al. issued Mar. 21, 2006 (Ex.
`1006).
`
`13
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`Claim(s) Challenged
`1–11
`1–11
`
`35 U.S.C. §
`103
`103
`
`Reference(s)
`Amanatides5, Kohn6
`Selzer7, Fiske8
`
`VII. LEVEL OF ORDINARY SKILL IN THE ART
`Petitioner describes a person of ordinary skill (“ordinarily skilled
`artisan” or “POSITA”) as having “at least a four-year degree in electrical
`engineering, computer engineering, computer science, or a related field and
`two years relevant experience in the graphics processing field including
`developing, designing, or programming hardware for graphics processing
`units.” Pet. 8. In the Realtek IPR Patent Owner does not comment on the
`level of ordinary skill. See Dec. to Inst. 13.
`The level of ordinary skill in the art usually is evidenced by the
`references themselves. See Okajima v. Bourdeau, 261 F.3d 1350, 1355
`(Fed. Cir. 2001); In re GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995); In
`re Oelrich, 579 F.2d 86, 91 (CCPA 1978). As Petitioner’s description of a
`person of ordinary skill is consistent the subject matter of the challenged
`
`
`5 John Amanatides and Edward Szurkowski, A Simple, Flexible, Parallel
`Graphics Architecture, Proceedings of Graphics Interface at 155–160
`(Canadian Information Processing Society 1993) (Ex. 1007).
`6 Les Kohn and Neal Margulis, Introducing the Intel i860 64-bit
`Microprocessor, IEEE, Volume 9, Issue 4, pages 15–30, August 1989 (Ex.
`1008).
`7 Harald Selzer, Dynamic Load Balancing within a High Performance
`Graphics System, In Proceedings of Rendering, Visualization and
`Rasterization Hardware (Eurographics' 91 Workshop) at 37–53 (Springer-
`Verlag 1993) published in 1993 (“Selzer”) (Ex. 1009).
`8 Stuart Fiske and William J. Dally, Thread prioritization: A Thread
`Scheduling Mechanism for Multiple-Context Parallel Processors,
`Proceedings of First Symposium on High-Performance Computer
`Architecture, 1995 at 210–221 (IEEE 1995) (Ex. 1010).
`
`14
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`claims and the references, we apply Petitioner’s description for purposes of
`this Decision.
`
`VIII. CLAIM CONSTRUCTION
`Claim Construction Principles
`A.
`We interpret claim terms using “the same claim construction standard
`that would be used to construe the claim in a civil action under 35 U.S.C.
`282(b).” 37 C.F.R. § 42.100(b) (2019). In this context, claim terms “are
`generally given their ordinary and customary meaning” as understood by a
`person of ordinary skill in the art in question at the time of the invention.
`Phillips v. AWH Corp., 415 F.3d 1303, 1312–13 (Fed. Cir. 2005) (citing
`Vitronics, 90 F.3d at 1582) (en banc). “In determining the meaning of the
`disputed claim limitation, we look principally to the intrinsic evidence of
`record, examining the claim language itself, the written description, and the
`prosecution history, if in evidence.” DePuy Spine, Inc. v. Medtronic
`Sofamor Danek, Inc., 469 F.3d 1005, 1014 (Fed. Cir. 2006) (citing Phillips,
`415 F.3d at 1312–17). Extrinsic evidence is “less significant than the
`intrinsic record in determining ‘the legally operative meaning of claim
`language.’” Phillips, 415 F.3d at 1317 (citing C.R. Bard, Inc. v. U.S.
`Surgical Corp., 388 F.3d 858, 862 (Fed. Cir. 2004)).
`Any special definition for a claim term must be set forth in the
`specification with reasonable clarity, deliberateness, and precision. In re
`Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994).
`We construe only those claim terms that require analysis to determine
`whether to institute inter partes review. See Realtime Data, LLC v. Iancu,
`912 F.3d 1368, 1375 (Fed. Cir. 2019) (“The Board is required to construe
`‘only those terms . . . that are in controversy, and only to the extent
`
`15
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`necessary to resolve the controversy.’” (quoting Vivid Techs., Inc. v. Am.
`Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999))).
`B.
`Realtek IPR Constructions
`In the Realtek IPR, neither party proposed a special definition or
`explicit construction of any claim term. Underlying Patent Owner’s
`arguments, however, was a construction of the term “unified shader.”
`Noting that the limiting term “unified shader” appears in the preamble of all
`the claims, we construed the claimed “unified shader” to mean a shader that
`is configured to perform both vertex and pixel operations. Ex. 1001, 3:10–
`12. Realtek IPR Dec. to Inst. 15–17. As we did not perceive a need to
`construe other terms, we applied the plain and ordinary meaning to the
`remaining claim language. Id. at 17. We apply the same reasoning in this
`Decision and do not repeat the analysis here.
`IX. ANALYSIS
`Legal Principles
`A.
`“In an [inter partes review], the petitioner has the burden from the
`onset to show with particularity why the patent it challenges is
`unpatentable.” Harmonic Inc. v. Avid Tech., Inc., 815 F.3d 1356, 1363 (Fed.
`Cir. 2016) (citing 35 U.S.C. § 312(a)(3) (requiring inter partes review
`petitions to identify “with particularity . . . the evidence that supports the
`grounds for the challenge to each claim”)). This burden of persuasion never
`shifts to patent owner. See Dynamic Drinkware, LLC v. Nat’l Graphics,
`Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015) (discussing the burden of proof in
`inter partes review).
`The question of obviousness is resolved on the basis of underlying
`factual determinations including: (1) the scope and content of the prior art;
`(2) any differences between the claimed subject matter and the prior art;
`
`16
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`(3) the level of ordinary skill in the art; and (4) objective evidence of
`nonobviousness. Graham v. John Deere Co., 383 U.S. 1, 17–18 (1966).
`
`Additionally, the obviousness inquiry typically requires an analysis of
`“whether there was an apparent reason to combine the known elements in
`the fashion claimed by the patent at issue.” KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398, 418 (2007) (citing In re Kahn, 441 F.3d 977, 988 (Fed. Cir.
`2006) (requiring “articulated reasoning with some rational underpinning to
`support the legal conclusion of obviousness”)); see In re Warsaw
`Orthopedic, Inc., 832 F.3d 1327, 1333 (Fed. Cir. 2016) (citing DyStar
`Textilfarben GmbH & Co. Deutschland KG v. C. H. Patrick Co., 464 F.3d
`1356, 1360 (Fed. Cir. 2006)).
`An obviousness analysis “need not seek out precise teachings directed
`to the specific subject matter of the challenged claim, for a court can take
`account of the inferences and creative steps that a person of ordinary skill in
`the art would employ.” KSR, 550 U.S. at 418; accord In re Translogic
`Tech., Inc., 504 F.3d 1249, 1259 (Fed. Cir. 2007). Petitioner cannot satisfy
`its burden of proving obviousness by employing “mere conclusory
`statements.” In re Magnum Oil Tools Int’l, Ltd., 829 F.3d 1364, 1380 (Fed.
`Cir. 2016). Instead, Petitioner must articulate a reason why a person of
`ordinary skill in the art would have combined the prior art references. In re
`NuVasive, 842 F.3d 1376, 1382 (Fed. Cir. 2016).
`A reason to combine or modify the prior art may be found explicitly
`or implicitly in market forces; design incentives; the “interrelated teachings
`of multiple patents”; “any need or problem known in the field of endeavor at
`the time of invention and addressed by the patent”; and the background
`knowledge, creativity, and common sense of the person of ordinary skill.
`
`17
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`Perfect Web Techs., Inc. v. InfoUSA, Inc., 587 F.3d 1324, 1328–29 (Fed. Cir.
`2009) (quoting KSR, 550 U.S. at 418–21).
`In determining whether a claim is obvious in light of the prior art,
`when in evidence, we consider any relevant objective evidence of non-
`obviousness. See Graham, 383 U.S. at 17. Notwithstanding what the
`teachings of the prior art would have suggested to one of ordinary skill in the
`art at the time of the invention, the totality of the evidence submitted,
`including objective evidence of non-obviousness, may lead to a conclusion
`that the challenged claims would not have been obvious to one of ordinary
`skill. In re Piasecki, 745 F.2d 1468, 1471–72 (Fed. Cir. 1984). At this stage
`of the proceeding Patent Owner does not present evidence of such objective
`considerations.
`We analyze the asserted grounds of unpatentability in accordance with
`these principles to determine whether Petitioner has met its burden to
`establish a reasonable likelihood of success at trial.
`B.
`Petitioner’s Challenge to Claims 1–11 As Obvious Over
`Lindholm ’685 and Lindholm ’913 (collectively, “the Lindholm
`References”)
`
`Lindholm ’685 (Ex. 1005)
`Lindholm ’685 discloses a graphics processor that includes a
`multithreaded processing unit. Ex. 1005, 1:44–45.
`The multithreaded processing unit includes a thread control unit
`configured to store pointers to program instructions associated
`with threads, each thread processing a sample type of vertex,
`pixel, or primitive. The multithreaded processing unit also
`includes at least one programmable computation unit configured
`to process data under control of the program instructions.
`Id. at 1:45–51. Figure 2 of Lindholm ’685 is reproduced below.
`
`18
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`
`
`Ex. 1005, Fig. 2. Figure 2 illustrates that Lindholm ’685 includes execution
`pipelines 240, each containing a multithreaded processing unit that accepts
`and processes vertex and pixel samples from vertex and pixel input buffers
`210, 220, respectively, when a thread is available. Id. at 4:31–36, 5:23–25.
`Figure 4 of Lindholm ’685, showing details of a multithreaded processing
`unit, is reproduced below.
`
`19
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`
`
`Id., Fig. 4. Each thread processing unit can process vertex or pixel data—
`Instruction Dispatcher 440 gathers source data from pixel input buffer 215
`and vertex input buffer 220 or Register file 350 specified in an instruction
`and outputs the instruction and source data to Execution unit 470. Id. at
`9:34–38. When program instructions associated with a thread have
`completed execution, the storage resources allocated to retain intermediate
`data during thread execution become available to another thread. Id. at
`9:57–63.
`
`20
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`
`Lindholm ’913 (Ex. 1006)
`Lindholm ’913 discloses a “programmable graphics processor that
`supports processing of graphics data elements in an order independent from
`the order in which the graphics data elements are received by the
`programmable graphics pipeline within the programmable graphics
`processor.” Ex. 1006, 1:39–44. The graphics processor includes at least one
`multithreaded processing unit that receives samples in a first order to be
`processed by program instructions associated with at least one thread. Id. at
`1:48–52. Each multithreaded processing unit includes a scheduler. Id. at
`1:53. The scheduler is configured to receive program instructions,
`determine the availability of source data, and schedule instructions for
`execution in a second order that is independent of the first order. Id. at
`1:54–56. Each multithreaded processing unit includes a resource tracking
`unit that tracks the availability of source data, and a dispatcher configured to
`output program instructions in the second order to be executed by the
`multithreaded processing unit. Id. at 1:56–61. In one embodiment, when
`first source data required to process a program instruction associated with a
`first thread is not available, and second source data required to process a
`program instruction associated with a second thread are available, the
`program instructions associated with the second thread are dispatched prior
`to dispatching program instructions for the first thread. Id. at 2:7–22.
`
`Reasons to Combine the Teachings of Lindholm ’685 and
`Lindholm ’913
`Noting that Lindholm ’685 and Lindholm ’913 are both directed to a
`multithreaded shader and much of their Specifications and figures are the
`same, in the Realtek IPR Petitioner contends that a person of ordinary skill
`would have recognized the Lindholm references disclose different details of
`
`21
`
`

`

`IPR2024-00366
`Patent 8,760,454 B2
`the same unified shader architecture. Realtek IPR Pet. 21–22. In the
`Realtek IPR, Petitioner also states that an ordinarily skilled artisan would
`have looked to the additional disclosure in Lindholm ’913 for additional
`details about scheduling threads for execution independent of other threads.
`Id. at 22. In the Realtek IPR, we agreed that a person of ordinary skill would
`have had reason to combine the teachings of the Lindholm references. We
`apply the same reasoning to this Decision do not repeat that analysis here.
`
`Analysis in the Realtek IPR
`In the Realtek IPR we were persuaded that Patent Owner antedated
`the Lindholm references and therefore they are not prior art. Therefore, in
`this proceeding we are not persuaded that Petitioner will succeed on its
`challenge based on the Lindholm references. Realtek IPR Dec. to Inst. 23–
`41. We apply the same reasoning in this Decision and do not repeat our
`analysis here.
` In the Realtek IPR, we also noted that if the Lindholm references
`were considered applicable prior art, we are persuaded that Petitioner has
`cited sufficient evidence to demonstrate that a person of ordinary skill would
`have been motivated to combine the teachings of Lindholm ’685 and
`Lindholm ’913, and that in combination, the references would have taught,
`or at least suggested, all the limitations of claims 1–11 to a person of
`ordinary skill in the art. We apply the same reasoning to this Decisions and
`do not repeat that analysis here. Id.
`C.
`Petitioner’s Challenge to Claims 1–11 As Obvious Over
`Amanatides and Kohn
`
`Amanatides (Ex. 1007)
`Amanatides discloses a graphics architecture in which a host sends
`graphics primitives to a graphics pipeline front end. Ex. 1

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


Or .

Accessing this document will incur an additional charge of $.

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

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket