U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________________________________
`
`
`
`APPLE INC.,
`Petitioner
`
`v.
`
`OpenTV, Inc.,
`Patent Owner.
`
`Case No. ______
`
`
`
`
`
`PETITION FOR INTER PARTES REVIEW
`OF U.S. PATENT NO. 5,566,287 CHALLENGING CLAIMS 1, 5, 7, and 16
`UNDER 35 U.S.C. § 312, 37 C.F.R. § 42.104
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`
`TABLE OF CONTENTS
`
`
`
`
`I.
`INTRODUCTION ......................................................................................................... 1
`II. GROUNDS FOR STANDING AND FEE AUTHORIZATION ....................... 1
`III. MANDATORY NOTICES (37 C.F.R. § 42.8) ......................................................... 2
`IV. SUMMARY OF CHALLENGES ............................................................................... 3
`V. THE CHALLENGED PATENT ................................................................................ 3
`A. Overview Of The ’287 Patent ................................................................................... 3
`B. Level Of Ordinary Skill In The Art ........................................................................ 11
`C.
`Summary Of The Prosecution History Of The ’287 Patent .............................. 11
`D. Claim Construction ................................................................................................... 13
`1.
`“drawing request” (claim 1) ................................................................................. 14
`2.
`“image update request” (claim 1) ........................................................................ 16
`3.
`“a new entry representing the drawing area” (claim 1) .................................... 17
`4.
`“requesting that respective graphic objects be redrawn if any portion of the
`graphic object lies within the drawing area represented by the retrieved entry”
`(claim 1) ........................................................................................................................... 18
`5.
`“request to draw a graphic object” (claim 5) ..................................................... 21
`6.
`“request to move a graphic object” (claim 7).................................................... 21
`7.
`“step of receiving a screen update request comprises the step of receiving a
`request for update the complete image” (claim 16) .................................................. 22
`VI. SPECIFIC GROUNDS OF INVALIDITY ........................................................... 24
`A. Claims 1, 5, 7, And 16 Are Anticipated By Kosbie Or By Garnet Source Code
`
`24
`B. Claims 1, 5, 7, And 16 Are Rendered Obvious By Either Of Kosbie Or
`Garnet Source Code In Combination With Either Of Garnet Manual Or Garnet
`IEEE ..................................................................................................................................... 25
`C. Claims 1, 5, 7, And 16 Are Anticipated By The InterViews Publications
`(Vlissides, IV Source Code, and Linton) ......................................................................... 41
`D. Claims 1, 5, 7, And 16 Are Rendered Obvious By Any Of The InterViews
`Publications .......................................................................................................................... 56
`
`i
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`E. The Combination Of The Garnet Publications And The InterViews
`Publications Renders Obvious Claims 1, 5, 7, And 16. ................................................ 56
`1.
`“determining a drawing area” and “inserting a new entry representing an
`area into a list” (claim 1) ................................................................................................ 57
`2.
`“requesting that respective graphics objects be redrawn if any portion of the
`graphic object lies within the drawing area represented by the retrieved entry”
`(claim 1) ........................................................................................................................... 59
`CONCLUSION ........................................................................................................ 60
`
`VII.
`
`
`ii
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`
`
`
`LIST OF EXHIBITS
`
`
`Apple 1001 -- U.S. Patent No. 5,566,287 (“the ’287 Patent”)
`
`Apple 1002 -- Prosecution File History for Application No. 08/267,084, which later
`
`issued as U.S. Patent No. 5,566,287 (“’287 File History”)
`
`Apple 1003 -- David S. Kosbie, Brad Vander Zanden, Brad A. Myers, and Dario
`
`Giuse, “Automatic Graphical Output Management,” The Garnet
`
`Compendium: Collected Papers 1989-1990, ed. Brad A. Myers, Carnegie
`
`Mellon University, CMU-CS-90-154 (August 1990) (“Kosbie”)
`
`Apple 1004 -- Brad A. Myers, et al. “The Garnet Toolkit Reference Manuals: Support
`
`for Highly-Interactive, Graphical User Interfaces in Lisp,” Carnegie Mellon
`
`University, CMU-CS-89-196 (November 1989) (“Garnet Manual”)
`
`Apple 1005 -- Brad A. Myers, et al., “Comprehensive Support for Graphical, Highly
`
`Interactive User Interfaces,” IEEE Computer, vol. 23, no. 11, (Nov. 1990)
`
`(“Garnet IEEE”)
`
`Apple 1006 -- Garnet Source Code, available for download from the School of
`
`Computer Science, Carnegie Mellon University at least as early as 1991
`
`(excerpts) (“Garnet Source Code”)
`
`Apple 1007 -- Vlissides & Linton “Applying Object-Oriented Design to Structured
`
`Graphics,” 1988 USENIX C++ Conference (“Vlissides”)
`
`iii
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`Apple 1008 -- InterViews Source Code Version 3.1 (1992) (excerpts) (“IV Source
`
`Code”)
`
`
`
`Apple 1009 -- Vlissides & Linton, “Unidraw: A Framework for Building Domain-
`
`Specific Graphical Editors,” ACM Transactions on Information Systems, Vol
`
`8, No. 3, July 1990, pp 237-68 (“Linton”)
`
`
`
`Apple 1010 -- Declaration of Dr. Brad A. Myers
`
`Apple 1011 -- Curriculum Vitae of Dr. Brad A. Myers
`
`Apple 1012 -- Declaration of Dr. Mark A. Linton
`
`Apple 1013 -- Curriculum Vitae of Dr. Mark A. Linton
`
`
`
`iv
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`
`I.
`
`INTRODUCTION
`Pursuant to 37 C.F.R. § 42.100, et seq., Apple Inc. (“Petitioner”) hereby
`
`petitions the United States Patent and Trademark Office (the “Office”) to institute an
`
`inter partes review of claims 1, 5, 7, and 16 of U.S. Patent No. 5,566,287 (“the ’287
`
`Patent”). The ’287 Patent, a copy of which is provided as Apple 1001, is assigned to
`
`OpenTV, Inc. (“Patent Owner”). The ’287 Patent claims a method of asynchronously
`
`managing graphics on a display device by allowing an application to modify graphical
`
`attributes of objects and then initiate a screen refresh at a later time, rather than
`
`having the display manager immediately redraw the screen after any graphical attribute
`
`change. See Apple 1001 at 1:43-53. Such methods were well known in the art by the
`
`time the ’287 Patent was filed. The claimed invention is anticipated or rendered
`
`obvious by several prior art references discussed in detail below. This petition
`
`presents several non-cumulative grounds of rejection based on prior art that was not
`
`considered by the Office during prosecution. These grounds of rejection are each
`
`reasonably likely to prevail, and this petition, accordingly, should be granted on all
`
`grounds.
`
`II. GROUNDS FOR STANDING AND FEE AUTHORIZATION
`Pursuant to 37 C.F.R. § 42.104(a), Petitioner certifies that the ’287 Patent is
`
`available for inter partes review and that Petitioner is not barred or estopped from
`
`requesting inter partes review on the grounds identified herein. This petition is timely
`
`1
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`filed under 37 C.F.R. § 42.102(a)(2) because the ’287 Patent is not a patent described
`
`in section 3(n)(1) of the Leahy-Smith America Invents Act.
`
`Pursuant to 37 C.F.R. § 42.103(a), the Office is authorized to charge $23,000 to
`
`Deposit Account No. 50-0639 for the fee set forth in 37 C.F.R. § 42.15(a), and any
`
`additional fees that might be due in connection with the Petition.
`
`III. MANDATORY NOTICES (37 C.F.R. § 42.8)
`Real Party-In-Interest: The real party-in-interest is Apple Inc.
`
`Notice of Related Matters: OpenTV, Inc. has asserted this patent against Apple
`
`Inc. in Case No. 3:14-cv-01622-HSG, which was filed on April 9, 2014 and is
`
`currently pending in the District Court for the Northern District of California.
`
`Petitioner’s Lead and Back-up Counsel:
`
`Lead Counsel: Mark E. Miller (Reg. No. 31401), O’Melveny & Myers LLP,
`
`Two Embarcadero Center, 28th Floor, San Francisco, CA 94111. (Telephone: 415-
`
`984-8700; Fax: 415-984-8701; Email: markmiller@omm.com.)
`
`Backup Counsel: Brian M. Cook (Reg. No. 59356), Xin-Yi Zhou (Reg. No.
`
`63366), John Kevin Murray (Reg. No. 69,529), Anne E. Huffsmith (Reg. No. 57,041),
`
`and Ryan K. Yagura (Reg. No. 47,191), O’Melveny & Myers LLP, 400 S. Hope Street,
`
`Los Angeles, CA 90071. (Telephone: 213-430-6000; Fax: 213-430-6407; Emails:
`
`bcook@omm.com, vzhou@omm.com, kmurray2@omm.com,
`
`ahuffsmith@omm.com, and ryagura@omm.com).
`
`2
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`Service Information: Service of all documents may be made to the lead counsel and
`
`backup counsel at O’Melveny & Myers LLP, Two Embarcadero Ctr. 28th Floor, San
`
`Francisco, CA 94111-3823, with courtesy copies to the following email addresses:
`
`markmiller@omm.com, bcook@omm.com, vzhou@omm.com,
`
`kmurray2@omm.com, ahuffsmith@omm.com, and ryagura@omm.com. Petitioner’s
`
`counsel may also be reached by telephone at 415-984-8700 and by facsimile at 415-
`
`984-8701.
`
`IV. SUMMARY OF CHALLENGES
`Petitioner challenges the patentability of claims 1, 5, 7, and 16 on the following
`
`grounds, which are described in detail in Section VI, below.
`
`1. Printed publications and published source code describing the Garnet
`
`software package anticipate or render obvious claims 1, 5, 7, and 16.
`
`2. Printed publications and published source code describing the
`
`InterViews software package anticipate or render obvious claims 1, 5, 7,
`
`and 16.
`
`3. The combination of the Garnet publications and the InterViews
`
`publications renders obvious claims 1, 5, 7, and 16.
`
`V. THE CHALLENGED PATENT
`A. Overview Of The ’287 Patent
`The ’287 Patent was filed on June 28, 1994 and makes no claim of priority to
`
`any other application. Apple 1001 at cover. It is directed to a method of
`
`3
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`asynchronously maintaining graphical objects on a display. In particular, the ’287
`
`Patent purports to describe an improved method of refreshing a screen display
`
`according to which objects are not automatically redrawn as soon as an application
`
`changes their attributes. Rather, according to the described method, objects are
`
`redrawn at a later time as determined by the application, taking into consideration the
`
`other activities the application may have to perform. For example, the ’287 Patent
`
`states:
`
`It is well known that in graphical-based processor systems, the
`processor spends the majority of its processing time performing
`graphical functions, e.g. drawing or redrawing graphic objects on
`the display screen, and that it is important to optimize the screen
`drawing speed. In order to maximize graphical response times,
`current object-oriented graphical-based processor systems
`automatically invoke the display manager to redraw the
`screen immediately after any change in an attribute of a
`graphical object. The inventor has realized, however, that at any
`given time in the execution of an interactive program, other
`processing functions may be more important in increasing the
`perceived response speed than the screen drawing function, e.g.
`responding to user inputs, or data received from mass storage
`device or a remote transmission location.
`Apple 1001 at 1:39-53. The alleged invention is to give the application program
`
`control over when the screen should be updated:
`
`4
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`In short, by making screen updates asynchronous from graphic
`object attribute changes, and by placing the screen updates under
`the control of the application program, and by giving the
`application program the option of updating only a portion of the
`screen, or the complete screen, an application programmer may
`write the application program to optimize the perceived response
`of the application program.
`Id. at 9:47-53.
`
`The ’287 Patent describes the interaction of an application program and the
`
`User Interface Management System (UIMS) (display manager) which is the operating-
`
`system function that actually controls the display screen of a device. Id. at 2:48-53.
`
`Figure 1, which describes the operation of “the present invention,” (id. at 2:26-28, 41-
`
`43) shows how the application program (APPLN PROG) interacts with the UIMS:
`
`5
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`
`
`
`
`
`Figure 1 is divided into three columns. The left column (“APPLN PROG”)
`
`illustrates actions taken by the application program. The middle column (“UIMS”)
`
`illustrates actions taken by the user interface management system (display manager),
`
`and the right column (“DATA”) illustrates data maintained with respect to the
`
`graphical objects displayed on the screen. Apple 1001 at Fig. 1. Following the flow
`
`6
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`through the diagram from top to bottom describes how the application program may
`
`change an attribute of a graphical object it is responsible for: “In Fig. 1, the
`
`application program, APPLN PROG, in the course of its programming, changes the
`
`attribute of a graphic object in block 302.” Id. at 3:19-21. At this stage, the display is
`
`not immediately updated, but the UIMS is informed of the attribute change (see arrow
`
`from block 302 to block 342). The UIMS then determines an area affected by the
`
`change (342), adds data representing the affected area to a list (344), optionally
`
`performs optimizations (345), and returns control back to the application program
`
`(see arrow from box 344 or box 345 to box 302). The application program then
`
`proceeds with whatever additional processing it might need to perform and then later
`
`initiates a redraw of portions of the screen by issuing an “update request” (box 304)
`
`to the UIMS (see arrow from box 304 to box 346). The ’287 Patent describes this
`
`process as follows:
`
`Referring again to FIG. 1, after control is returned to the
`application program from the UIMS subroutine in block 302,
`further processing by the application program (which need not be
`related to the attribute change of the graphic object) is performed,
`illustrated in FIG. 1 by a zig-zag line descending from block 302.
`At a later time, in block 304, the application program makes a
`system call to a UIMS subroutine, defined in the API, which will
`update the screen.
`Id. at 5:20-27.
`
`7
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`When the application issues the update request (block 304), a region to be
`
`redrawn is determined by extracting data representing an affected area from the list
`
`(362), and the system instructs the graphical objects displayed on the screen to
`
`execute a REDRAW method:
`
`The REDRAW method first determines if any portion of the
`graphic object lies within the boundary box. If so, then that
`graphic object calls low-level graphic display routines which will
`redraw that graphic object. Otherwise, nothing is done. When each
`currently displayed graphic object has executed its REDRAW
`method, the retrieved drawing area will have been completely
`redrawn.
`Apple 1001 at 5:40-47. In other words, graphic objects that do not overlap the
`
`retrieved area are not redrawn, but any object having any portion that does overlap
`
`the retrieved area is redrawn by calling low-level graphics display routines. Id. at 7:44-
`
`46 (“The lower right-hand corner of the surrounding box object 31 lies within the
`
`boundary box, so it is redrawn (i.e., low level graphic routines are called).”) Low-level
`
`graphics routines are those routines that draw lines, shapes, etc. to the screen:
`
`to draw a text object, low level graphic routines are called which
`will draw the image of the characters in the string attribute at the
`position specified in the position attribute having the size specified
`in the size attribute. Other attributes which may be present in the
`text object are font, text attributes (bold, italic etc.) text color,
`background color, etc. All other graphic objects are similarly drawn
`according to their attributes.
`
`8
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`Id. at 6:31-37. Claim 1, the only challenged independent claim, reads as follows:
`
`1. In a processing system executing an application program
`displaying a plurality of graphic objects, a method for
`asynchronously maintaining an image on a display device,
`comprising the steps of:
`receiving a drawing request from the application program;
`determining a drawing area of the image in response to the received
`drawing request;
`inserting a new entry representing the drawing area into a list of a
`plurality of entries each representing respective drawing areas;
`receiving an image update request from the application program;
`retrieving one of the plurality of entries representing drawing areas
`from the list; and
`requesting that respective graphic objects be redrawn if any portion
`of the graphic object lies within the drawing area represented by
`the retrieved entry.
`Id. at claim 1. Some the terms used in claim 1 are not described or even mentioned in
`
`the specification and may not meet the requirements of 35 U.S.C. § 112. Because
`
`such grounds for invalidity cannot be presented here, Petitioner presents, for the
`
`purposes of this Petition only, the best constructions of these terms, to the extent
`
`they are found to be supported by the specification. These terms are discussed in
`
`detail in the section on Claim Construction, infra, and are summarized here. The term
`
`“drawing request,” for example, is used only in the claims and in a summary that
`
`9
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`essentially just repeats the claim language. Id. at 2:13-24; Abstract. Likewise, the
`
`specification never uses the term “image update request.”
`
`Dependent claim 5 recites specific steps to “draw a graphic object.”
`
`5. The method of claim 1 wherein:
`the step of receiving a drawing request comprises the step of
`receiving a request to draw a graphic object on the image; and
`the step of determining a drawing area comprises the step of
`determining the position and size of a rectangle which will
`encompass an area of the image at which the graphic object will be
`drawn.
`Id. at claim 5. Claim 7 recites steps to “move a graphic object.”
`
`7. The method of claim 1 wherein:
`the step of receiving a drawing request comprises the step of
`receiving a request to move a graphic object on the image; and
`the step of determining a drawing area comprises the steps of:
`determining the position and size of a first rectangle which will
`encompass an area of the image at which the graphic object was
`originally displayed; and
`determining the position and size of a second rectangle which will
`encompass an area of the image at which the graphic object will be
`displayed.
`Id. at claim 7. Claim 16 recites steps to “update the complete image.”
`
`16. The method of claim 1 wherein:
`the step of receiving a screen update request comprises the step of
`receiving a request for update the complete image; and
`
`10
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`the method further comprises the step of repeating the retrieving
`and requesting steps in response to the received complete image
`update request.
`Id. at claim 16.
`
`Systems for performing the claimed steps for maintaining graphical objects on
`
`a display device were well known in the art by June 28, 1994, as described in detail
`
`below. Multiple references described below, which were not before the Office during
`
`prosecution, anticipate or render obvious ’287 Patent claims 1, 5, 7, and 16.
`
`Level Of Ordinary Skill In The Art
`
`B.
`The level of ordinary skill in the art is evidenced by the references cited in
`
`Section VI below. More specifically, one of ordinary skill in the art would be
`
`someone with a bachelor’s degree or higher in computer science, computer
`
`engineering, electrical engineering or the equivalent, plus two or more years of
`
`experience in the field of software engineering, graphical user interface programming,
`
`computer graphics and display programming, or similar field. Apple 1010 ¶ 49. A
`
`hypothetical “person having ordinary skill in the art” shall be referred to herein as a
`
`“PHOSITA.”
`
`Summary Of The Prosecution History Of The ’287 Patent
`
`C.
`None of the references relied upon in this petition was before the Office
`
`during prosecution of Application No. 08/267,084 (“the ’084 Application”), which
`
`later issued as the ’287 Patent. The ’084 Application was filed on June 28, 1994 with
`
`16 claims, one of which was independent. Apple 1002.025-29.
`
`11
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`On February 6, 1996, the Examiner rejected all claims under 35 U.S.C. § 112 as
`
`indefinite, finding the term “a drawing area” to be unclear. The Examiner also
`
`rejected the claims under 35 U.S.C. § 103 as obvious over the combination of Ogawa
`
`(U.S. 5,438,661) and Stanton (5,430,870). Id. at 1002.069-70. Specifically, the
`
`Examiner found that Ogawa disclosed all elements of the claims except it did not
`
`explicitly teach the claimed “a drawing area,” instead operating on “windows.” The
`
`Examiner found this use of “drawing areas” to be well-know, as shown by Stanton,
`
`and an obvious modification of Ogawa. Id.
`
`In response to the rejection, the Applicant amended claim 1, among others, to
`
`address the §112 objection and more clearly recite the relationship between the
`
`claimed “drawing area” and the “list”:
`
`l. (Amended) In a processing system executing an application
`program displaying a plurality of graphic objects, a method for
`asynchronously maintaining an image on a display device,
`comprising the steps of:
`receiving a drawing request from the application program;
`determining a drawing area of the image in response to the received
`drawing request;
`inserting a new entry representing the drawing area into a list of a
`plurality of entries each representing respective drawing areas;
`receiving an image update request from the application program;
`retrieving a one of the plurality of entries representing drawing area
`areas from the list; and
`
`12
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`requesting that respective graphic objects be redrawn if any portion
`of the graphic object lies within the retrieved drawing area
`represented by the retrieved entry.
`Apple 1002.076-77. Responding to the prior art rejection, the Applicant characterized
`
`the claimed invention as follows:
`
`The invention recited in claim 1 relates to a display manager in a
`processing system. Such a display manager controls the drawing of
`graphic objects on a display screen in response to requests from an
`application program.
`Id. at 1002.82. The Applicant argued that, while the prior art disclosed the equivalent
`
`of the application program (APPLN PROG) “requesting a change of a graphic
`
`attribute, e.g., adding a circle, triangle and square,” it did not disclose the operation of
`
`the display manager manipulating the display. Id. The Applicant also argued that the
`
`prior art did not disclose adding entries to a drawing list or requesting that graphics
`
`objects be redrawn if any portion lies within the drawing area to be updated. Id. at
`
`1002.83-84.
`
`Following the Applicant’s submission, the Examiner issued a Notice of
`
`Allowance on May 30, 1996. Id. at 1002.89.
`
`D. Claim Construction
`The ’287 Patent expired on June 28, 2014. In the context of an inter partes
`
`review, a claim in an expired patent is construed in accordance with Phillips v. AWH
`
`Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc). Chimei Innolux Corp. v. Semiconductor
`
`13
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`Energy Laboratory Co., No. IPR2013-00065, Paper No. 11 at p. 10 (P.T.A.B. April 30,
`
`2013). For terms not specifically listed and construed below, Petitioner interprets
`
`them for purposes of this review in accordance with their plain and ordinary meaning.
`
`“drawing request” (claim 1)
`
`1.
`The term “drawing request” should be construed as “notification that an
`
`attribute of a graphical object has changed.” Apple 1010 ¶¶ 23-30.
`
`The ’287 Patent uses the term “drawing request” only in a summary that
`
`essentially just repeats the claim language. Apple 1001 at 2:13-24; Abstract. While
`
`Petitioner believes this term lacks sufficient written description, Petitioner presents a
`
`construction as the only reasonable interpretation consistent with the specification.
`
`The specification twice characterizes Figure 1 as illustrating “the present invention.”
`
`Id. at 2:26-28; 2:41-43 (“FIG. 1 is a diagram . . . illustrating the operation of a
`
`processing system incorporating the present invention.” (emphasis added)). When a
`
`patent “specification clearly describes a single embodiment as the invention,” the
`
`claims of that patent must be construed to reflect the scope of that “sole embodiment
`
`of the invention.” Lydall Thermal/Acoustical, Inc. v. Fed.-Mogul Corp., 344 F. App’x 607,
`
`614-15 (Fed. Cir. 2009); see also Verizon Servs. Corp. v. Vonage Holdings Corp., 503 F.3d
`
`1295, 1308 (Fed. Cir. 2007) (“When a patent thus describes the features of the
`
`‘present invention’ as a whole, this description limits the scope of the invention.”).
`
`Figure 1 shows that the application program, at box 302, changes a graphic
`
`attribute. This change is then communicated to the display manager, or UIMS, as
`
`14
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`shown by the arrow from box 302 to box 342. Box 342 is labeled “determine drawing
`
`area,” and claim 1 includes the step “determining a drawing area of the image in
`
`response to the received drawing request.” Similarly, the specification describes this
`
`process:
`
`In FIG. 1, the application program, APPLN PROG, in the course
`of its programing, changes the attribute of a graphic object in block
`302. An application program interface (API) is provided to an
`application programmer, in a known manner, to permit a request
`for such an attribute change. More specifically, to change an
`attribute of a graphic object, a system call is made to a subroutine
`defined in the API which will change the attribute of the graphic
`object. The called subroutine is part of the UIMS. In block 342 of
`the UIMS, a drawing area (or areas) which will need to be redrawn
`as a result of the attribute change is determined.
`Apple 1001 at 3:19-30. The only disclosed action that could be considered “receiving
`
`a drawing request from the application program” is an application program changing a
`
`graphical attribute and communicating that change to the display manager. There is
`
`no other disclosure in the specification of a “drawing request,” in response to which a
`
`“drawing area” is determined, as required by claim 1. The term “drawing request”
`
`should be construed as “notification that an attribute of a graphical object has
`
`changed.” Apple 1010 ¶¶ 23-30.
`
`15
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`
`“image update request” (claim 1)
`
`2.
`The phrase “image update request” should be construed as “instruction to
`
`initiate a screen redraw.” Apple 1010 ¶¶ 31-33.
`
`The ’287 Patent uses the phrase “image update request” only in claim 1. The
`
`most reasonable interpretation of the phrase “image update request” is initiating a
`
`screen redraw. One of stated goals of the ’287 Patent is to separate the graphical
`
`attribute update function from the screen redraw function and to give the application
`
`program control over when the screen update is initiated:
`
`In short, by making screen updates asynchronous from graphic
`object attribute changes, and by placing the screen updates under
`the control of the application program, and by giving the
`application program the option of updating only a portion of the
`screen, or the complete screen, an application programmer may
`write the application program to optimize the perceived response
`of the application program.
`Apple 1001 at 9:47-54. Similarly, Figure 1, which is a flow chart showing the
`
`interactions of the application program and the display manager, or UIMS, shows the
`
`application program initiating the screen redraw at block 304 (“issue update request”).
`
`The ’287 Patent describes this process as follows:
`
`Referring again to FIG. 1, after control is returned to the
`application program from the UIMS subroutine in block 302,
`further processing by the application program (which need not be
`related to the attribute change of the graphic object) is performed,
`
`16
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`illustrated in FIG. 1 by a zig-zag line descending from block 302.
`At a later time, in block 304, the application program makes a
`system call to a UIMS subroutine, defined in the API, which
`will update the screen.
`Id. at 5:20-27 (emphasis added). Thus, “image update request” should be construed as
`
`“instruction to initiate a screen redraw.” Apple 1010 ¶¶ 31-33.
`
`“a new entry representing the drawing area” (claim 1)
`
`3.
`The term “a new entry representing the drawing area” should be construed as
`
`“new data identifying an object or region requiring update.” Apple 1010 ¶¶ 34-37.
`
`Claim 1 describes a system in which an application program changes a graphical
`
`attribute, the system then collects those changes in a list, and the list is used to identify
`
`portions of the screen to be redrawn when the application program later executes an
`
`update request. The ’287 Patent describes the creation of the list as follows:
`
`For example, if the color attribute of a circle is changed, then a
`rectangle (or more precisely, a square) encompassing the circle is
`determined. The square outlines the area of the image which needs
`to be redrawn as a result of the attribute change. Data representing
`the position and size of this square is then inserted into a list of
`drawing areas 362 in block 344.
`’287 Patent at 3:33-39. In other words, the “drawing area” is data representing an
`
`object or a portion of an object to be redrawn. During prosecution, the Examiner
`
`found “a drawing area” to be unclear. To overcome this rejection, the Applicant
`
`17
`
`

`
`U.S. Patent No. 5,566,287
`Petition for Inter Partes Review
`amended claim 1 to clarify that what goes into the list is data that “represents” the
`
`area to be redrawn, as shown below:
`
`inserting a new entry representing the drawing area into a list of a
`plurality of entries each representing respective drawing areas;
`receiving an image update request from the application program;
`retrieving a one of the plurality of entries representing drawing area
`areas from the list; and
`requesting that respective graphic objects be redrawn if any portion
`of the graphic object lies within the retrieved drawing area
`represented by the retrieved entry.
`Apple 1002.069. These arguments and amendments demonstrate that an entry
`
`“representing” a “drawing area” is data that identifies an object or region that needs
`
`updating, and that “a new entry representing the drawing area” should be construed as
`
`“new data identifying an object or region requiring update.” Apple 1010 ¶¶ 34-37.
`
`4.
`
`“requesting that respective graphic objects be redrawn if any
`portion of the graphic object lies within the drawing area
`represented by the retrieved entry” (claim 1)
`
`The phrase “requesting that respective graphic objects be redrawn if any
`
`portion of the graphic object lies within the drawing area represented by the retrieved
`
`entry” should be construed as “commanding every object that overlaps the drawing
`
`area represented by the retrieved entry to call low level graphic routines to