0101
`
`Volkswagen 1002 - Part 2 of 8
`
`

`
`Applicationtcontrol Number: 10t459,797
`Art Unit: 2671
`
`Page 13
`
`The scan converter detennines which clusters ofpixei data are to be processed by which pipeline
`
`(Col. 11, lines 41-59; Col. 13, lines 54-63). Therefore, the scan converter is coupled to the back
`
`end circuitry (20), operative to determine the portion of the pixel data to be processed by the
`
`back end circuitry.
`
`It would have been obvious to one of ordinary skill in this art at the time of invention by
`
`applicant to modify the device of Alcorn so that each of the at least two graphics pipelines
`
`fitrther includes a scan converter as suggested by Furtner. Scan converting is the most popular
`
`method of drawing polygons because it uses only integer maths, takes up very little memory, and
`
`is simple to understand. The advantages of scan converters are well-known in the art and can be
`
`found in many publications, such as Elias’ website. Furtner suggests that it is advantageous to
`
`have a parallel scan converter for two graphics pipelines because the scan conversion can be
`
`performed in parallel (Col. 17, lines 7-22), which increases the speed of processing.
`
`37. With regard to Claim 1 1, Alcorn describes that the first ofthe at least two graphics
`
`pipelines (Col. 6, lines 33-35, 40-43) further includes circuitry (64, 72, Figure 3), coupled to the
`
`front end circuitry (60) and the back end circuitry (76), operative to provide positioircoordinates
`ofthe pixels within the first set oftiles (Col. 10, lines 1-8; texel data outputfrom the parameter
`
`interpotator circuit 64 is provided to the titer 72, which determines the address of thefour
`
`texel.s...checi’rs to determine whether each is wtthin the boundary ofthe teitture... texe! data
`
`includes the interpolated S, Tcoordinates as wet! as the map number, Col. 11, lines 8-31) to be
`
`processed by the back end circuitry (S, T coordinatesfor each display screen pixel are provided
`
`from the parameter-in-terpolators, through the titer, to texel interpalator 76, Col. 12, lines 13-
`
`0102
`
`

`
`Applicationlcontrol Number: 101459.797
`Art Unit: 2671
`
`Page 14
`
`20), the circuitry including a pixel identification line for receiving tile identification data
`
`indicating which of the set of tiles is to be processed by the back end circuitry (texe! data
`
`includes the interpolatedS, T coordinates as wet! as the map number, Col. ll, lines 15-17).
`
`However, Alcorn does not teach a scan converter. However, Furtner describes a parallel
`scan converter (16, Figure 23) that has a plurality of outputs for supplying data to a plurality of
`
`,
`
`pixel pipelines (20, Co]. 2, lines 3-16). Therefore, the first of the at least two graphics pipelines
`
`fiirther includes a scan converter. The scan converter receives, at its input, data which to write
`
`onto the graphic primitive to be processed (Col. 1, lines 58-62), and this data inherently comes
`
`from a front end circuitry. The output of the scan converter is connected to the pipelines (20,
`
`Col. 1, lines 62-66). Therefore, the scan converter is coupled to the front end circuitry and the
`
`back end circuitry (20). The scan converter determines which clusters of pixel data are to be
`
`processed by which pipeline (Col. 11, lines 41-59; Col. 13, lines 54-63). The scan converter has
`
`knowledge with regard to mapping the screen areas onto the memory address area (tiling) (Col:
`
`6, lines 60-65). Therefore,'the scan converter is inherently operative to provide memory
`
`addresses or position coordinates oithe pixels within the first set of tiles to be processed by the
`
`back end circuitry, the scan converter inherently including a pixel identification line for receiving
`
`tile identification data indicating which of the set of tiles is to be processed by the back end
`
`circuitry. This would be obvious for the same reasons given in the rejection for Claim 5.
`
`38. With regard to Claim 13, Claim 13 is_simila.r in scope to Claim 11, and therefore is
`
`rejected under the same rationale.
`
`0103
`
`

`
`App|ication!Control Number: 10f459,797
`
`Page 15
`
`Art Unit: 2671
`
`39. With regard to Claim 15, Claim 15 is similar in scope to Claim 11, and therefore is ‘
`
`rejected under the same rationale.
`
`40.
`
`With regard to Claim 16, Claim 16 is similar in scope to Claim 1 1, and therefore is
`
`rejected under the same rationale.
`
`41. With regard to Claim 24, Alcorn describes a graphics processing circuit (Col. 3, lines 53-
`
`63), comprising front end circuitry (3 2A, 32B, 32C, Figure 2) operative to generate pixel data in
`
`response to primitive data for a primitive to be rendered (distributes 3-D primitive data evenly
`
`_ among the 3-D geometvy accelerator chips, Col. 6, lines 43-47; each 3-D geometry accelerator
`
`chip prdcessesprimitive data, Col. 6, lines 56-62; rendering hardware interpoiaies the primitive
`
`data to compute the display screen pixels that are turned on to represent each primitive, Col. 1,
`
`lines 31-33); first
`
`end circuitry (12), coupled to the front end circuitry (Col. 7, lines 5-10),
`
`operative to receive and process a portion of the pixel data (Col. 12, lines 13-20) in response to
`
`position coordinates (Col. 12, lines 13-20); circuitry (64, 72), coupled between the front end
`
`circuitry and the first back end circuitry (76), operative to determine which set of tiles (tiler, Col.
`
`1 1, lines 8-31) of a repeating tile pattern (Col. 11, lines 35-50) are to be processed by the first
`
`back end circuitry (Col. 11, lines 8-3 1). Alcorn discloses that the repeating tile pattern includes a
`
`horizontally and vertically repeating pattern of square regions (Col. 15, lines 44-57), as shown in
`
`Figure 6. Aicorn describes providing the position coordinates to the first back end circuitry in
`
`response to the pixel data (Col. 12, lines 13-20). Aloorn describes a memory controller (5 0,
`
`0104
`
`

`
`Applicationlcontrol Number: 101459397
`
`'
`
`Page 16
`
`Art Unit: 2671
`
`Figure 2), coupled to the at least two graphics pipelines, operative to transmit and receive the
`
`processed pixel data (Col. 6, lines 33-3 5, 40-43; Col. 8, lines 27-40).
`
`However, Alcorn does not teach two back end circuitries and two scan converters.
`
`However, Furtner describes a first scan converter (16, Figure 23). The flrst scan converter
`
`receives, at its input, data which to write onto the graphic primitive to be processed (Col. 1, lines
`58-62), and this data inherently comes from a fi'ont end circuitry. The output ofthe scan
`
`converter is connected to the pipelines (20, Col. 1, lines 62-66). Therefore, the first scan
`
`converter is coupled to the front end circuitry and the first back end circuitry (20). The scan
`
`converter determines which clusters of pixel data are to be processed by which pipeline (Col.
`
`1 1,
`
`lines 41-59; Col. 13, lines 54-63). Therefore, the first scan converter is operative to determine '
`
`which set of tiles are to be processed by the first back end circuitry. The scan converter has
`
`knowledge with regard to mapping the screen areas onto the memory address area (tiling) (Col.
`
`6, lines 60-65). Therefore, the first scan converter is inherently operative to provide the memory
`
`, address area or position coordinates to the first back end circuitry in response to the pixel data.
`
`Furtner describes multiple pipelines, and each pipeline processes a cluster ofpixel data (Col. 11,
`
`lines -'41-59; Col. 13, lines 54-63). The scan converter is 21 parallel scan converter, and provides
`
`data to the multiple pipelines in parallel (Col. 2, lines 3-16), so the scan converter is considered
`
`to be similar to twolscan converters, and the second scan converter performs in a similar manner
`
`as the first scan converter for the second back end circuitry. This would be obvious for the same
`
`reasons given in the rejection for Claim 5.
`
`0105
`
`

`
`Applicationfcontrol Number: 10l459,79?
`
`Art Unit: 2671
`
`Allowable Subject Matter
`
`42.
`
`Claim 19 is objected to as being dependent upon a rejected base claim, but would be
`
`allowable if rewritten in independent form including all of the limitations of the base claim and
`
`any intervening claims.
`
`The following is a statement ofreasons for the indication of allowable subject matter:
`
`43.
`
`The prior art singly or in combination do not teach or suggest that each separate chip
`
`creates a bounding box around the polygon and wherein each corner ofthe bounding box is
`checked against a super tile that belongs to each separate chip and wherein ifthe bounding box
`
`does not overlap any of the super tiles associated with a separate chip, then the processing circuit
`
`rejects the whole polygon and processes a next one, as recited in Claim 19.
`
`44.
`
`The closest prior art (Kent) teaches calculating the bounding box of the primitive and
`
`testing this against the VisRect. If the bounding box of the primitive is contained in the other
`
`Pl0’s superltile the primitive is discarded at this stage [OI29]. The method used is to calculate
`
`the distance from each subpixel sample point in the point’s bounding box to the point’s center
`
`and compare this to the point’s radius. Subpixel sample points with a distance greater than the
`radius do not contribute to a pixel’s coverage. The cost ofthis is kept low by only allowing
`
`small radius points hence the distance calculation is a small multiply and by taking a cycle per
`
`subpixel sample per pixel within the bounding box [0144]. However, Kent does not teach that
`
`each separate chip creates a bounding box around the polygon and wherein each corner of the
`
`bounding box is checked against a super tile that belongs to each separate chip and wherein if the
`
`0106
`
`

`
`Applicationlcontrol Number: 10!459,797
`Art Unit: 2671
`
`'
`
`Page 18
`
`bounding box does not overlap any of the super tiles associated with a separate chip, then the
`
`processing circuit rejects the whole polygon and processes a next one.
`
`Prior Art of Record
`
`The prior art made of record and not relied upon is considered pertinent to applicant's
`
`disclosure.
`
`1.
`
`US 20030164 830Al teaches a ‘graphics pipeline [0006] that calculates the bounding box
`
`of the primitive in a super tile [0I29].7
`
`2.
`
`Elias, Hugo. “Polygon Scan Converting.”
`
`httpzf/freespace.vi[gin.netfhugo.e1ias/grep’hics/x pol1sc,htrn.
`
`Any inquiry concerning this communication or earlier communications from the
`
`— Conclusion
`
`examiner should be directed to Joni Hsu whose telephone number is 5‘71~2'72-7785. The
`
`examiner can normally be reached on M-F Sam-Spm_.
`
`If attempts to reach the examiner by telephone are unsuccessfirl, the examiner’s
`supervisor, Ulka Chauhan can be reached on 571-272-7782. The fax phonenurnber for the
`
`organization where this application or proceeding is assigned is 571-273-3300.
`
`0107
`
`

`
`Applicatiohlcontrol Number: 10145939?
`Art Unit: 2671
`
`A
`
`-
`
`Page 19
`
`Information regarding the status of an application may be obtained from the Patent
`
`Application Information Retrieval (PAIR) system. Status information for published applications
`
`may be obtained from either Private PAIR or Public PAIR. Status information for unpublished
`
`applications is available through Private PAIR only. For more information about the4PAIR
`
`system, see http:/fpair-direct.uspto.gov. Should you have questions on access to the Private PAIR
`
`system, contact the Electronic Business Center (BBC) at 866-217-9197 (toll-fi'ee).
`
`0108
`
`

`
`Notice of References Cited
`
`App|ication!Control No.
`worms?
`Examiner
`
`Applicant(s)o'Patent Under
`[‘é’A°3‘r“H".‘;'Ff.‘£$"AL
`Art Unit
`
`Joni Hsu
`
`2671
`
`Page 1 0”
`
`IIMIWWWHI M
`Cuuniry code-Numhe:-Ifind Dude
`MM.
`In 04-1998
`Ill 08-2004
`I 09-2003
`III
`IE
`
`u.s. PATENT nbcumenrrs
`
`Aicorn et al.
`Funner, Wolfgang
`Kent, Osman
`
`.
`IH%flII
`
`I I
`
`Ii
`
`03
`
`lflfl
`
`iil
`
`Classification
`
`H.
`
`include as appiiuable: Author, Title Date, Publisher, Edition or Volume. Pertinent Pages)
`
`Elias, Hugo. “Polygon Scan Converting" hitp:i'i‘freespace.virgin.netihugo.eliasigraphicslx__|:$oiyec.htm.
`
`NON-PATENT DOCUMENTS
`
`
`
`‘A copy at this reierenee is not being lurnished wiih ihis_Oifiee action. (See MPEP § TO‘i’.05(a).)
`Dates in Miiil-YYYY format are publiczlian dates. Classifications may be US or foreign.
`u.s. Patent and Tmdelnlrii Office
`PTO-892 (Rev. 01-2001)
`
`Notice of References cited
`
`Part of Paper No. 31705
`
`0109
`
`

`
`.. IPC-lygon Scan Converting
`
`Page 1 of5
`
`Polygon Scan Converting
`
`There are many ways to draw polygons. All have their uses. Some are fast, others very slow. The most
`popular method, used in practically every game, rendering engine, and graphics package which handles
`polygons, is known as scan converting.
`
`This method uses only integer maths, takes up very little memory, and is simple to understand. The
`algorithm can be adapted to handle flat or gourad shaded, textured and hump mapped polygons.
`
`It is an approximate method. You will never be able to draw a totally perfect polygon with smooth edges
`on a normal screen, because of the fact that the picture is divided up into pixels. It is possible to make
`the edges look better, but the edges will nevertheless look jaggy.
`
`.. On a pixelated screen, a small
`polygon like this will end up .
`' with nasty edges when viewed
`' close up.
`
`. The method works by taking the
`-- polygon a line at a time,
`processing all the edges, then
`" filling in the surface. lfyou
`haven't already, take a look at
`the page about drawing lines. You will find this very helpful.
`
`--
`
`A single scan conversion is the processof converting a polygon edge into data which can be used by the
`polygon filling routine. The process is essentially a single case of the line drawing algorithm. A polygon
`edge is calculated as if it were a line, but the line is not drawn to the screen. Instead the information is
`_
`saved in a buffer for use later.
`Rather than having a different routine to handle nearly horizontal or nearly vertical lines, all edges are
`handled as nearly vertical.
`
`So the line algorithm travels down an edge, calculating the X-coordinate of the pixel which lies closest
`to the line for each Y~coordinate.
`'
`
`Having calculated the x-coordinates for every edge of the polygon, the next step is to loop through the-
`Y-coordinates spanned by the top and bottom of the polygon, and draw lines between pairs of X-
`coordinates.
`
`1.
`Scan convert first edge.
`
`2.
`Scan convert second edge. .-
`
`httpzl/freespacevirgin.netfhugo.eliasfgraphicsfx_polysc.htm
`
`W26/05
`
`0110
`
`

`
`._Polygon Scan Converting
`
`Page 2 of 6
`
`in;
`
`Scan convert third edge.
`
`Scan convert fourth edge H H
`
`edges have been scan-
`converted, you need to begin
`__ filling. Start at the top of the
`__
`... polygon, and draw a horizontal
`-- strip between the left and right
`-; edges. Work your way down,
`" drawing horizontal strips across
`the polygon until it is filled.
`
`‘ One filled polygon.
`
`Now that you know the basic idea behind it, there are many things to consider.
`
`how do you store the in values?
`
`For convex polygons, there is a very quick and easy way to handle this. Create two arrays of integers,
`big enough to store an x value for each scanline of the screen. Call them Lefi and Right.
`-
`For example, for a 320x200 screen:
`
`'
`
`Left(O to 199)
`Rightlfl to 199)
`
`:
`:
`
`integer
`integer
`
`Now if you always list the points of the polygon in anti-clockwise order. Then you can easily determine
`which lines make up the left and the right edges of the polygon. Lines who's first point is above the
`second make up the left edges. Lines who's first point is below the second make up the right edges.
`Lines who's points lie at the same y coordinate can be ignored. Store the X values in either the Left or
`Right arrays accordingly. Then, when you come to fill the polygon, the x coordinates are already there in
`the right order.
`
`which points to Fill?
`
`Ifyou use a simple line drawing algorithm to calculate the x-coordinates, you will find that many of the
`pixels drawn will actually lie slightly outside the boundaries of the polygon. This means that where
`polygons share the same edge, some pixels will be drawn twice. Now, this may or may not be a bad
`thing. It depends on how perfectly you need your polygons to be drawn. In many cases, if the polygons
`- are flat shaded, people will never notice the fact. However, you may have transparent polygons, in
`which case you will get funny looking pixels at the boundaries between polygons, Where the surface
`appears to be double thickness. It can be fatal however. Ifthe edge of a texture mapped polygon lies
`very close to it's vanishing point at an oblique angle, a pixel outside the polygon may just lie past the
`horizon. In many perspective correct texture mapping routines, this could cause a divide by zero error.
`
`http :1’/freespace.vii-ginnetlhugo.eliaslgraphics/x_polysc.htm
`
`7l26f05
`
`0111
`
`

`
`. Polygon Scan Converting
`
`These should be avoided at all cost.
`
`In these_cases, it is essential to write a scan-converter which guarantees that all pixels lie within the
`polygon's bounds:-ies._This is, of course, easier said than done. What about pixels that lie exactly on a
`polygon boundary?
`'
`"
`
`I now present what I believe to be a perfect scan-converting routine. It allows you to specify the verti ces
`of the polygon to non-integer coordinates on the screen. This makes the polygon move a lot more
`fluidly. It also draws pixels which lie inside the edges of the polygon.
`
`Perfect scan converting
`
`OK, so this routine is going to use non-integer maths. That does not mean you will need slow floating
`point code. This can all be done with resonably fast fixed point maths, which can be handled extremely
`fast in assembler. Even faster, dare I say it, than the integer codel gave for drawing lines. Ifyou don't
`know about fixed point maths, then you'll have to either find out for yourself, wait till I write a
`document on it, or just use floating point code for now.
`
`Perfectly scanned polygons move much more smoothly than those calculated with integer maths, and so
`are more pleasing to the eye. Take a look at Quake, then Tomb Raider or Syndicate Wars. You will see
`that the cheap polygons in Tomb Raider move in a rather jittery way, making the scenery look like it's
`held together with selotape. Quake's smoothly rendered polygons on the other hand give the architecture
`a more solid feel.
`
`There is a demo available showing the difference between integer and Fixed Point polygons. It requires
`DQ5[4giW to run.
`
`So, lets take a really close look at the edges of a polygon:
`
`OK, this may get complicated, and
`involve a little maths, but the
`results are excelent.
`
`Take a close look at the line that is
`
`to be scan converted, the yellow
`one. The two points that it is being
`drawn between (white dots (x1,y1)
`& (x2,y2)) do not lie exactly at the
`center of any pixel, (green dots).
`However, when the polygon
`comes to be rendered, it must be
`drawn using horizontal strips that
`are drawn between integer
`coordinates.
`
`The way to handle this is calculate
`the X intersection of the line with
`
`~
`
`http://freespacevirgin.net/hugo.elias/graphics/x__polysc.htm
`
`-
`
`7/26/OS
`
`0112
`
`

`
`-Polygon Scan Converting
`
`page 4 of 5
`
`the X coordinate of the nearest pixel inside the polygon.
`
`horizontal scanlines. Then, save
`
`Firstly some variables we'll need.
`
`Nonintegers:
`
`gradient
`ex, ey
`x1, yl, x2, y2
`Ax, Ay, Bx, By
`
`Integers:
`
`height
`
`the function inti) returns the integer part of a number. i.e. int(5.7) = 5
`
`OK, so lets break down the steps:
`
`1. Calculate the gradient of the line:
`
`dx = x2 - x1 .
`
`dy — y2 - yl
`gradient = dx/dy
`
`2. Calculate ey:
`
`ey = int(y1+1)
`
`— yl
`
`3. Calculate ex:
`
`ex = gradient*ey
`
`4. Calculate coordinates of A:
`
`Ax
`Ay
`
`‘x1 + ex
`Lnt(y1+1)
`
`5. Calculate y coordinate‘ of B:
`
`By = int(y2)
`
`You will notice that there is a divide in the calculation. Risk of a. divide by zero. If dy is equal to zero,
`then you can simply ignore the entire line.
`
`Right, now you have calculated all those things, the line can be scan convened. This scan converting
`process is actually faster than the one used for integer polygons (if you're using fixed point maths,
`otherwise it's slower). There are no [F's and IUMP's involved. The loop can be unrolled nicely to
`process at increadibie speed.
`
`So the inner loop looks something like this:
`
`= Ax
`
`loop y from Ay to By.
`Yfiufferlyl = x
`
`http:I/freespacevirginnetfhugo.elias/g1'aphicsfx_polysc.htm
`
`0113
`
`

`
`-?olygon Scan Converting
`
`-
`
`page 5 of 5 _
`
`x=x+gradient
`end of loop
`
`Again, you will have to handle Left hand lines and Right hand lines differently. The case given here is
`for a Left hand line. I will leave it up to you to work out how to handle the other side.
`
`Scan converting in Assembler
`
`Here is an example of a scan converter I wrote in Assembler. It works on 32-bit Fixed Point numbers
`only.
`
`It takes as arguments; The initial at value (X), The gradient (DeltaX), the number of scan lines to
`calculate (length), and a pointer to the first element in the Y Buffer.
`
`3 YBuffer[y|.= x
`: x
`x + Deltax
`: y
`y + 1
`
`;end of loop
`
`x D
`
`eltax
`
`length
`pointer to YBuffer[Y]
`
`EEK
`EBX
`ECX
`EDI
`
`top:
`
`add
`add
`dec
`
`jnz
`
`[edi], eax
`eax, ebx
`edi,
`4
`ecx
`
`top:
`
`This can be unrolled and can celculate polygon edges very fast indeed. This version has been unrolled
`four times
`-
`
`'x
`EA3
`EBX Deltax
`
`ECX
`EDI
`
`length
`pointer to YBuffer[Y]
`
`shr
`jnc
`
`ecx
`Nosingle
`
`mov
`cmp
`je
`add
`add
`Nosingle:
`shr
`
`jnc
`
`mov
`add
`mov
`add
`
`cmp
`je
`add
`Nonouble:
`top:
`
`[edi], eax
`ecx, D
`NoMore
`eax, ebx
`edi.
`4
`
`ecx
`
`Nosingle
`
`[edi], eax
`eax, ebx
`[edi+4], eax
`eax, ebx
`
`D
`ecx,
`Nomore
`edi,
`8
`
`' halve the number of loops
`if there are an even number of lines to do
`then don't do this odd one
`
`' YBuffer[y] = x
`are there any more left?
`' if not,
`then exit
`' x
`x + 1
`y
`y + 1
`‘
`halve the number of loops again
`if the number of lines is a multiple or 4
`then don't do these add two
`
`-u.a.‘IIIn-.w.in.
`
`YBuffer[y] = x
`3 = x + Deltax
`
`YBuffer[y+1] = x
`x = X + Deltax
`
`' are there any more left?
`' if not,
`then exit
`' y = y + 2
`
`http://freespacevirginnetlhugo.eliasfgraphics/x_po]ysc.ht1n
`
`0114
`
`

`
`-_Polyg0n Scan Converting
`
`mov
`add
`
`add
`
`add
`mov
`add
`add.
`
`clec
`jnz
`
`[edi], eax
`eax, ebx
`[edi+4], eax
`eax, ebx
`[edi+8], eax
`eax, ebx
`{edi+l2], eax
`eax, ebx
`edi, 16
`
`ecx
`top
`
`.
`
`'
`
`: YBuffer[y] = X
`: x = X + Deltax
`; YBuffer[y+1] = x
`; 3 = x + Deltax
`; YBuffer[y+2] = 1:
`; K = x + Deltax
`; YBuffer[y+3] = x
`: x
`x + Deltax
`r’ Y
`Y -l-
`£1
`
`:
`;.end of loop
`
`So, after all the edges of the polygon have been scan converted, you have an array of pairs of X
`coordinates where the edges cross horizontal scanlines. Assuming you are going to fill the area with a
`solid colour, you should loop down the height of the polygon, drawing horizontal strips from one side to
`the other. Remember that you only want to draw pixels that lie inside the polygon. So draw from the
`first pixel to the right of the left edge, to the first pixel to the left of the right edge. geddit?
`
`Take a look at the polygon
`again, this time filled. The
`centres of the filled pixels all
`' lie within the polygon. The X
`coordinates stored in the
`Y'Buffer would be:
`
`You will notice that on the last
`
`line, 6, X1 is larger then X2.
`This is because the polygon
`crosses the line, but pokes
`between pixels. This strip does
`not get drawn.
`
`-
`I hope I have convinced you
`to only ever write perfect scan converters from now on. There shouldn't really be any excuse for using
`tacky integer polys any more. Computers are quite fast enough to cope with the tiny extra computing
`overhead involved, and you as a programmer, I have no doubt, are more then capable of writing the
`code.
`'
`
`http://freespacevirginnetfhugo.eliasfgraphicslx_polysc.htm
`
`0115
`
`

`
`This Page is Inserted by IFW Indexing and Scanning
`Operations and is not part of the Official Record
`
`BEST AVAILABLE IMAGES
`
`Defective images within this document are accurate representations.ofthe original
`documents submitted by the applicant.
`‘
`
`Defects in the images include but are not limited to the items checked:
`
`Cl BLACK BORDERS
`
`CI IMAGE CUT OFF AT TOP, BOTTOM OR SIDES
`
`El FADED TEXT OR DRAWING
`
`D RLURRED OR ILLEGIBLE TEXT OR DRAWING
`
`El s
`
`DISLANTED IMAGES
`
`COLOR OR BLACK AND WHITE PHOTOGRAPHS
`
`El GRAY SCALE DOCUMENTS
`
`El LINES OR MARKS ON ORIGINAL DOCUMENT
`
`El REFERENCE(S) OR EXH]Bl'l‘(S) SUBMITTED ARE POOR QUALITY
`
`El OTHER:
`
`IMAGES ARE BEST AVAILABLE COPY.
`
`As rescanning these documents will not correct the image
`problems checked, please do not report these problems to
`the IFW Image Problem Mailbox.
`
`0116
`
`

`
`PTDBBI22 (12-D4)
`Approved for use through orrs-uzoos. ours 0551-0031
`u.s. Patent and Trademark orrloe; u.s. DEPARMENT or commence
`
`r the papenvortt Reduction Act oi 1995, no persons are required to respond to a collection ofintorrnation unless it disptays a valid OMB control number.
`- , :5 mow FOR EXTENSION or TIME UNDER 37 can 1.136(a)
`D°ckelNurr1ber(0l=ti0rIa|)
`FY 2005
`00100.02.0053
`Fees ursuanr lothe Consolidated - 3 trons Act. 1005 H.R. 1818.
`
`Application Number 101459.797
`
`Filed
`
`June 12. 2003
`
`For DIVIDING WORK AMONG MULTIPLE GRAPHICS PIPELINES USING A SUPER-TILING TECHNIQUE
`
`Art Unit 2676
`
`Examiner Joni Hsu
`
`This is a request under the provisions of 37 CFR 1.136(3) to extend the period for filing a reply in the above identified
`application.
`-
`
`The requested extension and fee are as lollows (check time period desired and enter the appropriate fee below):
`
`One month (37 CFR 1.17(a)(1)t
`
`Two months (37 CFR 1.17(a)(2))
`
`Three months (37 CFR 1.17(a){3))
`
`Four months (37 CFR 1.17(a)(4))
`
`Five months (37 CFR 1.17(a)(5))
`
`Ee_e_
`
`$120
`
`$450
`
`Small Entity Fee
`
`$60
`
`$225
`
`$510
`
`$795
`
`$1060
`
`$
`
`is 450-00
`
`35
`
`3
`
`s
`
`D Applicant claims small entity status. See 37 CFR 1.27.
`
`E] A check in the amount of the fee is enclosed.
`
`[3 Payment by credit card. Form PTO-2038 is attached.
`
`E] The Director has already been authorized to charge fees in this application to a Deposit Account.
`
`'2 The Director is hereby authorized to charge any fees which may be required. or credit any overpayment, to
`Deposit Account Number
`22-0259
`.
`I have enclosed a duplicate copy of this sheet.
`WARNING: Information on this form may become public. Credit card information should not be included on this form.
`Provide credit card infonnalion and authorization on PTO-2033.
`
`J
`
`01/092006 SHRSSEIII 00000034 220359
`
`1045979?
`
`lam the El applicanvinventor.
`.
`01;;-51353
`C] assignee of record ofthe entire interest. See 37 CPR 3.71.
`Statement under 37 CFR 3.73(b) is enclosed (Form PTOISBIQG).
`attorney or agent of record. Registration Number 34-414
`El attorney or agent under 37 CFR 1.34.
`Registration number if acting under 3? CFR 1334
`
`550,90 M
`
`% E
`
`rgnature
`
`;
`
`Christopher J. Fleckamp
`Typed or printed name
`
`:
`
`'
`
`T
`
`January 3. 2006
`
`Date
`
`312-609-7599
`Telephone Number
`
`NOTE: signatures of all the inventors or essignees oi record of the entire interest or their representetivetst are required. Submit multiple forms if more than one
`signature is required. see below.
`
`forms are submitted.
`1
`Total of
`This collection ol information is required by 37 CFR 1.13Ei(e). The information is required to obtain or retain a benefit by the public which is to file (and by the
`USPTO to process) an appiicalion. confidentiality is governed by 35 U.S.C. 122 and 37 CFR 1.11 and 1.14. This collection is estimated to take 5 minutes to
`complete. including gathering. preparing. and submitting the completed application form to the USPTO. Time will vary depending upon the individual case. Any
`comments on the amount at time you require to complete this form enolor suggestions for reducing this burden. should be sent to the chin! Information Dlficor.
`U.S. Patent and Trademark Oflioe. US. Department of Commence. P.O. Box 1450. Alexandria. VA 22313-1450. DO NOT SEND FEES OR COMPLETED
`FORMS To THIS ADDRESS. SEND TO: commissioner for Patents. r.o. Box 1450, Alexandria, VA 22313-1450.
`lfyou need assistance in completing the ibrrn, call 1-E00-PTO-9199 and select option 2.
`
`0117
`
`

`
`REMARKS
`
`Applicants respectfully traverse and request reconsideration.
`
`Applicants with to thank the Examiner for the notice that claim 19 would be allowable if
`
`rewritten in independent form.
`
`Claims 1-4, 6-8, 9, 10, 12, 14, 17, 18. 20-23, 25 and 26 stand rejected under 35 U.S.C.
`
`§102(b) as being anticipated by U.S. Patent No. 5,745,118 (Alcom). The independent claims
`
`have been amended to include inherent language indicating that
`
`the tiles described in the
`
`specification and claimed correspond to screen locations and may have corresponding frame
`
`buffer memory locations as well. Alcom is directed to different structure and operations from
`
`that claimed and instead is directed to texture space source data. Alcom describes a 3D bypass
`
`structure for the download of textures and describes a system that receives primitive information
`
`from a host processor and passes it through a distributor 30 which then distributes 3D primitive
`
`data evenly among the 3D geometry accelerator chips.
`
`In this way, for example, three groups of
`
`primitives are operated upon simultaneously. The multiple 3D geometry accelerator chips
`
`determine object red, green and blue values and texture values for the screen space coordinates
`
`and they also perform view clipping operations. The output from these multiple 3D geometry
`
`accelerator chips are then passed to a concentrator chip 36 which combines the 3D primitive
`
`output data received from the 3D geometry accelerator chips and reorders the primitives to the
`
`original order that they had prior to being distributed by the distributor chip 30.
`
`(See for
`
`example, column 6, line 42 through column 7, line 10). As such, distribution of primitive data is
`
`done merely in a round robin type approach wherein each graphics accelerator chip receives an
`
`even distribution of primitives. The texture mapping board 12 then receives the primitives in the
`
`same order that the distributor receives them in and then processes them in that order.
`
`CHICAGOM1435290. I
`
`0118
`
`

`
`In contrast, Applicants’ claims are directed to a different operation - render space
`
`destination data. There is no teaching or suggestion in Alcom of at least two graphics pipelines
`
`that process data in a corresponding set of tiles of a repeating tile pattern corresponding to screen
`
`locations, wherein the repeating tile pattern includes a horizontally and vertically repeating
`
`pattern of square regions.
`
`It appears that the Alcorn reference actually teaches a type of round robin or sequential
`
`load balancing for texture source data in a front end.
`
`In contrast, Applicants describe, for
`
`example, a multi-pipeline system that performs pixel operations on pixels within a determined
`
`set of tiles by a corresponding one of a plurality of graphics pipelines based on a set of tiles of a
`
`repeating tile pattern corresponding to screen locations.
`
`In one embodiment, a scan converter
`
`determines, for example, whether pixels within portions of an object, such as a triangle, intersect
`
`with tiles that backend circuitry is responsible for processing. No tile based load distribution
`
`appears to be taught or suggested in the cited reference. Accordingly, the claims are believed to
`
`be in condition for allowance.
`
`For example, the office action cites Alcom, column 6, lines 40-43 as allegedly teaching a
`
`plurality of graphics pipelines. This portion refers to the multiple accelerator chips 32a-32c, for
`
`example. The office action then cites to column 11, lines 8-31 as teaching the processing of
`
`corresponding sets of tiles. However, this cited portion actually refers to the texture mapping
`
`board which is not part of the graphics accelerator chips.
`
`In fact, the graphics pipelines (i.e. the
`
`graphics accelerator chips) merely process data in a round robin fashion and do not process data
`
`based on tiles of a repeating tile pattern. Accordingly, the independent claims are in condition
`
`for allowance.
`
`The office action also cites to Alcom at column 15, lines 44-57. However again, this
`
`portion refers to the texture mapping board 12 which again processes data in the order in which
`
`CHICAGO.ml43S290.l
`
`10
`
`0119
`
`

`
`the distributor 30 received them. The portion referred to in the office action actually refers to the
`
`storage of texels in a MIP map so that the tiler 72 in the texture mapping board can access texels
`
`in the texel cache access 82. There is no teaching or suggestion that any texture tiles correspond
`
`to screen locations nor a plurality of pipelines that process data in a corresponding set of tiles of
`
`a repeating tile pattern corresponding to screen locations wherein the pattern includes a
`
`horizontally and vertically repeating pattern of the square regions. Accordingly, claims 1, 20, 24
`
`and 25 are in condition for allowance.
`
`The dependent claims add additional novel and non-obvious subject matter.
`
`For
`
`example, claim 3 requires that the square regions are 2-dimensional partition of memory in a
`
`frame buffer. However, the cited portion of Alcom actually i