throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`__________________
`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket