`__________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________________
`
`GOOGLE INC.,
`SAMSUNG ELECTRONICS AMERICA, INC. AND SAMSUNG
`ELECTRONICS CO., LTD.
`Petitioners
`
`v.
`
`MICROGRAFX, LLC
`Patent Owner
`
`__________________
`
`
`Case IPR2014-00532
`Patent 5,959,633
`
`______________________________________________________
`
`
`
`
`
`PETITIONER’S REPLY TO PATENT OWNER’S RESPONSE
`
`
`
`
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`
`TABLE OF CONTENTS
`
`
`I. Claim interpretations ..................................................................................................... 1
`A. Broadest Reasonable Interpretation standard should be applied under 37 C.F.R.
`§ 42.100(b) .......................................................................................................................... 1
`B. “external shape stored outside the computer program” (claims 1, 8) .................. 1
`C. “delegate” (claims 1, 2, 8, 9) ...................................................................................... 3
`II. Walton discloses “an external shape stored outside the computer program” ....... 4
`III. Walton discloses a “computer program further operable to: . . . delegate the
`production of a graphical image of the external shape to the external
`capabilities.” ............................................................................................................... 7
`IV. The obvious combination of Eick in view of Kruglinski would provide an external
`class (at least an external FloatDraw class) having external capabilities. ......... 11
`V. Eick teaches additional graphical image drawing classes that can be
`implemented as DLLs using the teachings of Kruglinski. .................................... 13
`VI. Eick does not teach away from implementing the classes and class libraries of
`Eick as DLLs as taught by Kruglinski. .................................................................... 14
`
`
`
`i
`
`
`
`
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`
`EXHIBIT LIST
`
`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 (“Kruglinski”)
`
`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
`Action No. 3:13-cv-03595-N, Plaintiff Micrografx, LLC’s Preliminary
`Disclosure of Asserted Claims and Infringement Contentions dated
`January 6, 2014
`
`GOOGLE1009
`
`Almeling Declaration In Support of Google's Motion for Pro Hac Vice
`Admission
`
`GOOGLE1010
`
`Second Declaration of David S. Almeling in Support of Petitioners’
`Motion for Pro Hac Vice Admission
`
`GOOGLE1011
`
`Second Declaration of Dr. Anselmo Lastra
`
`GOOGLE1012
`
`
`
`Transcript of the Deposition of Mr. Garry Kitchen
`ii
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`GOOGLE1013
`
`Assignment history of the ‘633 patent
`
`GOOGLE1014
`
`Select portions of The C++ Programming Language, Second Edition
`by Bjarne Stroustrup, June 1993 (“Stroustrup”)
`
`GOOGLE1015
`
`U.S. Patent No. 5,999,987 to O’Farrell et al. (“O’Farrell”)
`
`GOOGLE1016
`
`U.S. Patent No. 5,923,877 to Berner et al. (“Berner”)
`
`GOOGLE1017
`
`PCT Pub. No. WO/1996/008765 to Foody et al. (“Foody”)
`
`GOOGLE1018
`
`U.S. Patent No. 4,622,633 to Ceccon et al. (“Ceccon”)
`
`GOOGLE1019
`
`U.S. Patent No. 5,475,817 to Waldo et al. (“Waldo”)
`
`GOOGLE1020
`
`European Patent Pub. No. EP0567699 A1 to Barman (“Barman”)
`
`GOOGLE1021
`
`U.S. Patent No. 5,726,979 to Henderson et al. (“Henderson”)
`
`GOOGLE1022
`
`Reserved
`
`GOOGLE1023
`
`Patent Owner’s Response for IPR2014-00532 (NOT FILED)
`
`
`
`
`
`
`
`iii
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`
`
`
`Case Law
`
`TABLE OF AUTHORITIES
`
`In re Cuozzo Speed Technologies, LLC, ___ F.3d ___, 2015 WL 448667 (Fed. Cir. 2015) .. 1
`In re Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994) .............................................................. 2
`
`
`Decisions of the Patent Trial and Appeal Board
`
`SAP America, Inc. c. Versata Dev. Group, Inc., CBM2012-00001 ......................................... 1
`Intel Corporation v. Fuzzysharp Technologies, Inc., IPR2014-00001 Paper 23 .................. 13
`
`iv
`
`
`
`
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`
`The arguments of Patent Owner (“PO”) all rely upon improper claim interpretations
`
`and mischaracterizations of the prior art, and the instituted grounds for rejection here should
`
`be maintained. Further, PO implies that it is somehow related to original patentee
`
`“Micrografx” (at p. 3), but in fact PO (Micrografx LLC) is merely a new “patent assertion
`
`entity” that misleadingly selected its name in 2013 to be similar to the now-defunct, original
`
`patentee (Micrografx, Inc.). See Ex. 1013 (compare “Assignment 1” to “Assignment 18”). To
`
`be clear, PO does not and never has developed computer graphics software or otherwise
`
`contributed to any computer graphics innovation. PO’s contentions lack credibility.
`
`I. Claim interpretations
`A. Broadest Reasonable Interpretation standard should be applied under 37
`C.F.R. § 42.100(b)
`PO objects to use of the “broadest reasonable interpretation” (BRI) standard, but the
`
`Federal Circuit recently affirmed that the BRI standard is proper based on both legislative
`
`intent and the PTO’s rule-making authority. In re Cuozzo Speed Technologies, LLC, ___
`
`F.3d ___, 2015 WL 448667, *6-*7 (Fed. Cir. 2015). Also, the Board enumerated numerous
`
`public policy reasons supporting use of the BRI standard, all of which were ignored by PO.
`
`SAP America, Inc. c. Versata Dev. Group, Inc., CBM2012-00001, pap. 70 at pp. 7-18. PO
`
`had the opportunity to amend the claims, yet it failed to make a good faith attempt to do so.
`
`B. “external shape stored outside the computer program” (claims 1, 8)
`PO’s claim interpretation is overly narrow and should be rejected because it attempts
`
`
`
`to import limitations from the specification by including a requirement that external shapes
`1
`
`
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`“can be developed and provided for use by the computer program without modifying the
`
`computer program.” Ex. 1011 at ¶¶ 4-12. To be clear, this imported limitation is found
`
`nowhere in the claims and is not included in any “lexicographer” definition of “external
`
`shape” within the specification. In re Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994). The
`
`inventor was surely aware of how to provide such a lexicographer definition for a claim term
`
`as the ‘633 specification includes precisely such an example for the term “capabilities.” See
`
`Ex. 1001 at 3:30-32; Petition at 2; Inst. Dec. at 9.
`
`By contrast, the ‘633 patent contains no such lexicographer definition of the term
`
`“external shape.” See Ex. 1012 at 22:19-23:1. Rather, PO attempts to import portions of the
`
`‘633 patent specification which express a purportedly preferred benefit of avoiding
`
`modification of existing programs. See Ex. 1001 at 2:6-9 (“The invention also provides . . .”);
`
`Resp. at 11. However, this benefit is merely one in a list of numerous other alleged benefits
`
`of the preferred embodiment, and is not tied explicitly or implicitly to the claim term “external
`
`shape.” Even through the ‘633 patent lists numerous other alleged benefits that “the
`
`invention provides,” PO gives no explanation as to why one of the alleged benefits that “the
`
`invention provides” (col. 2:6-9) should be imported into the definition of a claim term while
`
`others should not. E.g., id. at 2:1-3 (“the invention provides for the modular production of
`
`additional shapes.”); 1:60-63 (“The invention provides several technical advantages
`
`[including that] shapes may be developed by third parties, addressing particular markets.”);
`
`
`
`2
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`3:43-44; 4:27-32. Not even PO’s expert, Mr. Kitchen, can explain this glaring inconsistency.
`
`Ex. 1012 at 30:25-31:23; Ex. 1011 at ¶¶ 6-7.
`
`Additionally, the proposed construction in the Patent Owner’s Response is
`
`necessarily inconsistent with the plain claim language of “external shape” by eliminating any
`
`requirement for any type of “shape” or “graphical image”—instead referring only to generic
`
`“computer code stored outside the computer program” without any limit that the code is
`
`used in creating a shape or graphical image. Ex. 1011 at ¶ 8. Even Mr. Kitchen explained
`
`that the claim construction set forth at page 10 of the Response is incorrect and different
`
`from his corrected interpretation. Ex. 1012 at 21:4-14; Ex. 1011 at ¶ 9. The claims do not
`
`require the unclaimed limitation imported by PO, and such a limitation should not be read
`
`into the claims, especially when PO’s proposed construction would eliminate the term
`
`“shape” from the claims altogether.
`
`C. “delegate” (claims 1, 2, 8, 9)
`PO does not offer an explicit construction of the term “delegate” but does rely on an
`
`overly narrow interpretation of the term “delegate” throughout its argument section, implying
`
`that “delegate” means to commit or entrust to another’s independent actions. E.g., Resp. at
`
`31. However, there is no requirement in the claims or specification that “delegation” requires
`
`the external shape to be able to draw a graphical image completely unassisted and using
`
`only its own independent actions. Ex. 1011 at ¶¶ 13-14. In fact, the ‘633 patent explicitly
`
`contemplates that delegation of the production of a graphical image can comprise
`
`
`
`3
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`“generating data [by an external shape] that may be used by the computer graphics
`
`application 122 to place a graphical image on an output device,” thereby highlighting PO’s
`
`flawed assumption. Ex. 1001 at 3:20-24. The ‘633 patent discloses that the computer
`
`graphics application 122 and other components of the computer graphics system 110 are
`
`involved in the production of graphical images, including “shared library 130” and a “callback
`
`function” for making calls to external shapes. Id. at 4:27-38; 6:48-53; Ex. 1012 at 41:12-22.
`
`Mr. Kitchen identified additional components that would be required by the system of the
`
`‘633 patent to produce the graphical images including “software to display graphics on a
`
`screen,” and “low level graphic routines . . . that create the data.” Ex. 1012 at 38:17-39;
`
`43:21-44:14. As such, the Board properly determined that the term “delegate” does not
`
`require an external shape must be able to produce a graphical image completely
`
`independently of a computer application or any other components of a graphics system.
`
`Inst. Dec. at pp. 9-10. The Board’s initial determination was reasonable, proper, and
`
`consistent with the fact that the external shapes of the ‘633 patent merely generate
`
`information that is used by other components of the overall system 110 to place a graphical
`
`image on an output device. Ex. 1001 at 3:20-24; 6:48-53. Ex. 1011 at ¶ 14.
`
`II. Walton discloses “an external shape stored outside the computer program”
`Mr. Kitchen revealed that his analysis of Walton with respect to the term “external
`
`shape” (which PO relies upon for its conclusions about Walton) was based on an incorrect
`
`assumption that the “user code” of Walton is part of the VSE system. Ex. 1012 at 50:11-51:2
`
`
`
`4
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`(incorrectly stating that “[t]he user code is compiled into the final product which includes all
`
`of the code of the VSE system.”);49:7 (“yes, I rely on that in my conclusion”). Yet Mr.
`
`Kitchen’s assumption is demonstrably false, for Walton expressly discloses that “client
`
`server 414 establishes the connection between a user program and the VSE system 400
`
`and passes information between the two as required.” Ex. 1004 at 21:9-17; Ex. 1011 at ¶ 15
`
`(“the user program is separate from and external to the VSE system 400 (so that it can
`
`“connect” to the VSE system 400)”). PO’s arguments that Walton does not teach an
`
`“external shape” are all based on Mr. Kitchen’s erroneous assumption that Walton’s user
`
`code is part of the VSE system, and the conclusions based thereon must be disregarded.
`
`Further, PO contends that Walton does not disclose “external shapes” because
`
`“Walton discloses VSE objects that are created within the VSE system, and Walton does
`
`not disclose that such objects are ever used in any other system.” Resp. at 22. Even if PO’s
`
`assumptions about Walton are true, none of these requirements are found in the claims of
`
`the ‘633 patent—and certainly not under the BRI standard. Ex. 1011 at ¶¶ 16-18.
`
`First, there is no requirement in the claims that external shapes must be initially
`
`“created” external to an overall system that includes the computer program and the shape
`
`library. Ex. 1011 at ¶ 16. In contrast, the ‘633 patent contemplates that the external shape
`
`library 124 can include “shape collection modules delivered with computer graphics
`
`application 122” as well as “shape collection modules developed by third parties.” Ex. 1001
`
`
`
`5
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`at 4:12-16. Second, there is no requirement in the claims that external shapes must be
`
`“used” with multiple systems. Ex. 1011 at ¶ 18. In fact, the ‘633 patent only describes the
`
`“external shape library 124” in the context of use within the overall “system 110” (just like
`
`the overall “system” of Walton) and does not explain how any other system would somehow
`
`access and use the external shapes in external shape library 124 without the overall
`
`“system 110.” See Id. at 2:66-3:7; 4:63-67; Ex. 1011 at ¶¶ 17-18; Ex. 1012 at 48:1-10.
`
` Third, the claims merely require that the external shape is “outside the computer
`
`program,” not that the external shape is “outside an entire system containing the computer
`
`program and/or other components.” This is consistent with the ‘633 specification which
`
`describes both the “computer graphics application 122” and “external shape library 124” as
`
`being included in the overall “system 110.” See Ex. 1001 at 2:58-3:1; Ex. 1011 at ¶¶ 16 and
`
`19. In fact, the ‘633 patent shows the computer graphics application 122 accesses the
`
`shapes of the external shape library 124 as part of the overall “system 110,” much like FIG.
`
`3 of Walton shows the user source code 360 accesses the shapes of the library of graphical
`
`objects 320 in use with the overall VSE system. See Ex. 1011 at ¶¶ 17 and 19.
`
`PO further contends that the graphical objects of Walton are not external shapes
`
`because the behaviors (stored as design files) of Walton’s graphical objects “must be built
`
`within the VSE system.” Resp. at 24; see also Ex. 1004 11:23-30; Ex. 1003 at ¶¶ 42, 45, 49.
`
`However, as addressed above, there is no requirement in the claims or specification of the
`
`
`
`6
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`‘633 patent that external shapes must be created outside of the overall “system 110.” Ex.
`
`1011 at ¶ 19. Also, Walton’s graphic’s editor 310 is merely a preferred embodiment for
`
`creating graphical objects, but the undisputed testimony evidence shows that the VSE
`
`system was necessarily compatible with other graphic editors too. Id.; Ex. 2004 at 60:6-20.
`
`Contrary to PO’s contention at pages 23-24 of its Response, there is no requirement
`
`in the claims or the specification of the ‘633 patent that external shapes must be able to
`
`interact with the claimed computer program “without modification of the computer program”
`
`or that the external shapes must be “new” external shapes created after the computer
`
`program. Ex. 1011 at ¶ 20-22; supra at p. 6. Indeed, Mr. Kitchen agrees that the claimed
`
`“external shapes” need not be new. Ex. 1012 at 70:12-25. Even if the improperly narrow
`
`construction offered by PO is applied, there are still questions that are unanswered by PO’s
`
`evidence, including the question as to whether or not creating user code from whole cloth
`
`constitutes “modifying” the computer program. Ex. 1011 at ¶ 22. Furthermore, through the
`
`use of behavior state names for calling graphical objects, the system of Walton necessarily
`
`allowed for the use of new graphical objects with existing, unmodified user code merely by
`
`using the same behavior state name. Ex. 1011 at ¶ 21; Ex. 2004 at 56:11-57:6. PO’s
`
`myopic focus on features absent from the claims ignores what an ordinary artisan would
`
`have understood from Walton’s disclosure. Ex. 1011 at ¶¶ 16-23.
`
`III. Walton discloses a “computer program further operable to: . . . delegate the
`production of a graphical image of the external shape to the external capabilities.”
`
`
`
`7
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`
`PO contends that the user source code of Walton does not “delegate the production
`
`of a graphical image” to the external objects because “the graphical objects of Walton may
`
`only be drawn by the VSE system as a whole” and “both the graphics editor of the VSE
`
`system and view objects of the VSE system are always involved in the production of a
`
`graphical image in the VSE system.” Resp. at 25, 27-28. First, this is an extreme
`
`misrepresentation of the teachings of Walton. Ex. 1011 at ¶¶ 24-25. Walton describes
`
`certain components being involved in the drawing of graphical images (including graphical
`
`objects) but does not disclose or suggest that every component of the VSE system is
`
`involved in the generation of every graphical object. Ex. 1011 at ¶ 25; Ex. 1004 at 8:44-65
`
`Second, as addressed in section I.C., supra, there is no indication in the claims or
`
`the specification of the ‘633 patent that delegation of production of a graphical image to an
`
`external shape must be left solely to the independent actions of the external shape alone.
`
`To the contrary, the ‘633 patent explains that the computer graphics application 122, the
`
`shared library 130, and the “callback function” of the computer graphics system 110 are
`
`involved in “plac[ing] a graphical image on an output device.” Ex. 1001 at 3:20-24; 4:27-38;
`
`6:48-53. Walton parallels this system of the ‘633 patent. Ex. 1011 at ¶ 26. Even though
`
`Walton describes the graphics editor and view objects of the VSE system as being involved
`
`in displaying graphic images, the graphical objects store the particular behavior functions
`
`which are used to draw particular graphical images when called by the user source code
`
`
`
`8
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`using the behavior state name of the graphical object. Id.; Ex. 1004 at 8:16-21; 9:4-8; 17:50-
`
`58; 18:15-17. In other words, the graphical objects of Walton “generat[e] data that may be
`
`used by the [computer program] to place a graphical image on an output device” (just like
`
`that described in col. 3:20-24 of the ‘633 patent), so the production of graphical images is
`
`delegated to the graphical objects in a manner similar to the ‘633 patent embodiment. Ex.
`
`1011 at ¶ 26; Ex. 1001 at 3:20-24; Ex. 1004 at 8:54-60; 17:50-58; 18:15-17.
`
`PO further contends that “the production of a graphical image in the VSE system is
`
`always performed by the VSE system, not any graphical objects.” Resp. at 28; see also Id.
`
`at 17-18. This is a misrepresentation in that, as described above, the graphical objects of
`
`Walton generate data that is used to create graphical images of objects much like the
`
`external shapes of the ‘633 patent produce graphical images of the external shapes—by
`
`“generating data that may be used by the computer graphics application 122 to place a
`
`graphical image on an output device.” Ex. 1011 at ¶ 26-27.
`
`PO continues to misrepresent the teachings of Walton by asserting that “Walton
`
`expressly teaches that other components in the system are entrusted with [the]
`
`responsibility” of drawing images. Resp. at 29. After making this assertion, PO cites
`
`numerous portions of Walton that are taken out of context. Ex. 1011 at ¶¶ 29-30. For
`
`example, PO cites numerous portions that deal with designing of new graphical objects, not
`
`drawing of graphical images in response to a call by user code to behavior functions of an
`
`
`
`9
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`existing graphical object. Id. at ¶ 29. Walton explicitly and repeatedly teaches the delegation
`
`of drawing of graphical images to graphical objects. Id. at ¶ 30; Ex. 1004 at 13:19-30 (“a
`
`VSE [graphical] object of the invention tracks a behavior function (graphics manipulation)
`
`such that when a value change occurs (a behavior event), the VSE object can change its
`
`graphical representation and update itself on the display.”); 8:33-37; 18:63-64; 9:40-42.
`
`Furthermore, in his expert Declaration, Mr. Kitchen contends that Walton’s graphical
`
`objects do not really “draw themselves,” but that one cited portion of Walton (col. 13:19-22)
`
`is referring to objects “graphically react[ing] in some way when selected.” Ex. 2005 at ¶¶ 49-
`
`50. However, Walton makes clear that a first function (displaying an indication of the object
`
`being selected) is distinct from a second function (the object drawing itself). Ex. 1011 at ¶
`
`31; Ex. 1004 at 13:19-22. Mr. Kitchen’s erroneously contends that “[o]utside of the out-of-
`
`context quote above (‘a graphical object… must be able to draw itself’), there is no other
`
`indication in Walton of the objects having the ability to be delegated the production of their
`
`own graphical image.” See Ex. 2005 at ¶ 51. This statement is false, or at least highlights
`
`Mr. Kitchen’s confusion, for Walton includes numerous disclosures of delegation of drawing
`
`of graphical images to the capabilities of graphical objects. ). Ex. 1011 at ¶ 31; Ex. 1004 at
`
`13:26-30 (“when a value change occurs (a behavior event), the VSE object can change its
`
`graphical representation and update itself on the display” i.e., redraw itself) ; 23:50-51 (“[t]he
`
`
`
`10
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`universe 420 then tells the gray box to draw itself.”); 12:43-45 (“all objects . . . are told to
`
`redraw themselves.”); 25:67-26:2; 9:34-42; 8:33-37.
`
`PO again mischaracterizes the teachings of Walton by asserting that Walton’s
`
`graphical objects’ capabilities “are limited to what can be done inside the VSE environment
`
`as the shapes are directly dependent on the built-in capabilities of the VSE graphic editor.”
`
`Resp. at 30-31. However, although Walton describes objects being initially created using
`
`the graphic editor, once created, the objects draw themselves using their own behavior
`
`functions when called by the user code. Ex. 1011 at ¶¶ 32, 25-26, 29. Each of Walton’s
`
`graphical objects has behavior elements which define “output behavior states” and
`
`“graphics transformation of a graphics object, such as change of color, move, rotate, scale,
`
`stretch, fill, map, unmap, raise and lower.” Ex. 1004 at 9:24-25; 8:33-37; see also 8:7-21.
`
`IV. The obvious combination of Eick in view of Kruglinski would provide an external
`class (at least an external FloatDraw class) having external capabilities.
`PO contends that the object classes of Eick “do not contain any drawing capability.”
`
`Resp. at 44. This argument ignores that at least Eick’s FloatDraw class includes drawing
`
`capability, and the evidence here shows it was obvious in view of Kruglinksi’s teaching for
`
`“any class” of Eick (e.g., the FloatDraw class or other classes) to be implemented as a
`
`dynamically linked library (DLL). Ex. 1011 at ¶ 33; Ex. 1003 at ¶ 106. PO’s contends that
`
`the “DoExpose” function is responsible for all drawing operations, but PO ignores that the
`
`FloatDraw class plainly includes executable code for the “DoExpose” function. See Ex. 1005
`
`
`
`11
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`at FIG. 6B, 625; 10:6-8. FloatDraw clearly has drawing capability as “[o]bjects of the class
`
`FloatDraw 503 have three operations: . . . drawing [the] window 401, and responding to
`
`mouse selections.” Id. at 9:56-59; Petition at 44-45; Ex. 1011 at ¶ 35.
`
`Kruglinski shows it was obvious at the time for any of Eick’s object classes (including
`
`at least the FloatDraw class) to be implemented as a DLL, as Kruglinski teaches the
`
`predictable and well-known fact that “any class can be compiled into an external DLL
`
`library.” Ex. 1011 at ¶¶ 33-34; Ex. 1003 at ¶ 106; Ex. 1006 at 635; Ex. 1012 at 62:10-13.
`
`Both dynamically-linked and statically-linked libraries (whether they included one class or
`
`many classes therein) were known for over a decade prior to the filing of the '633 patent as
`
`available tools in the tool kit of a programmer. Ex. 1011 at ¶ 33; Ex. 1012 at 62:2-13; Ex.
`
`1006 at 635. Eick simply discloses a statically linked implementation of FloatDraw, with the
`
`“main” program making a direct call to the FloatDraw class. Ex. 1011 at ¶ 33; Ex. 1005 at
`
`FIG. 6D, 633; 10:28-34. A POSITA would have readily and easily known (especially from
`
`the teachings of Kruglinski) how to modify Eick to implement FloatDraw and its subclasses
`
`(shown in Eick’s FIGs. 6A-6C) as one or more DLLs external to the “main” program of Eick’s
`
`FIG. 6D. Ex. 1011 at ¶¶ 33-35; Ex. 1006 at 638 (“[c]onverting a statically linked class library
`
`application to a DLL-based application is easy”); 637; Ex. 1006 at ¶ 106. Indeed, even the
`
`‘633 patent concedes that DLLs were a traditional prior art option among many known
`
`options at the time, all of which were easily implemented without the need for further
`
`
`
`12
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`teaching in the ‘633 patent. Ex. 1001 at 4:27-32. Here, the application of Kruglinski’s
`
`textbook suggestion to Eick would be predictable, for “a skilled artisan would have sought a
`
`standard textbook” such as Kruglinski. Intel Corp. v. Fuzzysharp, IPR2014-00001 Pap. 23 at
`
`25; Resp. at 42; Ex. 2005 at 68 (a “generic Visual C++ manual”); Ex. 1012 at 61:9-15.
`
`PO further contends that the computer program of Eick must be modified in order to
`
`call object classes. Resp. at 46-47. As addressed in sections I.B. and II, supra, there is no
`
`requirement in the claims or the specification of the ‘633 patent that external shapes must
`
`be able to interact with the claimed computer program “without modification of the computer
`
`program.” Ex. 1011 at ¶ 36. Even if PO’s construction is applied, the claims are obvious
`
`over Eick in view of Kruglinski, at least because creating user code from whole cloth (to
`
`interact with already existing graphical object classes) would not constitute “modifying” the
`
`computer program. Id.
`
`V. Eick teaches additional graphical image drawing classes that can be implemented
`as DLLs using the teachings of Kruglinski.
`In addition to the FloatDraw class, Eick describes several other classes included in
`
`the class library 301 that include drawing functionality for drawing a graphic image of an
`
`object. For example, class library 301 includes VzBarLayout having capabilities for “drawing
`
`either rows or columns of bars” and VzTextArea which is described as “an object that draws
`
`lines of text.” Ex. 1005 at 8:40-44; 32:22. VzTextArea inherits VzDrawer which “gives an
`
`area object the ability to respond to drawing commands.” Id. at 32:27; 33:1-2; 6:54-61; Ex.
`
`
`
`13
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`1012 at 67:5-13. In view of the suggestions of Kruglinski, each of these drawing classes
`
`would have bene readily implemented as an external DLL, just as described with respect to
`
`FloatDraw in section IV, supra. See also Ex. 1003 at ¶ 106 (“any class”); and ¶¶ 99-105.
`
`VI. Eick does not teach away from implementing the classes and class libraries of
`Eick as DLLs as taught by Kruglinski.
`PO begins their assertion that Eick “teaches away” from implementing class libraries
`
`as DLLs with a drawn out discussion of whether Eick discloses “C++ graphic object
`
`libraries” or “C++ class libraries.” Resp. at 47-49. This discussion misses the point since, as
`
`explained by Dr. Lastra during his deposition, the choice of one term over the other is mere
`
`nomenclature. Ex. 2004 at 88:13-21; Ex. 1011 at ¶ 37.
`
`PO further contends that "[w]here customization is desired for the use of specific
`
`objects, the benefit that Kruglinski asserts for DLLs would not exist." Resp. at 42. However,
`
`this ignores situations in which customization is not prioritized (customization may be a goal
`
`of the ‘633 patent, but not Eick) and it further ignores the traditional situations in which
`
`different user programs would benefit from accessing the shape classes described in Eick
`
`(e.g., FloatDraw and others) using one or more DLLs. Ex. 1011 at ¶ 39; Ex. 1012 at 62:23-
`
`63:24 (listing benefits of using DLLs of which a POSITA would have been aware).
`
`PO also asserts that “Kruglinski’s stated benefits are only applicable in certain
`
`circumstances that are not applicable in Eick.” Resp. at 53. Yet this unsupported assertion
`
`ignores the explicit disclosure in Eick that splitting an application into a series of main
`
`
`
`14
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`programs and component libraries provides the benefit of allowing a programmer to write a
`
`graphics program without having to worry about writing and debugging each class library.
`
`Ex. 1005 at 1:51-57; Ex. 1011 at ¶¶ 38 and 40. This assertion also ignores the well-known
`
`benefits stated in Kruglinski, including quicker loading of programs. Ex. 1011 at ¶ 41;
`
`Petition at 17-18; Ex. 1006 at 635. PO offers no argument as to why quicker loading of
`
`programs developed using the system of Eick wouldn’t be desirable or as to why a
`
`programmer wouldn’t want to “conserve your users' disk space and memory” as stated by
`
`Kruglinski and noted by PO in their response. Resp. at 53; Ex. 1006 at 638.
`
`Furthermore, Eick’s background discussion of prior art “packaged libraries” is merely
`
`a statement about those then-existing specific software bundles, not a disparagement of all
`
`types of “external libraries”—and certainly not a disparagement of the commonly used DLLs
`
`(as PO contends). See Ex. 1011 at ¶¶ 42-43; Ex. 1005 at 1:51-57; 2:35-56; Resp. at 53-55.
`
`In fact, after describing the specific prior art package libraries, Eick explicitly states that
`
`“[t]he invention solves the foregoing problems”—a statement ignored by PO—and this
`
`solution would have been also be present in the resulting combination. Ex. 1005 at 2:63; Ex.
`
`1011 at ¶ 42. PO’s arguments here lack credibility.
`
`For the reasons discussed above, Petitioners request that this Board find all claims
`
`at issue here (claims 1-4, 6, 8-11, 13, and 15) invalid upon the instituted grounds.
`
`
`
`
`
`15
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Respectfully submitted,
`
`
`
`
` /Michael T. Hawkins/
`Michael T. Hawkins, Reg. No. 57,867
`
`
`
`
`Attorney for Petitioners
`
`
`
`
`Dated: February 13, 2015
`
`
`
`
`
`
`(Trial No. IPR2014-00532)
`
`
`
`
`16
`
`
`
`Case IPR2014-00532
`U.S. Patent No. 5,959,633
`Our Ref. 19473-0309IP1
`
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 CFR §§ 42.6(e)(4) and 42.205(b), the undersigned certifies that on
`
`February 13, 2015, a complete and entire copy of this Petitioner’s Reply to Patent Owner’s
`
`Response was provided via email to the Patent Owner by serving the correspondence email
`
`addresses of record as follows:
`
`
`
`
`Douglas R. Wilson
`Heim, Payne & Chorush, L.L.P
`9442 Capital of Texas Hwy.
`Plaza I, Suite 500-146
`Austin, TX 78759
`
`Nathan J. Davis
`Michael F. Heim
`Heim, Payne & Chorush, L.L.P
`600 Travis Street, Suite 6710
`Houston, Texas 77002
`
`Email: dwilson@hpcllp.com
`ndavis@hpcllp.com
`mheim@hpcllp.com
`micr