Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`________________
`
`LG ELECTRONICS, INC.,
`Petitioner,
`
`v.
`
`ATI TECHNOLOGIES ULC,
`Patent Owner.
`________________
`
`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`________________
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`PURSUANT TO 37 C.F.R. § 42.107(a)
`
`

`

`I.
`II.
`
`III.
`
`IV.
`
`TABLE OF CONTENTS
`
`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`PAGE
`
`2.
`
`i
`
`Introduction & Summary of Arguments..........................................................1
`Graphics Processing Primer.............................................................................2
`Graphics Processors Use Vertex And Pixel Data To Create
`A.
`Display Images......................................................................................2
`Graphics Processors Use Instruction “Threads” To Transform
`Vertex and Pixel Data ...........................................................................5
`Conventional Graphics Processors Executed Vertex And Pixel
`Threads Using Separate Vertex Shaders And Pixel Shaders................7
`The ’454 Patent................................................................................................9
`The ’454 Patent’s Unified Shader.........................................................9
`A.
`The Unified Shader Can Simultaneously Execute Vertex And
`B.
`Pixel Threads.......................................................................................11
`The ’454 Patent’s Challenged Claims.................................................12
`1.
`Challenged claim 2 is directed to a unified shader
`processor that executes pixel or vertex thread instructions
`in response to receiving selected data from a register ..............12
`Challenged claims 3-11 are directed to a unified shader
`that includes a processor that can switch back and forth
`between performing unfinished vertex and pixel threads.........13
`LG’s Petition Fails To Establish The Required Likelihood Of Success
`On Any Grounds............................................................................................15
`Challenged Claim 2: LG’s Grounds 1-4 Fail To Identify A
`A.
`Processor Unit That Generates Pixel Color, Vertex Position,
`And Vertex Appearance Data In Response To Selected Data
`From The General Purpose Register...................................................16
`Challenged Claims 3-11: LG’s Petition Fails To Identify A
`Unified Shader Processor That Can Switch Back And Forth
`Between Performing Unfinished Vertex And Pixel Threads..............19
`Grounds 1 & 2: Lindholm .........................................................21
`1.
`
`B.
`
`C.
`
`C.
`
`B.
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`2.
`
`a.
`
`The purported Lindholm unified shader processor does not
`switch back and forth between unfinished vertex and pixel
`threads ...............................................................................21
`b. LG’s Petition fails to identify a Lindholm unified shader
`processor that can switch back and forth between
`performing unfinished vertex and pixel threads ...............25
`Grounds 3 & 4: Stuttard............................................................26
`The purported Stuttard unified shader processor does not
`a.
`switch back and forth between unfinished vertex and pixel
`threads ...............................................................................26
`b. LG’s Petition fails to identify a Stuttard unified shader
`processor that can switch back and forth between
`performing unfinished vertex and pixel threads ...............31
`i.
`Claim 11..................................................................31
`
`ii. Claims 3-10.............................................................35
`
`V.
`
`Conclusion .....................................................................................................35
`
`ii
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`TABLE OF AUTHORITIES
`
`Page(s)
`
`Cases
`Ariosa Diagnostics v. Verinata Health, Inc., et al.,
`IPR2013-00276, Paper 43 (PTAB Oct. 23, 2014)..............................................34
`
`Callcopy v. Verint Americas, et al.,
`IPR2013-00486, Paper 11 (PTAB Feb. 5, 2014)................................................33
`
`In re Chaganti,
`554 Fed. Appx. 917 (Fed. Cir. 2014)..................................................................33
`
`In re Karn,
`441 F.3d 997 (Fed. Cir. 2006) ............................................................................33
`
`Symantec Corp. v. RPost Communications Ltd.,
`IPR2014-00355, Paper 12 (PTAB Jul. 15, 2014)...............................................33
`
`iii
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`I.
`
`Introduction & Summary of Arguments
`
`For at least the following reasons, LG’s Petition fails to establish the
`
`required likelihood that it will prove that challenged claims 2-11 of ATI’s U.S.
`
`Patent No. 8,760,454 are unpatentable.
`
` Challenged claims 3-11 are directed to a unified shader processor
`
`that can switch back and forth between executing unfinished vertex and pixel
`
`threads, but LG fails to identify any such unified shader processor in the asserted
`
`references. In the Lindholm reference of Grounds 1 and 2, the purported processor
`
`cannot switch between unfinished threads at all, be they pixel, vertex, or other. In
`
`the Stuttard reference of Grounds 3 and 4, the purported processor unit likewise
`
`cannot switch back and forth between unfinished vertex and pixel threads, but must
`
`instead finish executing all vertex threads before it can begin executing any pixel
`
`threads.
`
` Challenged claim 2 requires a unified shader processor that executes
`
`certain pixel or vertex thread instructions in response to receiving selected data
`
`from a data register. But LG’s Petition does not even allege that the purported
`
`processor units of Lindholm or Stuttard execute any of those pixel or vertex thread
`
`instructions “in response to” the selected data as required by the explicit claim
`
`language. Instead, the Petition ignores the limitation altogether.
`
`1
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`For each and all of these reasons, the Board should deny LG’s Petition in its
`
`entirety and not institute inter partes review of the ’454 Patent.
`
`II. Graphics Processing Primer
`
`The ’454 Patent and its challenged claims generally concern graphic
`
`processors and, more specifically, graphics processors that use a “unified shader”
`
`to perform both “vertex” and “pixel” operations. (E.g., ’454 Patent at 1:32-34,
`
`2:58-61).
`
`A.
`
`Graphics Processors Use Vertex And Pixel Data To Create
`Display Images
`
`Graphics processors are designed to convert a three-dimensional object into
`
`an image for display on a two-dimensional screen. As part of this process, a three-
`
`dimensional object is rendered as a collection of simple shapes, called primitives.
`
`For example, in the figure below, a three-dimensional character has been rendered
`
`as a collection of triangular primitives.
`
`2
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`Each triangular primitive is defined by the positions of its three corner
`
`points, i.e., its “vertices.” After a three-dimensional object is rendered as a group
`
`of primitives, subsequent processing steps include converting the vertices of each
`
`primitive from three-dimensional coordinates to two-dimensional coordinates. To
`
`illustrate, in the example shown below, a triangular primitive is being used to
`
`render a portion of a sphere and has vertices with three-dimensional position
`
`coordinates along the X-, Y-, and Z- axes. These three-dimensional vertices
`
`coordinates are converted into two-dimensional coordinates (along only the X- and
`
`Y- axes) for display on a two-dimensional screen.
`
`3
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`X Y
`
`X Y
`
`X
`
`Y
`
`X Y
`
`Z
`
`X YZ
`
`X YZ
`
`X YZ
`
`Y
`
`X
`
`Subsequent processing steps include rendering each primitive as two-
`
`dimensional collection of dots on a screen called “pixels.” As part of this process,
`
`the graphics processor uses the two-dimensional vertices coordinates to determine
`
`which pixels fill a particular primitive. In the illustration below, the pixels that fill
`
`the primitive defined by the XY coordinates are depicted in blue.
`
`4
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`X Y
`
`X Y
`
`Y
`
`X Y
`
`X
`
`Further processing includes identifying the correct color and texture for each
`
`pixel filling the primitive.
`
`B.
`
`Graphics Processors Use Instruction “Threads” To Transform
`Vertex and Pixel Data
`
`Graphics processors use various collections of instructions to transform a
`
`three-dimensional object
`
`into a two-dimensional display.
`
`Each particular
`
`collection of instructions is called a “thread.”
`
`5
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`Each thread contains a sequence of instructions to be performed one after
`
`another. Each instruction consists of an “OpCode” and an “Operand.” The
`
`OpCode indicates which calculation operation is required by the instruction, such
`
`as an arithmetic or logical operation. The Operand indicates the location of the
`
`graphics data upon which the calculation operation is to be performed.
`
`An Exemplary 16-bit Instruction
`
`Some threads comprise instructions that manipulate and transform vertex
`
`data. These threads are known as “vertex threads,” and can include instructions
`
`that, for example, work together to transform a triangular primitive’s vertex
`
`coordinates from three-dimensional to two-dimensional (as discussed above), to
`
`translate or scale the primitive,
`
`to remove off any portion of the triangular
`
`primitive that may be off the screen, or to cull primitives that don’t project onto the
`
`screen.
`
`Other threads comprise instructions that manipulate and transform pixel
`
`data. These threads are known as “pixel threads,” and can include instructions
`
`that, for example, work together to transform pixel data by assigning color value to
`
`6
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`the pixels, determining lighting effects, determining texture coordinate values, and
`
`blending colors.
`
`C.
`
`Conventional Graphics Processors Executed Vertex And Pixel
`Threads Using Separate Vertex Shaders And Pixel Shaders
`
`Conventional graphics processors featured a number of circuits, each
`
`configured to perform a single type of transformation. These circuits are known as
`
`“shaders.”
`
`Conventionally, each shader was dedicated to executing a particular type of
`
`thread to transform a particular type of data. For example, a “vertex shader” would
`
`execute only vertex threads to transform vertex data, such as, for example,
`
`transforming the three-dimensional coordinates of a primitive’s vertices in object
`
`space into two-dimensional coordinates for a display screen. (’454 Patent at 1:63 –
`
`2:7). But to execute pixel threads to transform pixel data, another, separate shader
`
`was needed. This type of shader is known as a “pixel shader,” and was used, for
`
`example, determine and apply the color for each pixel making up a rendered
`
`object. (’454 Patent at 2:8-18).
`
`Thus, to execute the position and color threads and operations necessary to
`
`transform a three-dimensional object to a two-dimensional display, a conventional
`
`graphics processor needed at least two shaders, one a vertex shader and the other a
`
`pixel shader.
`
`(’454 Patent at 2:15-18). As described in the ’454 Patent, this
`
`7
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`requirement resulted in drawbacks in both size and performance. First, the need
`
`for multiple specialized shaders increased the size of graphics processors:
`
`Conventional graphics processors require the use of both a
`vertex shader and a pixel shader in order to generate an object.
`Because both types of shaders are required, known graphics
`processors are relatively large in size, with most of the real estate
`being taken up by the vertex and pixel shaders.
`
`(’454 Patent at 2:20-29).
`
`Second, sequencing the pixel shader after the vertex shader meant that one
`
`shader was dependent on – and had to wait for – the output of the other before it
`
`could continue processing, leading to idle downtime that slowed down the graphics
`
`processor and resulted in relatively poor performance:
`
`In addition to the real estate penalty associate with conventional
`graphics processors,
`there is also a corresponding performance
`penalty associated therewith. In conventional graphics processors, the
`vertex shader and the pixel shader are juxtaposed in 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.
`
`(’454 Patent at 2:20-29).
`
`Such a prior art “pipeline” is illustrated in Figure 3 of the ’454 Patent, which
`
`depicts a vertex shader 46 in series with pixel shader 54.
`
`8
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`III. The ’454 Patent
`
`The ’454 Patent issued June 24, 2014 and is titled “Graphics Processing
`
`Architecture Employing A Unified Shader.”
`
`A.
`
`The ’454 Patent’s Unified Shader
`
`As its title suggests, the ‘454 patent solves the real estate and performance
`
`problems of separate vertex and pixel shaders by providing a shader that is capable
`
`of executing both vertex threads and pixel threads to transform both vertex and
`
`pixel data, respectively. (’454 Patent at 2:58-61). This multipurpose shader “is
`
`referred to as a ‘unified’ shader.”
`
`9
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`In an embodiment described in the patent, the unified shader includes a
`
`register, a sequencer, and a processor.
`
`(’454 Patent at 3:4-10). The unified
`
`shader’s register stores the inputs transmitted to the unified shader, including the
`
`vertex and pixel data that are to be transformed by the unified shader. (’454 Patent
`
`at 3:4-5, 4:29-39).
`
`The unified shader’s sequencer stores the individual instructions that, when
`
`sequenced together, comprise the vertex and pixel threads that the unified shader
`
`will use to manipulate and transform the stored vertex and pixel data. (’454 Patent
`
`at 3:4-10, 4:52 - 5:31). The ’454 Patent refers to those individual instructions (i.e.,
`
`the logical and arithmetic operations) as vertex and pixel “calculation operations.”
`
`(’454 Patent at 3:4-7, 3:63-66, 4:42-45, 4:53-60, 5:36-52). The resulting threads
`
`are called vertex and pixel “manipulation operations.” (’454 Patent at 3:4-7. 5:19-
`
`36).
`
`The unified shader’s processor can execute the vertex and pixel instructions
`
`and threads (stored in the sequencer) on the vertex and pixel data (stored in the
`
`register). (’454 Patent at 3:4-12). The unified shader is thus configured to perform
`
`as both a pixel shader and a vertex shader. (’454 Patent at 2:58-61, 3:10-12, 5:19-
`
`31).
`
`10
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`B.
`
`The Unified Shader Can Simultaneously Execute Vertex And
`Pixel Threads
`
`In addition to describing a unified shader that can handle both vertex data
`
`and pixel data, the ’454 Patent further addresses issues associated with such a
`
`unified shader. For example, one such issue is how to allocate the unified shader’s
`
`resources among vertex and pixel data in a manner that prevents backlogs of data
`
`waiting to be processed and idle downtime for the shader.
`
`One approach the ’454 Patent discloses for increasing efficiencies and
`
`decreasing processing time is to employ a unified shader that can execute vertex
`
`and pixel threads at the same time, switching back and forth between unfinished
`
`threads to prevent downtime and backlogs of data sitting waiting to be processed.
`
`(E.g., ’454 Patent at 5:32-36).
`
`For example, when executing the sequence of instructions in a vertex thread,
`
`the unified shader may encounter a vertex calculation operation instruction that it
`
`cannot yet perform because the necessary data or memory is not yet available.
`
`(’454 Patent at 5:36-44).
`
`Rather than having the unified shader sitting idle,
`
`waiting for the necessary data or memory so that it can execute the next vertex
`
`calculation operation and proceed with the vertex thread, the ’454 Patent discloses
`
`the unified shader switching to pending pixel
`
`threads and instructions and
`
`11
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`executing pixel instructions until the idle vertex thread is ready to proceed. (’454
`
`Patent at 5:32-52).
`
`Thus, the ’454 Patent discloses a unified shader that “has the ability to
`
`simultaneously perform vertex manipulation operations [vertex threads] and pixel
`
`manipulation operations [pixel threads] at various degrees of completion by being
`
`able to freely switch between such program or instructions [stored in the unified
`
`shader’s register] very quickly.” (’454 Patent at 5:32-36). “[T]hrough the sharing
`
`or resources within the unified shader 62, processing of image data is enhanced as
`
`there is no down time associated with the processor 96.” (’454 Patent at 5:49-52).
`
`C.
`
`The ’454 Patent’s Challenged Claims
`
`The Petition challenges claims 2-11 of the ’454 Patent. Challenged claims
`
`2, 3, 4, 5, and 11 are independent claims. Challenged claims 6-10 depend directly
`
`or indirectly from independent claim 5.
`
`1.
`
`Challenged claim 2 is directed to a unified shader processor
`that executes pixel or vertex thread instructions in response
`to receiving selected data from a register
`
`Challenged claim 2 is directed to a unified shader that includes (1) a register
`
`for storing data and (2) a processor unit that generates pixel color and vertex
`
`position and appearance data “in response to” receiving selected data from that
`
`register:
`
`2. A unified shader, comprising:
`
`12
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`a general purpose register block for maintaining data;
`
`a processor unit;
`
`a sequencer, coupled to the general purpose register block and the
`processor unit, the sequencer maintaining instructions operative
`to cause the processor to execute vertex calculation and pixel
`calculation operations on selected data maintained in the general
`purpose register block; and
`
`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.
`
`(’454 Patent at claim 2)(emphasis added).
`
`2.
`
`Challenged claims 3-11 are directed to a unified shader that
`includes a processor that can switch back and forth between
`performing unfinished vertex and pixel threads
`
`Claims 3-11 are all directed to a unified shader having a processor unit that
`
`can switch back and forth between unfinished vertex and pixel threads. For
`
`example, the unified shader of claim 11 includes a processor that is flexibly
`
`controlled to perform pixel and vertex threads (“manipulation operations”) and can
`
`switch back and forth between performing the instructions in those threads before
`
`the vertex and pixel threads are completed:
`
`11. A unified shader comprising:
`
`13
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`a processor unit flexibly controlled to perform vertex
`manipulation operations and pixel manipulation operations
`based on vertex or pixel workload; and
`an instruction store and wherein the processor unit of the unified
`shader performs the vertex manipulation operations and pixel
`operations at various degrees of completion based on
`switching between instructions in the instruction store.
`
`(’454 Patent at claim 11)(emphasis added).
`
`Similarly, each of the unified shaders of claims 3-10 includes a processor
`
`unit that can perform both vertex thread instructions and pixel thread instructions
`
`and can switch back forth between performing those instructions when certain
`
`conditions are met, regardless of whether the subject thread is completed. In claim
`
`3, for example, the claimed unified shader processor performs pixel thread
`
`instructions (“calculation operations”) until there are enough resources to perform
`
`a vertex thread instruction, at which point the processor starts performing the
`
`vertex thread instruction, regardless of whether that processor has completed the
`
`ongoing pixel thread:
`
`3. A unified shader comprising:
`a processor unit operative to perform vertex calculation operations
`and pixel calculation operations; and
`shared resources, operatively connected to the processor unit;
`the processor unit operative to use the shared resources for either
`vertex data or pixel information and operative to perform pixel
`
`14
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`calculation operations until enough shared resources are
`available and then use the shared resources to perform vertex
`calculation operations.
`(’454 Patent at claim 3 (emphasis added); see, also, claim 4 (“processor unit …
`
`operative to perform vertex calculation operations until enough shared resources
`
`are available and then use the shared resources to perform pixel calculation
`
`operations); claim 5 (“a sequencer … operative to cause the processor to execute
`
`vertex calculation and pixel calculation operations … depending on an amount of
`
`space available in the store).
`
`IV. LG’s Petition Fails To Establish The Required Likelihood Of Success
`On Any Grounds
`
`The Petition seeks institution and trial on the following Grounds:
`
`Ground
`
`1
`
`2
`
`3
`
`4
`
`Reference
`
`Lindholm
`
`Lindholm, OpenGL
`
`Stuttard
`
`Stuttard
`
`Basis
`
`Challenged Claims
`
`§ 102(e)
`
`§ 102(a)
`
`§ 103(a)
`
`§ 103(a)
`
`2-11
`
`2-11
`
`2, 11
`
`2-11
`
`LG’s Petition fails to establish the required likelihood success for any of
`
`these grounds, for at least the following reasons:
`
`(1)
`
`Challenged claim 2 requires a unified shader processor that
`
`generates specific pixel and vertex data “in response to” receiving selected data
`
`15
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`from a register, but LG’s Grounds 1-4 ignore this “in response to” limitation
`
`entirely.
`
`(2) Challenged claims 3-11 require a processor that can switch back and
`
`forth between executing unfinished vertex and pixel threads, but LG fails to
`
`identify any such unified shader processor in any of the asserted references.
`
`A.
`
`Challenged Claim 2: LG’s Grounds 1-4 Fail To Identify A
`Processor Unit That Generates Pixel Color, Vertex Position, And
`Vertex Appearance Data In Response To Selected Data From The
`General Purpose Register
`
`Challenged claim 2 requires a unified shader processor unit that generates
`
`pixel color, vertex position, and vertex appearance data in response to selected
`
`data from the general purpose register. For example, the claimed processor
`
`executes pixel instructions that generate a pixel’s color in response to receiving
`
`selected data from the register: “the processor unit executes instructions that
`
`generate a pixel color in response to selected data from the general purpose
`
`register block.” (’454 Patent at claim 2)(emphasis added). Similarly, the processor
`
`executes vertex instructions to generate vertex position and appearance data in
`
`response to receiving other selected data from the register: “the processor unit
`
`executes instructions that … generates vertex position and appearance data in
`
`response to selected data from the general purpose register block.” (’454 Patent at
`
`claim 2)(emphasis added).
`
`16
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`But LG’s Petition does not even allege in Counts 1-4 that the asserted
`
`references describe or make obvious such a processor unit, and therefore, the
`
`Petition against claim 2 fails on its face.
`
`Indeed, the phrase “in response to” is
`
`wholly and fatally missing from LG’s allegations and arguments – it does not even
`
`conclusorily allege or explain how that the limitation is disclosed in the references,
`
`much less identify evidence sufficient to meet its burden on that issue.
`
`For example, in Grounds 1-2, the Petition does not allege or identify any
`
`evidence that the purported “processor unit” (Lindholm’s Execution Unit 470)
`
`executes any pixel or vertex instructions to generate the specified pixel and vertex
`
`data “in response to” the selected data as required by claim 2.
`
`(E.g., Petition at
`
`18-19). Instead, the Petition addresses only whether, despite Lindholm’s silence on
`
`the subject, it was implicit or obvious that Lindholm’s Execution Unit 470 could
`
`execute instructions to generate pixel color and vertex location and appearance
`
`data as required by claim 2.
`
`(Petition at 18-19, 28-31). But LG fails to even
`
`allege, much less identify evidence supposedly showing, that the Execution Unit
`
`470 will perform any of such instructions “in response to” the selected data from
`
`the register.1 (Petition at 18-19, 28-31,35).
`
`1 Patent Owner does not concede any of the Petition’s allegations, including those
`
`not addressed in this Preliminary Response. For example, in addition to the claim
`
`17
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`Grounds 3 and 4 likewise fail
`
`to address claim 2’s “in response to”
`
`limitation: they do not even allege that Stuttard’s purported “processor unit”
`
`(processing block 106) executes pixel or vertex instructions “in response to” the
`
`selected data. (E.g., Petition at 47-48, 49). Instead, the Petition again ignores the
`
`limitation altogether and argues merely that Stuttard either discloses or makes
`
`obvious that processing block 106 could execute instructions that generated a pixel
`
`color or vertex location and appearance data. (Petition at 47-48, 49-50). But LG
`
`fails to allege, much less identify evidence supposedly showing, that processing
`
`block 106 will perform either of those instructions “in response to” the particular
`
`selected data received from the register. 2 (Petition at 47-48, 49-50).
`
`element identified here, Patent Owner also disputes other allegations in the Petition
`
`concerning Lindholm, including those regarding priority and collateral estoppel.
`
`But the Lindholm Grounds 1 and 2 can and should be rejected without reaching
`
`those issues, and they are therefore are not addressed herein.
`
`2 Again, Patent Owner does not concede any of the Petition’s allegations, including
`
`those not addressed in this Preliminary Response. For example, in addition to the
`
`claim elements identified here, Patent Owner also disputes other allegations in the
`
`Petition concerning Stuttard, but the Stuttard Grounds 3 and 4 can and should be
`
`18
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`Because the Petition’s Grounds 1-4 wholly fail to address the “in response
`
`to” limitations of claim 2, they necessarily fail to establish the required likelihood
`
`of success on those limitations and must be rejected.
`
`B.
`
`Challenged Claims 3-11: LG’s Petition Fails To Identify A Unified
`Shader Processor That Can Switch Back And Forth Between
`Performing Unfinished Vertex And Pixel Threads
`
`Claims 3-11 are all directed to a unified shader having a processor unit that
`
`can switch back and forth between unfinished vertex and pixel threads. For
`
`example, the unified shader of claim 11 includes a processor that is flexibly
`
`controlled to perform pixel and vertex threads (“manipulation operations”) and can
`
`switch back and forth between performing the instructions in those threads before
`
`either are completed: “the processor unit of the unified shader performs the vertex
`
`manipulation operations and pixel operations at various degrees of completion
`
`based on switching between instructions in the instruction store.” (’454 Patent at
`
`claim 11)(emphasis added).
`
`The unified shaders of claims 3-10 likewise include a processor unit that can
`
`perform both vertex thread instructions and pixel thread instructions and can
`
`switch back forth between performing those instructions when certain conditions
`
`rejected without reaching those issues, and they are therefore are not addressed
`
`herein.
`
`19
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`are met, regardless of whether the subject thread is completed. In claim 3, for
`
`example, the claimed unified shader processor performs pixel thread instructions
`
`(“calculation operations”) until there are enough resources to perform a vertex
`
`thread instruction, at which point the processor starts performing the vertex thread
`
`instruction, regardless of whether that processor has completed the ongoing pixel
`
`thread: “the processor unit operative to use the shared resources for either vertex
`
`data or pixel information and operative to perform pixel calculation operations
`
`until enough shared resources are available and then use the shared resources
`
`to perform vertex calculation operations.” (’454 Patent at claim 3 (see, also,
`
`claim 4 and 5).
`
`Despite having the burden to do so, LG neither identifies nor supports any
`
`proposed claim constructions for any of the foregoing processor unit limitations.
`
`(E.g., Petition at 8-9). Instead, without ascribing any meaning to the claims, the
`
`Petition generally alleges that the claimed processor unit is taught by Lindholm
`
`(Grounds 1 and 2) or Stuttard (Ground 3 and 4).3 (E.g., Petition at 20-25). But the
`
`3 In addition to Lindholm, LG’s Ground 2 also relies to a limited extent on the
`
`OpenGL reference. But Ground 2 does not rely on OpenGL for any of the missing
`
`limitations that are the subject of this Preliminary Response, and OpenGL is
`
`therefore irrelevant to the presented reasons for denying LG’s Petition.
`
`20
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`Petition identifies no evidence that the purported Lindholm or Stuttard unified
`
`shader processors can switch back and forth between unfinished vertex and pixel
`
`threads as required by claims 3-11.
`
`1.
`
`Grounds 1 & 2: Lindholm
`
`a.
`
`The purported Lindholm unified shader processor
`does not switch back and forth between unfinished
`vertex and pixel threads
`
`Grounds 1 and 2 are based on U.S. Patent No. 7,038,685 to Lindholm
`
`(Exhibit 1003), which describes a programmable graphics processor for
`
`“processing and allocating threads for multithreaded execution of graphics
`
`programs.” (Ex. 1003, Lindholm, at 1:36-43).
`
`As shown in Lindholm’s Figure 2 reproduced below, Lindholm’s graphics
`
`processor includes numerous “Execution Pipelines,” each of which LG argues is
`
`the claimed “unified shader.” (Petition at 14, 16-17, 29-30).
`
`21
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`Figure 2 further illustrates the Lindholm graphics processor also includes a
`
`Vertex Input Buffer 220, which stores all of the graphics input data (samples)
`
`provided by the host computer for processing by the Lindholm graphics processor.
`
`(Ex. 1003 at 3:9-26, 4:22-26, Figs. 1 & 2). Lindholm describes (and its Figure 4
`
`below illustrates) that each Execution Pipeline 240 (the alleged unified shader)
`
`includes a “Thread Control Unit,” which is configured to assign threads to a
`
`22
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`sample. (Ex. 1003 at 6:38 – 7:11). Once the Thread Control Unit 420 assigns a
`
`particular thread of instructions to a sample, a Thread Selection Unit 415 selects
`
`which of the assigned threads will be executed and identifies that thread (or
`
`threads) to Instruction Cache 410. (Ex. 1003 at 7:44-64, 8:15-17).
`
`Instruction Cache 410 is a cache that stores instructions and may (or may
`
`not) already include the instructions for the threads selected by Thread Selection
`
`23
`
`

`

`Case IPR2017-01225
`U.S. Patent No. 8,760,454
`
`Unit 415. (Ex. 1003 at 8:15-21). Instruction Cache determines which of the thread
`
`instructions it already has and then fetches any missing instructions from a
`
`graphics memory. (Ex. 1003 at 8L17-24). Instruction Cache 410 then outputs the
`
`selected thread’s sequence of instructions to an Instruction Scheduler 430.
`
`(Ex.
`
`1003 at 8:33-36).
`
`Instruction Scheduler 430 then determines which thread of instructions
`
`received from the Instruction Cache 430 will be executed. (Ex. 1003 at 8:47-58).
`
`After Lindholm’s Instruction Scheduler 430 schedules a thread for execution, the
`
`Instruction Dispatcher 440 fetches the sample data to be processed and provides it
`
`and the required instructions to Execution Unit 460 (see Figure 4 above).
`
`(Ex.
`
`1003 at 9:33-39). The Petition alleges that this Execution Unit 460 is the claimed
`
`“processor unit” from the challenged claims. (E.g., Petition at 18).
`
`Execution Unit 460 includes a Programmable Computation Units (PCU
`
`375), which executes the selected thread’s instructions. (Ex. 1003 at 5:25-30, 9:33-
`
`47). “When the program instructions associated with a thread have completed
`
`execution, the storage resources allocated to retain intermediate data generated
`
`during execution of the thread become available for allocation to another thread.”
`
`(Ex. 1003 at 9:57-60; see also 9:18-32).
`
`Because storage resources allocated to a thread will not be allocated to
`
`another thread until the instructions associated with that thread have completed
`
`24
`
`

`

`Case IPR2017-