IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`In re Patent of: McFarland et al.
`
`U.S. Patent No.: 5,959,633
`Issue Date:
`Sep. 28, 1999
`Appl. Serial No.: 08/726,091
`Filing Date:
`Oct. 4, 1996
`Title: METHOD AND SYSTEM FOR PRODUCING GRAPHICAL IMAGES
`
`Attorney Docket No.: 19473-0309|P1
`
`Mail Stop Patent Board
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`
`P.O. Box 1450
`
`Alexandria, VA 22313-1450
`
`PETITION FOR INTER PARTES REVIEW OF UNITED STATES
`
`PATENT NO. 5 959 633 PURSUANT TO 35 U.S.C.
`
`311-319 37 C.F.R.
`
`42
`
`

`
`TABLE OF CONTENTS
`
`I.
`
`ll.
`
`III.
`
`IV.
`
`INTRODUCTION ....................................................................................................... .. 1
`
`MANDATORY NOTICES UNDER 37 C.F.R § 42.8 .................................................. .. 2
`
`A. Real Parties-In-Interest Under 37 C.F.R. § 42.8(b)(1) ...................................... .. 2
`B. Related Matters Under 37 C.F.R. § 42.8(b)(2) .................................................. .. 2
`C. Lead And Back-Up Counsel Under 37 C.F.R. § 42.8(b)(3) .............................. .. 3
`D. Service Information ........................................................................................... .. 3
`
`PAYMENT OF FEES — 37 C.F.R. §42.103 .............................................................. .. 3
`
`REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104 ........................................ .. 3
`
`A. Grounds for Standing Under 37 C.F.R. § 42.104(a) ........................................ .. 3
`B. Challenge Under 37 C.F.R. § 42.104(b) and Relief Requested ...................... .. 3
`
`V.
`
`SUMMARY OF THE ‘633 PATENT .......................................................................... .. 4
`
`A. Brief Description ................................................................................................ .. 4
`B. Summary of the Original Prosecution ............................................................. .. 6
`
`VI.
`
`Claim Construction under 37 C.F.R. §§ 42.104(b)(3) ............................................ .. 8
`
`VII.
`
`THERE IS A REASONABLE LIKELIHOOD THAT AT LEAST ONE CLAIM
`
`OF THE ‘633 PATENT IS UNPATENTABLE ......................................................... .. 10
`
`A. Ground 1 sets forth a reasonable likelihood to prevail on at least one
`of Claims 1-4, 6, 8-11, 13, and 15 .................................................................... .. 11
`B. Ground 2 sets forth a reasonable likelihood to prevail on at least one
`of Claims 1-4, 6, 8-11, 13, and 15 .................................................................... .. 14
`
`[GROUND 1 CLAIM CHART] — Anticipation of Claims 1-4, 6, 8-11, 13, and
`15 under §102 by Walton ...................................................................................... .. 20
`
`[GROUND 2 CLAIM CHART] — Obviousness of Claim 1-4, 6, 8-11, 13, and
`15 under §103 by Eick in view of Kruglinski ....................................................... .. 39
`
`VIII.
`
`IX.
`
`X.
`
`CONCLUSION ........................................................................................................ .. 60
`
`

`
`EXHIBITS
`
`GOOGLE1001
`
`U.S. Patent No. 5,959,633 to McFarland et al. (“the ’633 patent”)
`
`GOOGLE1002
`
`Prosecution History of the ’633 patent (Serial No. 08/726,091)
`
`GOOGLE1003
`
`Declaration of Dr. Anselmo Lastra
`
`GOOGLE1004
`
`U.S. Patent No. 5,883,639 to Walton et al. (“Walton”)
`
`GOOGLE1005
`
`U.S. Patent No. 5,564,048 to Eick et al. (“Eick”)
`
`GOOGLE1006
`
`Select portions of Inside Visual C++, Second Edition: Version 1.5 by
`
`David J. Kruglinski, September 1, 1994 (“Krug|inski”)
`
`GOOGLE1007
`
`Select portions of The American Heritage Dictionary of the English
`
`Language (3rd ed. 1992)
`
`GOOGLE1008
`
`Micrografx, LLC, v. Google, Inc. and Motorola Mobility, LLC, Civil Ac-
`
`tion No. 3:13—cv—03595—N, Plaintiff Micrografx, LLC’s Preliminary Dis-
`
`closure of Asserted Claims and Infringement Contentions dated Janu-
`
`ary 6, 2014
`
`

`
`I.
`
`INTRODUCTION
`
`Google Inc., Samsung Telecommunications America, LLC, Samsung Electronics
`
`America, Inc., and Samsung Electronics Co., Ltd. (“Petitioners”) petition for Inter Partes Re-
`
`view (“|PR”) under 35 U.S.C. §§ 311-319 and 37 C.F.R. § 42 of claims 1-4, 6, 8-11, 13, and
`
`15 (“the challenged claims”) of U.S. Patent 5,959,633 (“the ’633 patent”). Below, Petitioners
`
`demonstrate there is a reasonable likelihood of prevailing (“RLP”) in their challenge of at
`
`least one claim identified as unpatentable in this Petition.
`
`The ’633 patent discloses a purported improvement to “computer graphics programs
`
`[that] provide tools within a computer program that allow a user to draw and edit a variety of
`
`shapes,” but which were limited to drawing a predetermined set of shapes. GOOGLE1001
`
`at 1:11-22. According to the ’633 patent, that improvement was to “provid[e] a shape library
`
`external to the computer program” in which each shape had “external capabilities” that could
`
`produce “a graphical image of the shape.” Id. at 1:41-50. As a result, according to the ’633
`
`patent, “[n]ew shapes may be easily added without rewriting the underlying computer pro-
`
`gram.” Id. at 1:60-62.
`
`But the claimed invention was not new. To the contrary, the ’633 patent was improv-
`
`idently granted without full consideration to the wide body of applicable prior art. For exam-
`
`ple, U.S. Patent No. 5,883,639 (“Walton”) [GOOGLE1004] discloses the exact limitations
`
`that served as the basis for allowance, namely, “an external shape stored outside the com-
`
`puter program” that includes “external capabilities” capable of “production of a graphical im-
`
`

`
`age of the external shape.” See GOOGLE1002, Amendment filed Jan. 26, 1999, at 12.
`
`Specifically, Walton discloses accessing external shapes in the form of graphics objects,
`
`each object including an external shape (“graphic element’’) and external capabilities (“be-
`
`havior element’’) that, among other things, can produce a graphical image of the shape.
`
`GOOGLE1004 at 13:13-17; GOOGLE1003, 111] 36-45. Walton is not alone, as the other ref-
`
`erences cited herein likewise disclose this same functionality.
`
`In sum, if the Office had been aware of Walton or the other cited references, the ‘633
`
`patent neverwould have issued. Petitioners therefore request the Board to institute inter
`
`partes review of the challenged claims on the grounds set forth below.
`
`ll.
`
`MANDATORY NOTICES UNDER 37 C.F.R § 42.8
`
`A. Real Parties-In-Interest Under 37 C.F.R. § 42.8(b)(1)
`
`Google Inc., Samsung Telecommunications America, LLC, Samsung Electronics
`
`America, Inc., and Samsung Electronics Co|., Ltd. are the real parties-in-interest.
`
`B. Related Matters Under 37 C.F.R. § 42.8(b)(2)
`
`Petitioners are not aware of any reexamination certificate or certificate of correction
`
`for the ‘633 patent. The Patent Owner (Micrografx, LLC) is a non-practicing entity that filed
`
`complaints alleging infringement of the ‘633 patent in lawsuits against Petitioners (Micro-
`
`grafx, LLC, v. Google, Inc. and Motorola Mobility, LLC, N.D. Tex., Case No. 3:13—cv—03595—
`
`N; Micrografx, LL C, v. Samsung Telecommunications America, LLC, Samsung Electronics
`
`America, Inc., and Samsung Electronics Co., Ltd., N.D. Tex., Case No. 3:13-cv-03599-N).
`
`Both complaints were filed on September 9, 2013, and both actions remain pending. Peti-
`
`2
`
`

`
`tioners have also petitioned — on this same day — for Inter Partes Review of two other pa-
`
`tents at issue in the above-noted litigation: U.S. Patent 6,057,854 (Davis, Jr. et al.) and
`
`U.S. Patent 6,552,732 (Davis, Jr. et al.).
`
`C. Lead And Back-Up Counsel Under 37 C.F.R. § 42.8(b)(3)
`
`Petitioners provide the following designation of counsel.
`
`LEAD COUNSEL
`
`BACK-UP COUNSEL
`
`
`
`John C. Phillips, Reg. No. 35,322
`12390 El Camino Real
`San Diego, CA 92130
`Tel: 858-6784304 / Fax 858-678-5099
`
`Michael T. Hawkins, Reg. No. 57,867
`3200 RBC Plaza, 60 South Sixth Street
`Minneapolis, MN 55402
`Tel: 612-337-2569 I Fax 612-288-9696
`
`D. Service Information
`
`Please address all correspondence and service to the address of both counsel listed
`
`above. Petitioners also consent to electronic service by email at 19473-0309|P1@fr.com
`
`(referencing No. 19473-0309|P1 and cc’ing phi||ips@fr.com and hawkins@fr.com).
`
`Ill.
`
`PAYMENT OF FEES — 37 C.F.R. § 42.103
`
`Petitioners authorize the Patent and Trademark Office to charge Deposit Account
`
`No. 06-1050 for the petition fee set in 37 C.F.R. §42.15(a) and for any other required fees.
`
`IV.
`
`REQUIREMENTS FOR IPR UNDER 37 C.F.R. § 42.104
`
`A. Grounds for Standing Under 37 C.F.R. § 42.104(a)
`
`Petitioners certify that the ‘633 patent is eligible for IPR and that Petitioners are not
`
`barred or estopped from requesting IPR.
`
`B. Challenge Under 37 C.F.R. § 42.104(b) and Relief Requested
`
`Petitioners request IPR of claims 1-4, 6, 8-11, 13, and 15 of the ‘633 patent on the
`
`

`
`grounds listed in the table below.
`
`In support, this Petition includes claim charts for each of
`
`these grounds and a supporting evidentiary declaration of Dr. Anselmo Lastra.
`
`(GOOGLE1003).
`
`1-4, 6, 8-11,
`
`Basis for Rejection
`Anticipated under§ 102 by U.S. Patent No. 5,883,639 to Wal-
`
`13, and 15
`
`ton et al. (“Walton”)
`
`sion 1.5 by David J. Kruglinski (Kruglinski)
`
`1-4, 6, 8-11,
`
`Obvious under§ 103 by U.S. Patent No. 5,564,048 to Eick et
`
`13, and 15
`
`al. (“Eick”) in view of Inside Visual C++, Second Edition: Ver-
`
`Walton and Eick are both prior art under at least 35 U.S.C. §102(e), having an effec-
`
`tive filing date years before Oct. 4, 1996. Kruglinski is prior art under at least 35 U.S.C.
`
`§102(b), having a publication date before Oct. 4, 1995 (U.S. Copyright Reg. No.
`
`TX0004058221). None of these references were considered by the Examiner during prose-
`
`cution of the ‘633 patent.
`
`V.
`
`SUMMARY OF THE ‘633 PATENT
`
`A. Brief Description
`
`The ‘633 patent is directed to a computer system for producing graphical images
`
`for use in a computer graphics program. GOOGLE1001 at 125-59. The specification of the
`
`‘633 patent contends that prior art systems “only enable a user to draw and edit a limited
`
`number of shapes. If additional shapes are desired, the computer program in the system
`
`must be modified to include the additional tools needed to draw and edit the desired shape.”
`
`

`
`Id. at 1:14-18. As described below, this characterization of the prior art was flawed, as there
`
`were numerous prior art references that overcome the supposed limitations. The ‘633 pa-
`
`tent further explains that “one computer graphics system incorporates a limited component
`
`plug-in capability utilizing tab|es.” Id. at 1:23-34. But this characterization of the prior art
`
`also was inconsistent with the state of the art at the time. The external shapes, according to
`
`the ‘633 patent, are computer programing objects libraries, or other data structures that are
`
`stored external to a computer program and that include data for use in producing graphical
`
`images.
`
`Id. at 3:17-29. External shapes include capabilities that “allow the generation of
`
`information required to produce a graphical image.” Id. at 3:29-31. These capabilities can
`
`include “action methods” and “symbol methods.” Id. “Action methods” define functions for
`
`receiving user interaction received by the application from an input device for creation or
`
`manipulation of graphical images defined by the external shapes.
`
`Id. at 6:19-29; 5:1-18.
`
`Examples of action methods include “the create action and edit actions.” Id. at 5:12-13.
`
`“Symbol methods” define functions for creating, editing, rendering, modifying, reading,
`
`and/or writing a graphic image.
`
`Id. at 7:14-16; 5:19-25. One example of a symbol method
`
`includes a rotate function for rotating a graphic image.
`
`Id. at 5:25-30.
`
`External shapes include external action data, which is data that is operated on by
`
`one or more action methods to define an external action.
`
`Id. at 6:4-6. External shapes fur-
`
`ther include external symbol data, which is data that is operated on by symbol methods to
`
`“create, edit, render, modify, read, or write a graphical object.” Id. at 7:14-16.
`
`

`
`Independent claim 1 is written nominally as a system claim, but in reality recites a
`
`generic computer, with method steps being recited in the context of a “computer program
`
`stored in [a] storage medium.” Claim 8 and its dependent claims are so-called Beauregard
`
`claims, reciting the identical method steps to Claim 1 and its dependent claims (or in the
`
`case of claim 15, nearly identical method steps) in the context of a “computer program en-
`
`coded on a computer-readable medium.” Independent claims 1 and 8 recite broad ele-
`
`ments of accessing an external shape object or library that includes capabilities for produc-
`
`ing a graphical image. Such functionality was well known in the art at the time the applica-
`
`tion that matured into the ‘633 patent was filed. The dependent claims recite similarly broad
`
`features that were also well known in the art at the time of filing.
`
`Indeed, numerous soft-
`
`ware programming platforms implemented in the early to mid 1990’s offered identical func-
`
`tionality of providing objects or libraries including capabilities for creating and manipulating
`
`graphical images that are stored external to applications. See GOOGLE1003 at 1] 17.
`
`B. Summary of the Original Prosecution
`
`The ‘633 patent was filed on October 4, 1996. Prior to this filing date, several dif-
`
`ferent systems and programming platforms described in patent applications and in other
`
`printed publications taught methods in which external objects and/or libraries containing
`
`code defining how to draw graphical images are accessed by one or more computer pro-
`
`grams. None of these prior art references were before the Examiner during the prosecution
`
`of the ‘633 patent. Instead, the two independent claims 1 and 8 at issue in this IPR were
`
`

`
`allowed in April 1999 after a brief examination involving prior art references that did not pro-
`
`vide an accurate picture of the state of the art.
`
`After all original 28 claims were rejected in the first office action, the applicant argued
`
`that claims 1-15 were patentable because the primary reference cited by the examiner did
`
`not explicitly suggest “an external shape stored outside the computer program” as recited in
`
`independent claims 1 and 8. GOOGLE1002 at pp. 101-104.
`
`In response to this argument,
`
`the examiner cited an additional reference (U.S. Patent No. 5,790,117 to Halviatti et at.) as
`
`teaching “an external shape stored outside the computer program.” Id. at pp. 109-110.
`
`The applicant countered that Halviatti does not teach an “external shape” and that
`
`the examiner did not provide a motivation to modify the primary reference (Visio) with the
`
`teachings of Halviatti.
`
`Id. at pp.124-126. However, the applicant did not address how the
`
`resulting combination of the systems described by Visio and Halviatti references would func-
`
`tion or how such a resulting combination would not include an “external shape.” Id. Rather
`
`than provide reasoning giving a motivation to modify the system taught by Visio with the
`
`teachings of Halviatti, the examiner allowed all claims with no express reasons for allow-
`
`ance other than the note in the Notice of Allowability that “this communication is responsive
`
`to the correspondence filed 1-26-99].” Id. at pp.129-130. Independent claims 1 and 8 were
`
`therefore allowed because the examiner accepted the applicant’s argument that the cited
`
`references, in isolation, did not disclose:
`
`“a computer program further operable to: access an external shape
`
`

`
`stored outside the computer program, the external shape comprising ex-
`
`ternal capabilities; and delegate the production of a graphical image of
`
`the external shape to the external capabilities.”
`
`Id., pp. 114, response filed Jan. 26, 1999.
`
`As described in more detail below, more pertinent prior art never considered by the
`
`examiner expressly disclosed an “external shape” and all other features of claims 1-4, 6, 8-
`
`11, 13, and 15.
`
`VI.
`
`Claim Construction under 37 C.F.R. §§ 42.104(b)(3)
`
`Claims are to be given their “broadest reasonable construction in light of the specifi-
`
`cation.” 37 C.F.R. § 42.100(b). The constructions are intended to aid in this proceeding,
`
`and should not be understood as waiving any arguments concerning indefiniteness or claim
`
`breadth that may be raised in any litigation, which requires different construction standards.1
`
`“external shape stored outside the computer program” (claims 1, 8) — an object,
`
`library component, or other data structure that contains source code, that is stored external
`
`to a computer program, and that includes data for use in producing a graphical image.
`
`GOOGLE1003 at 1] 21. This interpretation is consistent with the broadest reasonable inter-
`
`pretation of these terms and with the specification of the ‘633 patent. See GOOGLE1001 at
`
`2:66-3:7; 3:52-57; GOOGLE1003 at 1] 21 .
`
`1 The Patent Owner’s preliminary infringement contentions are attached as Exhibit
`
`GOOGLE1008 for the Board’s reference.
`
`

`
`“external capabilities” (claims 1, 8, 15) — As defined in the ‘633 patent, “capabili-
`
`ties” are “action methods, symbol methods, or any other functions that allow the generation
`
`of information required to produce a graphical image.” GOOGLE1001 at 3:29-31. “External
`
`capabilities,” therefore, are such capabilities that are external to a computer program.
`
`GOOGLE1003 at 1] 22. This interpretation is consistent with the broadest reasonable inter-
`
`pretation of these terms and with the specification of the ‘633 patent.
`
`Id. at 1] 22.
`
`“delegate” (claims 1,2, 8, 9) — the plain meaning of “delegate” is “to commit or en-
`
`trust to another.” GOOGLE1007 at p. 493. The ‘633 patent provides no express meaning
`
`for the term “delegate” that is different from this aforementioned definition. This interpreta-
`
`tion is consistent with the broadest reasonable interpretation of these terms and with the
`
`specification of the ‘633 patent. See GOOGLE1001 at 3:17-31; GOOGLE1003 at 1] 23.
`
`“external action” (claims 2-4, 9-1 1) — functions and data that are external to the
`
`computer program and that are operable to receive user interaction. GOOGLE1003 at 1] 24.
`
`This interpretation is consistent with the broadest reasonable interpretation of these terms
`
`and with the specification of the ‘633 patent. See GOOGLE1001 at 621-29.
`
`“external symbol” (claims 2, 3, 6, 9, 10, 13) — functions and data that are external
`
`to the computer program and that are operable for creating, editing, rendering, modifying,
`
`reading, and/or writing a graphical image. GOOGLE1003 at 1] 25. This interpretation is
`
`consistent with the broadest reasonable interpretation of these terms and with the specifica-
`
`tion of the ‘633 patent. See GOOGLE1001 at 7:11-16.
`
`

`
`VII.
`
`THERE IS A REASONABLE LIKELIHOOD THAT AT LEAST ONE CLAIM OF THE
`
`‘633 PATENT IS UNPATENTABLE
`
`As detailed below, claims 1-4, 6, 8-11, 13, and 15 of the ‘663 patent are anticipated
`
`by at least one reference (Grounds 1) and rendered obvious by another combination of ref-
`
`erences (Ground 2). The two Grounds are not cumulative or redundant. Instead, they rely
`
`upon different primary references that individually assert unique benefits to the user and,
`
`additionally, they address the dependent claims in different ways, including using different
`
`statutory grounds of§ 102 and § 103. See GOOGLE1003 at 111] 26-164.
`
`For example, the Walton patent, on which Ground 1 is based, describes a system for
`
`allowing users to create graphical user interfaces “without knowledge of programming Ian-
`
`guages and without having to learn a large set of complicated commands.” GOOGLE1004
`
`at 3:55-59. The system of Walton allows non-programming savvy lay-users to create a user
`
`interface and animations for graphical images by providing examples of how objects should
`
`respond to user input through a process of “animation by example.” Id. at 3:59-67. The user
`
`can add “graphical objects” to the user interface and identify how the graphical objects are
`
`to respond to user input. Id. at 426-20.
`
`By contrast, the Eick patent, on which Ground 2 is based, describes a C++ pro-
`
`gramming environment which provides graphical object classes, drawing classes, and func-
`
`tion classes that allow a programmer to call the classes from applications written by the
`
`programmer. See GOOGLE1005 at Abstract; 4:19-42; 5:35-55. The system of Eick allows
`
`10
`
`

`
`a “programmer [to] use components from the [class] library in his program.” (Id.at 1:51-57.)
`
`Specifically, the class libraries taught by Eick are intended for “use in object-oriented
`
`graphics programming.” Thus the system of Eick is implemented for the benefit of computer
`
`programmers writing graphics programs in object-oriented languages, such as C++, while
`
`the system described by Walton is implemented for the benefit of non-programmers when
`
`creating user interfaces. The two Grounds of rejection differ in the way in which they ad-
`
`dress the claim elements of the ‘633 patent in numerous other ways, as detailed below.
`
`A. Ground 1 sets forth a reasonable likelihood to prevail on at least one of
`Claims 1-4, 6, 8-11, 13, and 15
`
`Referring to Ground 1 (charted below), Walton discloses accessing external graph-
`
`ical objects, each of which includes an external shape (“graphic element’’) and external ca-
`
`pabilities (“behavior element’’) that, among other things, can produce a graphical image of
`
`the shape. GOOGLE1004 at 13:13-17; GOOGLE1003 at 111] 36-45. Walton also discloses
`
`delegating the production of a graphical image to the external capabilities. GOOGLE 1004
`
`at 11:8-9; 13:19-31; GOOGLE1003 at 111] 46-49. Walton also discloses that the graphical
`
`objects are stored externally from a program (“user code”). GOOGLE1004 at 8:54-65;
`
`21:10-16; 21:44-46.
`
`More specifically, the system taught by Walton utilizes external graphical object li-
`
`braries for storing graphical object data and input, drawing, and manipulation functions for
`
`various graphical objects that allow user applications to access the graphical objects and
`
`associated functionality stored within the external libraries. See GOOGLE1004 at 9:24-25;
`
`11
`
`

`
`9:46-47; 6:8-10; 6:17-20; 8:54-65; 21:10-16; GOOGLE1003 at 111] 36-49. Annotated Fig. 3
`
`of Walton below shows a modular arrangement for storing graphical object data and func-
`
`tionality in a “library of graphical objects 320” that is stored externally to an application, la-
`
`beled as “user’s source code 360:”
`
`/\
`
`shape objects are
`stored external to the
`
`computer program
`
`nrsruu
`
`Walton discloses that graphical objects are “stored as objects in an object-oriented
`
`database system and connected to other objects or user code” and that such techniques for
`
`storing the graphical objects external to the user code were “commonly used in object-
`
`oriented systems” at the time that the Walton patent was written. GOOGLE1004 at 8:54-59.
`
`12
`
`

`
`Walton further discloses that these external graphical objects can be “accessed by the user
`
`code 120” by connecting to “a client server via an interprocess communications mechanism
`
`of a type known to those skilled in the art.” Id. at 8:58-62. Walton describes that storing the
`
`graphical objects externally to the user application is “particularly advantageous in that the
`
`user application code can read input and send outputs to the display screen using the cre-
`
`ated graphics objects without requiring the designer to write interface code.” Id. at 8:24-27.
`
`Walton further discloses delegating drawing and other functions relating to the exter-
`
`nal shapes to the externally stored graphical objects. For example, Walton indicates that “a
`
`graphical object in accordance with the invention must be able to draw itself if asked to do
`
`so.” Id. at 13:19-21 (emphasis added). Walton additionally discloses that each “graphical
`
`object is responsible for controlling itself” and that a graphical object is responsible for
`
`“chang[ing] its graphical representation .
`
`.
`
`. on the display” in response to user input or other
`
`events.
`
`Id. at 11:8-9; 13:26-30.
`
`For at least these reasons, and the additional explanations set forth in the chart be-
`
`low, there is a reasonable likelihood that claims 1-4, 6, 8-11, 13, and 15 of the ‘633 patent
`
`are anticipated by Walton. See, e.g., GOOGLE1003 at 111] 26-49 (providing evidence that
`
`claim 1 is anticipated); see also 111] 50-86. Moreover, to the extent the Patent Owner argues
`
`that any element of claims 1-4, 6, 8-11, 13, and 15 is not expressly disclosed in the Walton
`
`patent, such element would be inherently disclosed or rendered obvious in view of the dis-
`
`closure of the Walton patent and in light of the knowledge of a POSITA, especially in light of
`
`

`
`the fact that Walton provides a system (for storing, externally to a computer program, graph-
`
`ical elements having external capabilities) that is virtually the same as the preferred embod-
`
`iment of the ‘633 patent. GOOGLE1003 at 1] 88.
`
`B. Ground 2 sets forth a reasonable likelihood to prevail on at least one of
`Claims 1-4, 6, 8-11, 13, and 15
`
`Referring to Ground 2 (charted below), Eick is directed to a computer graphics sys-
`
`tem for drawing shapes in an object-oriented programming environment, such as C++. See
`
`GOOGLE1005 at 4:19-42. The system allows a program to call drawing classes from a
`
`class library and delegate various drawing functions to the called classes. See Id. at 1:51-
`
`57; 4:15-17; 5:35-55. Each class can inherit other classes to provide various functions and
`
`shape drawing capabilities to the inheriting class. See Id. at 6:6-9; 9:22-27; 13:1-8. For ex-
`
`ample, Eick discloses that any graphical object class “can inherit .
`
`.
`
`. any number of the
`
`functionality classes 203 defined by class library 21 1
`
`Id. at 6:6-9.
`
`Inherited classes allow
`
`a graphical object class “to respond to drawing commands” and perform functions, such as
`
`“draw[ing] either the frame or a filled shape” for the graphical object.
`
`Id. at 53-56; 22:16-19.
`
`FIG. 5 shows library class F|oatDraw inheriting the classes VzDrawingArea, VzDrawer, and
`
`VzMouseable:
`
`14
`
`

`
`FIG‘.
`
`5
`
`_
`
`'_
`V:
`
`sg
`
`[lR.IL‘I'Il NC
`
`AREA
`\ "- X
`
`305
`
`I
`
`V: DRMITR
`
`I
`I
`I
`
`‘~~.
`
`x
`
`,
`- rum um
`I
`case
`
`323-
`r"
`I
`
`‘I
`
`,/'
`
`503
`
`_
`
`335
`
`V:
`
`IICIUSEAELE
`
`z ’
`
`“-:/JR
`/' /
`
`The inherited VzMouseab|e class allows F|oatDraw to receive user input from a
`
`mouse, while the inherited VzDrawer class draws the actual object defined by a class that
`
`inherits F|oatDraw.
`
`Id. at 5:23-34; 5:58-60; 6:54-61; 22:16-19. The drawing classes (such
`
`as VzBarLayout and F|oatDraw) that are called from the class library are able to use func-
`
`tions and capabilities provided in inherited classes to draw and manipulate graphical objects
`
`on a display screen. See Id. at 8:40-47; 9:56-10:14; GOOGLE1003 at 111] 89-92.
`
`For example, the graphical object class “VzBarLayout” has capabilities for “drawing
`
`either rows or columns of bars and [allowing a user to use] the mouse to manipulate them.”
`
`Id. at 8:40-44. Eick further discloses that the VzBarLayout class inherits the VzDrawingArea
`
`and VzMouseab|e classes and “is used to draw .
`
`.
`
`. either rows (horizontal) or columns (ver-
`
`tical) of bars” in response to tracked mouse movements.
`
`Id. at 13:1-3. The VzBarlayout
`
`class that draws bar shapes also inherits the VzDrawer class. Id. at 8:44-47.
`
`Additionally, while Eick does not explicitly state that its C++ graphic object libraries
`
`are external libraries, the functionality described in Eick suggests implementation of the li-
`
`braries of Eick as external libraries. (GOOGLE1003 at 1] 105.) For example, Eick discloses
`
`15
`
`

`
`that ‘‘libraries of components of graphical user interface programs” can be implemented to
`
`allow a “programmer [to] use components from the library in his program and thus avoid
`
`having to write and debug them himself.” (GOOGLE1005 at 1:51-57.) Eick also describes
`
`the graphic object libraries not as being written as part of a graphics program, but as stand-
`
`alone objects that “may be used in writing a graphics program.” (GOOGLE1005 at 4:14-17.)
`
`Additionally, persons of ordinary skill in the art prior to October 1996 commonly un-
`
`derstood that a C++ library could be made into an external library, such as a .DLL or a
`
`shared library. GOOGLE1003 at 111] 106-111. For example, Kruglinski, a text on a C++
`
`programming language, describes that any class can be compiled into an external DLL li-
`
`brary, describing such libraries as “an important part of Windows-based programming....
`
`DLLs are Windows-based program modules that can be loaded and linked at run time.
`
`Many applications can benefit by being split into a series of main programs and DLLs.” Id.
`
`Kruglinski describes an example project in which several classes are grouped into a
`
`DLL.
`
`Id. at pg. 645. The classes in Krug|inski’s example project "have mostly the same
`
`source code as their statically linked counterparts, except for some added code that
`
`demonstrate resource searching and runtime class access." Id. This use of external DLL
`
`files for storing libraries mirrors language in the ‘633 patent describing how external shapes
`
`are accessed by a user program. See the ‘633 patent at 3:52-67 (describing that the “shape
`
`collection modules 212 and 214 comprise a dynamic link library (DLL) that allows executa-
`
`16
`
`

`
`ble routines to be stored separately as files with DLL extensions and to be loaded only when
`
`needed by the program that calls them”); see also 4:27-32.
`
`There are a number of reasons that would have prompted a person of ordinary skill
`
`in the art (POSITA) to combine this functionality disclosed in Kruglinski with the teachings of
`
`Eick. First, a POSITA would have been prompted to store the classes of Eick as DLL librar-
`
`ies as taught by Kruglinski because Eick describes that its library is written in C++, and a
`
`POSITA would understand, as taught in Kruglinski, that when programming in C++, “[m]any
`
`applications can benefit by being split into a series of main programs and DLLs.”
`
`GOOGLE1006 at pg. 635; see also GOOGLE1003 at 111] 108-111 One such benefit is sug-
`
`gested by Eick, which discloses that splitting an application into a series of main programs
`
`and DLLs would allow a programmer to write a graphics program without having to worry
`
`about writing and debugging the graphic object class libraries. GOOGLE1005 at 1:51-57.
`
`Second, as a POSITA would have understood, storing libraries as DLL files allows
`
`for programs to be designed as a series of “modules” that can share various libraries, there-
`
`by allowing for quicker loading of programs, which would have prompted a POSITA to mod-
`
`ify the system of Eick with the teachings of Kruglinski. Kruglinksi recognized this benefit:
`
`“You might have separate programs, or modules, for Payroll, Accounts Receivable, and so
`
`forth, but these programs have a lot of functionality in common. All modules might share
`
`the same list management and database access classes, for example.
`
`If you put the
`
`shared code in one or more DLLs, the individual modules will be smaller on disk and there-
`
`17
`
`

`
`fore guicker to load.’’ GOOGLE1006 at pg. 635 (emphasis added). This same benefit was
`
`recognized by the ‘633 patent, touting that “the invention provides for modular production.”
`
`GOOGLE1001 at2:1-2.
`
`Third, a POSITA would have been motivated to implement the libraries of Eick as
`
`external DLL files to achieve the benefit of allowing multiple applications to access the li-
`
`braries, as taught by Kruglinski. See GOOGLE1003 at 1] 110.
`
`Fourth, a POSITA would have been prompted to modify Eick’s system with this well-
`
`known feature of Kruglinski because doing so would be merely the use of a known tech-
`
`nique (e.g., storing of libraries as external DLL files) to improve similar devices (e.g., object
`
`oriented programs implementing object libraries) in the same way.
`
`Indeed, “when a patent
`
`‘simply arranges old elements with each performing the same function it had been known to
`
`perform’ and yields no more than one would expect from such an arrangement, the combi-
`
`nation is obvious.” KSR Int’I Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007). Here, both Eick
`
`and Kruglinski disclose the creation of class libraries using C++, with Kruglinski describing
`
`an improvement for the creation, storage, and access of such libraries. A POSITA would
`
`have readily applied the capability to store C++ class libraries as external DLL files (as
`
`taught by Kruglinski) to Eick’s C++ class libraries, so as to provide a predictable result (e.g.,
`
`a prior art method for storing class libraries). GOOGLE1003 at 1] 111. Also, the resulting
`
`combination would continue to provide the original functionality taught by Eick (e.g., classes
`
`defining shapes having associated capabilities stored within libraries) while also providing
`
`18
`
`