Trials@uspto. gov
`571-272-7822
`
`Paper10
`Date: December 1, 2023
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`REALTEK SEMICONDUCTOR CORP.,
`Petitioner,
`
`Vv.
`
`ATI TECHNOLOGIES ULC,
`Patent Owner.
`
`IPR2023-00922
`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 ofInter Partes Review
`35 U.S.C. § 314
`
`
`571-272-7822
`
`Paper10
`Date: December 1, 2023
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`REALTEK SEMICONDUCTOR CORP.,
`Petitioner,
`
`Vv.
`
`ATI TECHNOLOGIES ULC,
`Patent Owner.
`
`IPR2023-00922
`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 ofInter Partes Review
`35 U.S.C. § 314
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`I.
`
`INTRODUCTION
`
`Realtek Semiconductor Corp. (‘Petitioner’) filed a petition, Paper 1
`
`(‘“Petition”or “Pet.’’), to institute an interpartes review (“IPR”) of claims 1—
`
`11 (the “challenged claims”) ofU.S. Patent No. 8,760,454 B2 (“the 454
`
`patent”). 35 U.S.C. §311. ATI Technologies ULC (“Patent Owner’) filed a
`
`Preliminary Response, Paper6 (“Prelim. Resp.”), contending that the
`
`Petition should be denied as to all challengedclaims. We authorized
`
`Petitioner’s filing ofa Preliminary Reply to Patent Owner’s Preliminary
`
`Response. (Paper8, “Prelim. Reply”) and Patent Owner’s filing ofa
`
`Preliminary Sur-reply (Paper9, “Prelim. Sur-reply”).
`
`We havejurisdiction under 35 U.S.C. § 6. This Decision on
`
`Institution is issued pursuant to 35 U.S.C. § 314, which providesthat an
`
`interpartes review maynotbeinstituted unless the information presented in
`
`the Petition “showsthat there is a reasonable likelihood that the Petitioner
`
`would prevail with respectto at least 1 ofthe claims challengedin the
`
`petition.”
`
`A decision to institute under § 314 may notinstitute on fewerthanall
`
`claims challengedin the petition. SAS Inst., Inc. v. Iancu, 138 S. Ct. 1348,
`
`1359-60 (2018). In addition, per Board practice, ifthe Board institutestrial,
`
`it will institute “on all ofthe challengedclaims and onall grounds of
`
`unpatentability asserted for each claim.” See 37 C.F.R. § 42.108(a).
`
`Having considered the arguments andthe associated evidence
`
`presented in the Petition and the Preliminary Response., for the reasons
`
`described below,weinstitute interpartes review.
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`Il.
`
`REAL PARTIES IN INTEREST
`
`The Petition identifies Realtek Semiconductor Corp. (“Realtek’’) as its
`
`real party-in-interest. Pet. 1. Patent Owner identifies ATI Technologies
`
`ULC asits real party-in-interest. Paper 4,1.
`
`I.
`
`RELATED MATTERS
`
`Petitioner and Patent Owneridentify the following proceedings as
`
`ones that mayaffect 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 AMDLitigation”); and
`Certain Graphics Systems, Components Thereof, and Digital
`Televisions Containing the Same, Inv. No. 337-TA-1318 (‘the
`ITC Investigation’).
`
`Pet. 2, Paper 4, 1. Petitioner states that the AMDlitigation is stayed pending
`
`completion ofthe ITC Investigation, expected on or about November7,
`
`2023. Pet. 2.
`
`IV.
`
`THE’454 PATENT
`
`The °454 patent concernsa graphicsprocessing architecture that
`
`employsa single or “unified shader,”i.e., a shaderthat “is configured to
`
`perform bothvertex and pixel operations.” Ex. 1001, 1:32—33, 3:10-12.
`
`The °454 patent explainsthat, 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. Jd. at
`
`1:38-42. Primitives are formed by interconnecting individualpixels. Jd. at
`
`1:42—43. In order to renderan objectfor display, based on the location of
`
`the pixels within the primitives andthe primitives’ orientation with respect
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`to the desired shape, color and texture are applied to the individualpixels
`
`that make upthe shapeto be generated. /d. at 1:42-48.
`
`Graphicsprocessorsthat interconnect the primitives and apply color
`
`and textures to the generated shapes includeaseries of shadersthat specify
`
`howafinal imageis drawn on a display device andits corresponding
`
`attributes. Jd. at 1:49-54. A shaderreceives 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
`
`representthe object with texture and other appearanceproperties applied to
`
`it. Id. at 1:55-60. Figs. 2A, 2B ofthe ’454 patent show vertex data Vx, Vy,
`
`V, of a cube applied to a vertex shader that outputs an gularly oriented
`
`vertices Vx’, Vy’, Vz’ and appearanceattributes of a corresponding cube. Id.
`
`at 2:3—7. A pixel shader operating at the pixel level provides the color value
`
`associated with eachpixel of a rendered object. /d. at 2:8-12.
`
`According to the ’454 patent, in a conventional graphics processor,
`
`the vertex shader and pixel shaderare “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 shaderare 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.” Jd. at 2:25—29, 4:5—7. Figure
`
`3, reproduced below,is a schematic of such a conventional shader.
`
`
`
`
`
`VERTEX
`
`bm 4D
`
`PRIMITIVE
`ASSEMBLY
`
`51
`
`RASTERIZATION
`ENGINE
`
`a0
`
`[92
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`
`
`TEXTURE
`MAP
`
`
`
`a3
`
`
`
`
`a7
`
`
`
`53-4
`
`8
`TO,
`PIXEL
`
`SHADER
`
`FROM
`57
`
`4
`
`}-59
`nn
`
`(PRIORART)
`
`mmoceeene
`
`In graphics processer40 ofFigure 3, on line 41 vertex fetch block 42
`
`receives from off-chip memory 55 vertex information relating to primitives
`
`to be rendered. /d. 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 programmedto apply a
`
`transformation position matrix to the input position information supplied
`
`from V-cache 44 and thereby provide data representing a perspectively
`
`corrected image ofthe object to be rendered, as well as texture and color
`
`coordinates for the image. /d. at 3:30-39. Vertex shader 46 transmits the
`
`transformedvertices to vertex store 48, which then transmits the modified
`
`
`
`IPR2023-00922
`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. /d. at
`
`3:40-49. Rasterization engine 52 receives and converts the previously
`
`assembledprimitives 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 appliesthe attributes to respective
`
`pixels. Pixel shader 54 can fetch texture data from texture map 57, as
`
`indexedby pixel data from rasterization engine 52, and apply logicalor
`
`arithmetic operations on the received texture data to generate the pixel color
`
`or other appearanceattributes of interest. /d. at 3:54-66. Thepixel
`
`appearanceattribute 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 shownin Figures 4A and 4B. Ex. 1001, 2:45—46, 4:5—28.
`
`Figure 4A, reproducedbelow,is an exemplary embodimentofa graphics
`
`processor with a unified shader. /d. at 3:47-48, 4:13.
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`INDICES
`
`
`
`87
`
`tO MEMORY
`
`ARBITER
`64
`
`6
`
`MUX
`
`66
`
`65
`
`go
`
`60
`
`UNIFIED
`SHADER
`
`85
`
`76
`
`RENDER
`BACK
`END
`
`7
`
`8
`
`MEMORY
`CONTROLLER
`
`8
`
`80
`
`DISPLAY
`CONTROLLER
`
`at
`
`MEMORY
`DATA
`
`69
`
`70
`
`
`
`TEXTURE
`VERTEX
`CACHE
`
`BoA
`
`PARAMETER Fo"
`CACHE
`
`7OB
`
`POSITION
`CACHE
`
`
`
`
`Fi
`primitive
`ASSEMBLY
`73
`
`RASTERIZATION
`ENGINE
`
`[5°
`
`78
`
`
`_
`7
`
`&
`
`ad
`
`82
`
`MEMORY
`DISPLAY
`
`
`FIG. 4A
`
`Ex. 1001, Fig. 4A. As Figure 4Aillustrates, 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 oftwo inputs mux 66
`
`supplies to unified shader 62. Js. At 4:19—-21. Mux 66 sends unified shader
`
`62 vertex data (e.g., indices) from a first mux input ifthere are enough
`
`resourcesavailable in the shaderto operate on the vertex data; otherwise,
`
`mux 66 sendsunified shader 62 interpolated pixel parameter data from
`
`rasterization engine 74 on line 75. Jd. at 4:13-28.
`
`Figure 5, reproduced below,is a schematic ofunified shader 62.
`
`Ex. 1001, 4:31-32.
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`FROM MUX
`
`99
`
`MEMORY
`FETCH
`
`INSTRUCTION
`STORE
`
`67
`
`
`
`
`
`
`FIG. 5
`
`\
`
`Id. at Fig. 5. Shader 62 includes (1) register block 92 (comprising 64 general
`
`purposeregisters), (11) source registers A, B, and C (reference designators
`
`94, 95, and 97, respectively), (111) CPU 96 (adapted to perform 32-bit
`
`floating point arithmetic operations and logical operations on corresponding
`
`operandsand,in section 96A scalar operations, e.g., log, exponent), and (iv)
`
`sequencer 99. Id. at 4:40—-52. Sequencer 99, which includesinstruction
`
`store 98, determines whether the next instruction to be executed from
`
`instruction store 98 on data maintained in general purposeregister 92, as
`
`provided by the sourceregisters, is an arithmetic instruction, or a logical
`
`instruction or amemory instruction, e.g.,a texture fetch. /d. at 4:52—66.
`
`Sequencer 99 also includes constants block 91—constants block 91 includes
`
`transformation matrices used in connection with vertex manipulation
`
`operations. /d. at 4:53—55. Instruction store 98 maintains both vertex
`
`manipulation and pixel manipulation instructions, enabling the shaderto
`
`
`
`IPR2023-00922
`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. /d. at 5:19-27.
`
`In application, when vertexdata(e.g., indices) to be processedis
`
`transmitted to general purposeregister 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
`
`enoughspace 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 performedby 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 ofprocessor 96. Seeid.
`
`at 5:32-—52.
`
`Pixel based output from the unified shaderon 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 70is 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 individualpixel
`
`data, e.g., through a walking process, and interpolated pixel datais
`
`transmitted to the second input ofthe mux on line75. Jd. 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 anddisplay
`
`controller 80, where the formatted informationis routed to display 84.
`
`Ex. 1001, 6:5—18.
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`V.
`
`ILLUSTRATIVECLAIMS
`
`Independentclaim | 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 toa “unified shader,” aterm in the preamblesthat 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 purposeregister 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 responseto selected data from the general
`purposeregister block.
`
`Ex. 1001, 6:65-7:11. Independent claim 2 recites that the processorunit
`
`executes instructions in responseto selected data, but does not includea
`
`limitation reciting the selection of operations based on the amountof space
`
`available in a data store. Independent claim 5, reproduced below,is
`
`illustrative of a claim with such an expresslimitation.
`
`5. Aunified 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
`
`10
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`on selected data maintained in a store depending upon an
`amount of space available in thestore.
`
`Ex. 1001, 8:1—8; see also claims 1, 3, 4.
`
`Patent Ownercharacterizes the ’454 patent as having severalsalient
`
`features that are embodied in the claims. Prelim. Resp. 9~17.
`
`First, Patent Ownerasserts that all of claims 1—11 require a unified
`
`shader,i.e.,a shader the Specification defines as one thatis capable of
`
`executing both vertex and pixel threads to transform both vertex andpixel
`
`data, respectively. Jd. at 9-11 (citing Ex. 1001, 2:58-61; Ex. 2001,
`
`Mangione-Smith Decl. 29), 15. The embodimentofthe unified shaderin
`
`the °454 patent includesa register that stores vertex and pixel data that are to
`
`be transformed by the unified shader, a sequencerthat stores individual
`
`instructions that form vertex and pixel threadsthat 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 Ownerasserts that the unified shaderin 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 Ownerstatesthat, unlike prior art systemsthat use pre-
`
`determinedpriorities or balance workloads based on how many ofa
`
`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. Prelim. Resp. 13, 15-16. For example, Patent Ownernotesthatif
`
`there is insufficient room in the data storage for vertex data, the processor
`
`' We morefully address the construction ofthe term “unified shader”in
`Section VIII.B herein.
`
`11
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`continuespixel operations until enough registers within the general purpose
`
`register block becomeavailable to store vertex data. Jd. at 13-14 (citing,
`
`e.g., Ex. 1001, code (57)) 15 (asserting that claims 1 and 3—11 require
`
`performingoperations based on this dynamically-monitored data storage
`
`capacity).
`
`Fourth, Patent Owner asserts that, unlike the prior art, in whicha
`
`shader performs tasks based on received instructions, the unified shader of
`
`the °454 patent is data-driven, such that the receipt ofparticular selected data
`
`dictates the execution ofinstructions,e.g., the unified shader performs one
`
`of the vertex operationsor pixel operations based on the selected one ofthe
`
`pluralityofinputs. Jd. at 14 (citing Ex. 1001, 2:58-3:17; Ex. 2001,
`
`Mangione-Smith Decl. { 39), 17 (noting that claim 2 recites executing
`
`instructions to generateapixel color and vertex instructions that generate
`
`vertex and appearancedata in responseto selected data).
`
`VI. ASSERTED GROUNDS
`
`Petitioner asserts that claims 1—1 1 would have been unpatentable on
`
`the following grounds:
`
`9133
`
`Claim(s) Challenged|
`Ii
`
`35 U.S.C.§
`
`Reference(s)
`Lindholm ’6852, Lindholm
`
`* U.S. Patent No. 7,038,685 to Lindholm etal. issued May 2, 2006 (Ex.
`1005).
`3U.S. Patent No. 7,015,913 to Lindholm etal. issued Mar. 21, 2006 (Ex.
`1006).
`
`12
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`
`
`
`Claim(s) Challenged|_35 U.S.C.§
`Amanatides*, Kohn?
`
`
`Selzer®, Fiske’
`
`VII. LEVEL OF ORDINARYSKILLIN THE ART
`
`Petitioner describes a person ofordinary skill (“ordinanly 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. Patent Owner does not commenton the level ofordinary
`
`skill.
`
`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 GPACInc. , 57 F.3d 1573, 1579 (Fed. Cir. 1995); In
`
`re Oelrich, 579 F.2d 86, 91 (CCPA 1978). As Petitioner’s description ofa
`
`person of ordinaryskill is consistent the subject matter ofthe challenged
`
`4 John Amanatides and Edward Szurkowski, A Simple, Flexible, Parallel
`Graphics Architecture, Proceedings ofGraphics Interface at 155—160
`(CanadianInformation Processing Society 1993) (Ex. 1007).
`> Les Kohn and Neal Margulis, Introducing the Intel i860 64-bit
`Microprocessor, IEEE, Volume9, Issue4, pages 15—30, August 1989 (Ex.
`1008).
`° Harald Selzer, Dynamic LoadBalancing within a High Performance
`Graphics System, In Proceedings ofRendering, Visualization and
`Rasterization Hardware (Eurographics' 91 Workshop) at 37—53 (Springer-
`Verlag 1993) published in 1993 (‘Selzer’) (Ex. 1009).
`7 Stuart Fiske and William J. Dally, Threadprioritization: A Thread
`Scheduling Mechanismfor Multiple-Context Parallel Processors,
`Proceedings ofFirst Symposium on High-Performance Computer
`Architecture, 1995 at 210-221 (IEEE 1995) (Ex. 1010).
`
`13
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`claims and the references, we apply Petitioner’s description for purposes of
`
`this Decision.
`
`VII. CLAIM CONSTRUCTION
`
`A.
`
`Claim Construction Principles
`
`Forpetitionsfiled after November 13, 2018, 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 understoodby a person ofordinary skill in the art in
`
`question at the time ofthe invention. Phillips v. AWH Corp., 415 F.3d 1303,
`
`1312-13 (Fed. Cir. 2005) (citations omitted) (en banc). “In determining the
`
`meaningofthe disputed claim limitation, we look principally to the intrinsic
`
`evidence ofrecord, examiningthe claim languageitself, the written
`
`description, and the prosecution history, ifin 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 ts “less significant
`
`than the intrinsic record in determining‘the legally operative meaning of
`
`claim language.’” Phillips, 415 F.3d at 1317 (citations omitted).
`
`Anyspecial definition for a claim term mustbe set forth in the
`
`specification with reasonableclarity, deliberateness, and precision. In re
`
`Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994).
`
`Weconstrue only those claim termsthat require analysis to determine
`
`whethertoinstitute inter partes review. See Realtime Data, LLC v. Iancu,
`
`912 F.3d 1368, 1375 (Fed. Cir. 2019) (“The Boardis required to construe
`
`‘only those terms... that are in controversy, andonly to the extent
`999
`
`necessary to resolve the controversy.’”
`
`(quoting Vivid Techs., Inc. v. Am.
`
`Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999))).
`
`14
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`Neither party has proposed a special definition or explicit construction
`
`of any claim term. Underlying Patent Owner’s arguments, however,is a
`
`construction ofthe term “unified shader.” Therefore, we consider how
`
`“unified shader’ should be construed.
`
`B.
`
`Unified Shader
`
`All the claims ofthe ’454 patentrecite a unified shader. The ’454
`
`patentstates that a unified shaderis one “that is capable ofperforming both
`
`the vertex and the pixel operations.” Ex. 1001, 2:45—46. Patent Owner
`
`contends that, in addition, a unified shader, as claimed in the ’454 patent, is
`
`one that can switch back and forth between executing unfinishedvertex and
`
`pixel threads. Prelim. Resp. 44 (emphasis added) (citing Ex. 2001,
`
`Mangione-Smith Decl. 4319); see also id. at 11-13 (citing Ex. 1001, 5:23—
`
`52, Ex. 2001, Mangione-Smith Decl. 79 33-35).
`
`Petitioner agreesthat “the ’454 patent uses the same piece of
`
`hardware, whichit also terms a ‘unified shader’ to run both vertex shader
`
`programs andpixel shader programs.” Pet. 13 (citing Ex. 1001, 2:58—3:3,
`
`3:10—-12). Referring to an embodimentin which processor 96 has one
`
`logical partition that performs32-bit floating point arithmetic operations for
`
`vertex processing and anotherlogicalpartition for processing scalar pixel
`
`operations, Petitionerstates “[t]he processor unit within the unified shader
`
`can process vertex data concurrently with pixel data andalternate between
`
`the two typesof operations.” /d. at 14 (citing Ex. 1001, 5:32—36, 6:36-41;
`
`Ex. 1003, Pfister Decl. 7954-55). Noting that the unified shaderin the ’*454
`
`patent maintains instructions for performing vertex and pixel operationsin a
`
`sequencer, Petitioner acknowledgesthat an arbiter circuit might give priority
`
`to selecting vertex or pixel inputs for processing based on whetherthe
`
`15
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`general purpose registers have space available to store incomingvertex data.
`
`Id. (citing Ex. 1001, 4:12—28, 4:52—5:5, 5:41—52).
`
`Accordingto Petitioner the °454 patent does not disclose a
`
`multithreaded shader, but“at best discloses a pipelined processor that can
`
`execute multiple instructions concurrently with respect to different data
`
`types, using separate partitions for floating point calculations needed for
`
`vertex operations andfor scalar/integer pixel operations.” Pet.41. We
`
`understand Petitioner to be arguing that the unified shader ofthe ’454 patent
`
`cannotbe construed to be one that switches back and forth between
`
`unfinished vertex andpixel threads, as Patent Ownerargues throughout the
`
`Preliminary Response. Although Patent Owner contendsthat the unified
`
`shader ofthe ’454 patent switches between unfinished vertex and pixel
`
`threads, the ’454 patent does not use the term “thread” and doesnotrefer to
`
`or discuss instructions to be executed as a “thread.”
`
`The °454 patent explicitly defines its unified shaderstating “[t]he
`
`shader ofthe present inventionis referred to as a ‘unified’ shader becauseit
`
`is configured to perform both vertex and pixel operations.” Ex. 1001, 3:10-
`
`12. This definition does not limit the unified shaderto one that switches
`
`back and forth between executing vertex and pixel threads. The °454 patent
`
`also describes the embodiment in Figure4A and Figure 5 as “exemplary.”
`
`In this “exemplary” embodiment, the unified shader “hasability to
`
`simultaneously perform vertex manipulation operations and pixel
`
`manipulation operations at various degrees of completion by being able to
`
`freely switch between such programsor instructions, maintained in the
`
`instruction store, very quickly.” Jd. at 5:32—37. Claim 11 explicitly recites
`
`this feature. /d. at 8:26—30 (reciting “wherein the processor unit ofthe
`
`unified shader performs the vertex manipulation operationsand pixel
`
`16
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`manipulation operationsat various degrees of completion based on
`
`switching betweeninstructions in the instruction store”). Based on the
`
`explicit definition ofa unified shader in the °454 patent and the explicit
`
`recitation in claim 11, we decline to adopt a construction that imports
`
`additionallimitations into the term “unified shader.”
`
`The limiting term “unified shader” appears in the preambleofall the
`
`claims. We construe the claimed “unified shader” to mean a shaderthatis
`
`configured to perform both vertex and pixel operations. Ex. 1001, 3:10—12.
`
`C.
`
`Other Terms
`
`As we do not perceive aneed to construe other terms, we apply the
`
`plain and ordinary meaningto the remaining claim lan guage.
`
`IX. ANALYSIS
`
`A.
`
`Legal Principles
`
`“In an [inter partes review], the petitioner has the burden from the
`
`onset to show with particularity why the patent it challengesis
`
`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
`
`groundsfor the challengeto each claim’”’)). This burden ofpersuasion never
`
`shifts to patent owner. See Dynamic Drinkware, LLC v. Nat’] Graphics,
`
`Inc., 800 F.3d 1375, 1378 (Fed. Cir. 2015) (discussing the burden ofproofin
`
`inter partes review).
`
`The question of obviousnessis resolved on the basis ofunderlying
`
`factual determinations including: (1) the scope and contentofthe priorart;
`
`(2) any differences between the claimed subject matterand the prior art;
`
`(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).
`
`17
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`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 patentat issue.” KSR Int’] 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 ofthe challenged claim,for a court can take
`
`accountofthe inferences andcreative steps that a person ofordinary skill in
`
`the art wouldemploy.” KSR,550 U.S. at 418; accord In re Translogic
`
`Tech., Inc., 504 F.3d 1249, 1259 (Fed. Cir. 2007). Petitioner cannotsatisfy
`
`its burden ofproving obviousness by employing “mere conclusory
`
`statements.” Jn re Magnum Oil Tools Int'l, Ltd., 829 F.3d 1364, 1380 (Fed.
`
`Cir. 2016). Instead, Petitionermustarticulate a reason whya person of
`
`ordinary skill in the art would have combined thepriorart references. /n re
`
`NuVasive, 842 F.3d 1376, 1382 (Fed. Cir. 2016).
`
`A reason to combine or modify the prior art may be found explicitly
`eee
`“interrelated teachings
`
`or implicitly in market forces; design incentives; the
`999, C66
`of multiple patents’”’;
`
`“‘any need or problem known in thefield of endeavor
`
`at the time of invention and addressed by the patent’”’; and the background
`
`knowledge, creativity, and commonsense ofthe person of ordinary skill.
`
`Perfect Web Techs., Inc. v. InfoUSA, Inc., 587 F.3d 1324, 1328-29 (Fed. Cir.
`
`2009) (quoting KSR, 550 U.S. at 418-21).
`
`18
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`In determining whether a claim is obvious in light ofthe priorart,
`
`whenin evidence, we consider any relevant objective evidence ofnon-
`
`obviousness. See Graham, 383 U.S. at 17. Notwithstanding what the
`
`teachings ofthe prior art would have suggested to one of ordinary skill in the
`
`art at the time ofthe invention,the totality ofthe evidence submitted,
`
`including objective evidence ofnon-obviousness, may lead to a conclusion
`
`that the challenged claims wouldnot have been obviousto one of ordinary
`
`skill. Inre Piasecki, 745 F.2d 1468, 1471-72 (Fed. Cir. 1984). At this stage
`
`of the proceeding Patent Ownerdoesnotpresent evidence of such objective
`
`considerations.
`
`Weanalyze the asserted grounds ofunpatentability in accordance with
`
`these principles to determine whetherPetitioner has met its burden to
`
`establish a reasonable likelihood of success attrial.
`
`B._Petitioner’s Challenge to Claims I-11 As Obvious Over
`Lindholm ’685 and Lindholm 913 (collectively, “the Lindholm
`References”)
`
`1.
`
`Lindholm ’685 (Ex. 1005)
`
`Lindholm ’685 discloses a graphics processor that includes a
`
`multithreaded processingunit. 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
`includesat least one programmable computation unit configured
`to process data under control ofthe program instructions.
`
`Id. at 1:45—51. Figure 2 ofLindholm ’685 is reproduced below.
`
`19
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`From
`
`
`
`Programmable
`Graphics
`
`
`480
`Pi
`A
`biy/Set
`Pipeline
`rimitive oon yiSetup
`|
`-_
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Execution
`| Pipeline
`
`i
`
`Execution
`Pipeline
`
`Execution
`| Pipeline
`B40
`
`Execution
`Pipeline
`240
`
`FIG, 2
`
`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. /d. at 4:31—36, 5:23—25.
`
`Figure 4 of Lindholm ’685, showing details of a multithreaded processing
`
`unit, is reproduced below.
`
`20
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`From. From
`215
`220
`£
`f
`
`i
`|
`
`
`
`Execution
`Pipeline
`240
`
`Multithreaded
`Processing Unit
`
`To 225 +
`From 225 ~~
`
`
`
`
`
`
`
`
`File
`
`| Resoure
`| Seoreboa:
`
`Instruction |
`Scheduler
`— —_
`
`
`
`
`.
`
`|i
`
`Instruction
`Dispatcher
`
`
`
`Register
`|
`
`—
`Frere 21Gnfeoefownnonnnnnnin
`
`
`
`Te 26048©6©To 270
`
`FIG. 4
`
`Id., Fig. 4. Each thread processing unit can processvertex 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 datato Execution unit 470. Jd. at
`
`9:34-38. When program instructions associated with a thread have
`
`completed execution, the storage resourcesallocated to retain intermediate
`
`data during thread execution becomeavailable to another thread. Jd.at
`
`9:57-63.
`
`21
`
`
`
`IPR2023-00922
`Patent 8,760,454 B2
`
`2.
`
`Lindholm ’913 (Ex. 1006)
`
`Lindholm ’913 discloses a “programmable graphics processorthat
`
`supports processing of graphics data elements in an order independentfrom
`
`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 processorincludesat least one
`
`multithreaded processing unit that receives samplesin a first order to be
`
`processed by program instructionsassociated with at least one thread. Jd. at
`
`1:48-52. Each multithreaded processing unit includes a scheduler. /d. at
`
`1:53. The scheduler is configured to receive program instructions,
`
`determine the availability of source data, and schedule instructionsfor
`
`execution in a secondorderthat is independentofthe first order. Jd. at
`
`1:54—56. Each multithreaded processing unit includes a resource tracking
`
`unit that tracks the availability of source data, anda dispatcher configured to
`
`output program instructions in the secondorder to be executed by the
`
`multithreaded processingunit. /d. 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 threadare available, the
`
`program instructions associated with the second thread are dispatchedprior
`
`to dispatching program instructionsfor the first thread. Jd. at 2:7—22.
`
`Reasons to Combine the Teachings ofLindholm ’685 and
`3.
`Lindholm ’913
`
`Noting that Lindholm ’685 and Lindholm ’913 are both directed to a
`
`mu
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
