UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`GOOGLE INC., SAMSUNG TELECOMMUNICATIONS AMERICA, LLC,
`SAMSUNG ELECTRONICS AMERICA, INC. AND SAMSUNG
`ELECTRONICS COL., LTD.
`Petitioners
`
`v.
`
`MICROGRAFX, LLC
`Patent Owner
`
`CASE IPR2014-00532
`Patent 5,959,633
`
`PATENT OWNER’S PRELIMINARY RESPONSE UNDER 37
`CFR § 42.107 TO PETITION FOR INTER PARTES REVIEW
`OF UNITED STATES PATENT NO. 5,959,633
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`
`TABLE OF CONTENTS
`
`I.
`
`INTRODUCTION ............................................................................................ 1
`
`II. AUTHORIZATION FOR PAYMENT OF FEES ........................................... 1
`
`III. SUMMARY OF THE ARGUMENT ............................................................... 1
`
`IV. BACKGROUND .............................................................................................. 3
`
`A. History of Micrografx ...................................................................................... 3
`
`B. The ’633 Patent Invention ............................................................................... 3
`
`V. ARGUMENT ................................................................................................... 6
`
`A. Legal Standards ............................................................................................... 6
`
`B. Claim Construction .......................................................................................... 8
`
`C. The Petition Does Not Demonstrate a Reasonable Likelihood of Prevailing
`on Proposed Ground 1: Anticipation Under § 102 by Walton ............................... 8
`
`i. Overview of Walton ........................................................................................ 9
`
`ii. Walton cannot anticipate claims 1-4, 6, 8-11, 13, and 15 because it does not
`disclose a “computer program [further] operable to: . . . delegate the
`production of a graphical image of the external shape to the external
`capabilities” ................................................................................................... 13
`
`iii. Petitioners’ attempt to introduce obviousness with conclusory boilerplate
`language in their petition and expert declaration is improper, unsupported by
`evidence, and cannot meet their burden to justify instituting a trial ................ 18
`
`D. The Petition Does Not Demonstrate a Reasonable Likelihood of Prevailing
`on Proposed Ground 2: Obviousness Under § 103 by Eick in view of Inside
`Visual C++ ........................................................................................................... 19
`
`i. Overview of Eick ........................................................................................... 20
`
`ii. Overview of Kruglinski ................................................................................. 22
`
`ii
`
`

`
`iii. Claims 1-4, 6, 8-11, 13, and 15 would not have been obvious over Eick in
`view of Kruglinski because Eick teaches away from external libraries ........ 22
`
`VI. CONCLUSION .............................................................................................. 25
`
`
`
`iii
`
`

`
`TABLE OF AUTHORITIES
`
`Cases
`
`In re Abbott Diabetes Care, Inc.,
`696 F.3d 1142 (Fed. Cir. 2012) .............................................................................. 7
`
`In re Ochiai,
`71 F.3d 1565 (Fed. Cir. 1995) ................................................................................ 7
`
`In re Suitco Surface, Inc.,
`603 F.3d 1255 (Fed. Cir. 2011) .............................................................................. 7
`
`Net MoneyIN, Inc. v. VeriSign, Inc.,
`545 F.3d 1359 (Fed. Cir. 2008) .............................................................................. 6
`
`Phillips v. AWH Corp.,
`415 F.3d 1303 (Fed. Cir. 2005) .............................................................................. 7
`
`Sanofi-Synthelabo v. Apotex, Inc.,
`470 F.3d 1368 (Fed. Cir. 2006) .............................................................................. 6
`
`Scripps Clinic & Research Found. v. Genentech, Inc.,
`927 F.2d 1565 (Fed. Cir. 1991) .............................................................................. 6
`
`Toshiba Corp. v. Intellectual Ventures II LLC,
`IPR2014-00201, Paper 9 (May 21, 2014) .............................................................. 18
`
`TRW Automotive US LLC v. Magna Electronics, Inc.,
`IPR2014-00258, Paper 16 (June 26, 2014) ............................................................ 18
`
`Wowza Media Systems, LLC v. Adobe Systems Inc.,
`IPR2013-00054, Paper No. 12 (April 8, 2013) ...................................................... 19
`
`
`
`
`
`iv
`
`

`
`I.
`Patent Owner Micrografx, LLC
`
`INTRODUCTION
`
`(hereafter “Patent Owner”) hereby
`
`respectfully submits this Preliminary Response to the Petition seeking Inter Partes
`
`review in this matter. This filing is timely under 35 U.S.C. § 313 and 37 C.F.R.
`
`§ 42.107, as it is being filed within three months of the April 8, 2014 mailing date of
`
`the Notice granting the Petition a filing date.
`
`A trial should not be instituted in this matter as none of the grounds relied
`
`upon in the Petition gives rise to a reasonable likelihood of Petitioner prevailing with
`
`respect to any claim of U.S. Patent No. 5,959,633 (“the ’633 Patent”).
`
`II. AUTHORIZATION FOR PAYMENT OF FEES
`The Board is authorized to charge any fees incurred by the Patent Owner in
`
`this Case IPR2014-00532 to Deposit Account No. 504592.
`
`III. SUMMARY OF THE ARGUMENT
`The challenged claims recite a computerized system comprising a computer
`
`program that is “operable to: access an external shape . . . , the external shape
`
`comprising external capabilities; and delegate the production of a graphical image of
`
`the external shape to the external capabilities.” With respect to Ground 1 based on
`
`asserted anticipation by Walton, Petitioners failed to present a reasonable likelihood
`
`that Walton discloses external shapes with external capabilities and a computer
`
`program that delegates the production of a graphical image of the external shape to
`
`the external capabilities. Petitioners cannot show that a computer program can
`
`1
`
`

`
`delegate the production of a graphical image of an object within Walton’s Visual
`
`Software Engineering system to external capabilities within that object. Walton’s
`
`VSE system as a whole is needed to draw graphical images within the system, and
`
`Walton does not disclose that a user program can delegate any task to an object
`
`within the system.
`
`With respect to Ground 2 based on asserted obviousness over Eick in view of
`
`Kruglinski, Petitioners cannot show that the combination discloses external shapes.
`
`Eick discloses a C++ library that can be used to create classes with specific
`
`functionalities. Eick does not disclose that any of such classes or corresponding
`
`objects are external shapes because Eick does not disclose that the libraries are
`
`external to any computer program. Petitioners concede that Eick does not disclose
`
`that such classes are external to a computer program and rely on Kruglinski for the
`
`disclosure of external libraries. Petitioners argue that Eick discloses external libraries
`
`in its discussion of the prior art, suggesting an acknowledgement of external libraries.
`
`But to the extent that Eick discloses external libraries as prior art, Eick criticizes their
`
`use. Thus, Eick teaches away from the very combination Petitioners propose.
`
`Neither of the two grounds presented in the Petition raises a reasonable
`
`likelihood of success. Micrografx respectfully requests that the Petition be denied.
`
`2
`
`

`
`IV. BACKGROUND
`A. History of Micrografx
`Micrografx was an early innovator in the field of computer graphics software.
`
`In the mid-1990s, it developed several software packages that offered new
`
`capabilities for graphics publishing. These products included Windows Draw, a
`
`family-oriented software package that enabled home users to create materials like
`
`invitations, flowcharts, and stationery, and QuickSilver and Designer, which
`
`provided web users and web developers with new interactive graphics capabilities.
`
`The ’633 patent at issue in this case relates to the interactive graphics capabilities
`
`invented by Micrografx and implemented by its Windows Draw product.
`
`B. The ’633 Patent Invention
`The ’633 patent, which was filed on October 4, 1996, describes a novel way of
`
`producing interactive shapes in a computer graphics program by providing external
`
`shapes that can be accessed by the program and in which the program can delegate
`
`the production of the shapes to themselves. Prior to the ’633 patent, it was difficult to
`
`add new shapes to a computer graphics program after it was released by the software
`
`developer. GOOGLE1001 at 1:14-22. One method for adding shapes was to provide
`
`a table of data files, the data files containing information describing a shape. Id. at
`
`1:23-27. In such a system, however, the shape is created and edited with tools within
`
`the computer graphics program, which limits the capability to create and edit such
`
`new shapes to those already within the computer program. Id. at 1:27-34. If the
`
`3
`
`

`
`software developer wished to provide new shapes to its users, it had to revise the
`
`computer program. Id. at 8:24-34.
`
`Micrografx invented a new way to add shapes to a computer graphics program
`
`without requiring modification of the computer program itself. Id. at 1:41-2:9.
`
`Micrografx’s new shapes are provided externally to the computer program and with
`
`external capabilities that allow the production of a graphical image based on those
`
`capabilities. Id. at 1:41-59. Because the capabilities are provided with the new
`
`external shapes, the editing and drawing of the new external shapes are not limited to
`
`capabilities pre-existing in the computer program. The architecture of the system is
`
`reflected in Figure 3A from the ’633 patent:
`
`4
`
`

`
`
`
`Figure 3A shows how the computer graphics application (computer program) 122
`
`contains its own internal actions and internal symbols and provides templates to
`
`access an external shape library 124 with external capabilities.
`
`Additionally, new shapes may be added to the computer program without
`
`rewriting the code for the program. GOOGLE1001 at 1:60-62. Also, providing
`
`shapes as external libraries means that third parties can create shapes for a computer
`
`program that are directed to specific markets. Id. at 1:62-63. Providing shapes as
`
`external libraries allows for more frequent and less expensive updates for computer
`
`graphics packages. Id. at 1:66-2:1.
`
`5
`
`

`
`V. ARGUMENT
`
`A. Legal Standards
`“The Director may not authorize an inter partes review to be instituted
`
`unless the Director determines that the information presented in the petition filed
`
`under section 311 . . . shows that there is a reasonable likelihood that the petitioner
`
`would prevail with respect to at least 1 of the claims challenged . . . .” 35 U.S.C.
`
`§ 314(a).
`
`A patent claim is anticipated if, and only if, all limitations can be found
`
`either expressly or inherently within a single prior art reference. Sanofi-Synthelabo
`
`v. Apotex, Inc., 470 F.3d 1368, 1375 (Fed. Cir. 2006). The prior art reference
`
`“must not only disclose all elements of the claim within the four corners of the
`
`document, but must also disclose those elements ‘arranged as in the claim.’” Net
`
`MoneyIN, Inc. v. VeriSign, Inc., 545 F.3d 1359, 1369-70 (Fed. Cir. 2008) (internal
`
`citation omitted). “There must be no difference between the claimed invention and
`
`the reference disclosure, as viewed by a person of ordinary skill in the field of the
`
`invention.” Scripps Clinic & Research Found. v. Genentech, Inc., 927 F.2d 1565,
`
`1576 (Fed. Cir. 1991).
`
`To prove obviousness under 35 U.S.C. § 103, one must prove that “the
`
`differences between the subject matter sought to be patented and the prior art are
`
`such that the subject matter as a whole would have been obvious at the time the
`
`6
`
`

`
`invention was made to a person having ordinary skill in the art to which said
`
`subject matter pertains.” When assessing a proposed obviousness rejection, the
`
`Patent Office must make “a searching comparison of the claimed invention—
`
`including all its limitations—with the teachings of the prior art.” In re Ochiai, 71
`
`F.3d 1565, 1572 (Fed. Cir. 1995) (emphasis added).
`
`Patent Owner acknowledges 37 C.F.R. § 42.100(b), which states: “A claim
`
`in an unexpired patent shall be given its broadest reasonable construction in light
`
`of the specification of the patent in which it appears.”1 However, the Federal
`
`Circuit has instructed that “any such construction be consistent with the
`
`specification, and that claim language should be read in light of the specification as
`
`it would be interpreted by one of ordinary skill in the art.” In re Abbott Diabetes
`
`Care, Inc., 696 F.3d 1142, 1149 (Fed. Cir. 2012) (quoting In re Suitco Surface,
`
`Inc., 603 F.3d 1255, 1260 (Fed. Cir. 2011)).
`
`                                                            
`1 Patent Owner objects to the use of the “broadest reasonable interpretation”
`
`standard for claim construction during this post-grant proceeding where there is
`
`parallel district court litigation in which the same terms will be subject to
`
`construction under a different standard. Patent Owner respectfully submits that
`
`claim construction in this proceeding should be governed by the standard set forth
`
`in Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en banc).
`
`7
`
`

`
`B. Claim Construction
`Petitioners have proposed constructions for several claim limitations. For
`
`purposes of this Preliminary Response, Patent Owner contends that regardless of
`
`the construction adopted for the limitations at issue, Petitioner cannot show a
`
`reasonable likelihood of invalidity of any claim. Although Patent Owner does not
`
`agree with all of Petitioners’ proposed constructions, Patent Owner will not dispute
`
`them for purposes of this Preliminary Response but reserves the right to dispute
`
`them should the Board institute a trial on any ground.
`
`C. The Petition Does Not Demonstrate a Reasonable Likelihood of
`Prevailing on Proposed Ground 1: Anticipation Under § 102 by
`Walton
`
`Ground 1 of Petitioners’ petition proposes that claims 1-4, 6, 8-11, 13, and 15
`
`are anticipated under 35 U.S.C. § 102(e) by U.S. Patent 5,883,639 (hereinafter,
`
`“Walton”). Paper 5 at 4. Petitioners do not propose any obviousness grounds
`
`involving Walton. Id.
`
`Walton does not anticipate any of the challenged claims at least because it
`
`does not disclose external shapes with external capabilities and a computer program
`
`that delegates the production of a graphical image of the external shape to the
`
`external capabilities. Each of the challenged claims requires that a computer program
`
`“delegate the production of a graphical image of the external shape to the external
`
`capabilities,” but Walton does not disclose external shapes with external capabilities
`
`8
`
`

`
`that can produce a graphical image of the external shape. For this and the additional
`
`reasons stated below, Patent Owner respectfully requests that Petitioners’ request for
`
`trial on Ground 1 be denied.
`
`i. Overview of Walton
`
`Walton discloses a Visual Software Engineering (“VSE”) system as follows:
`
`The present invention relates to a system for designing a
`prototype of a user interface to a product without actually having to
`build a hardware user interface. In particular, a custom graphics display
`is developed in accordance with the invention so that operation of the
`prototype product may be viewed before the product is actually built.
`
`GOOGLE1004 at 7:62-67. Walton goes on to describe how objects are created in the
`
`VSE system:
`
`The invention of Fig. 3 is particularly characterized by an
`animator 340 which allows the user to define by example what input
`and output behavior states a graphical object should have. As will be
`described in more detail below, this is accomplished by storing the
`corresponding input and output behavior and display states with the
`graphics object and then selectively recalling this information for
`display on display 330 as an indication of what output change will result
`for a particular change in the input to the interface. . . . In addition, the
`behavior states of the graphical objects created by the graphics editor
`310 may also be linked to user source code 360 such that the source
`code 360 can manipulate the states of the graphical objects.
`
`9
`
`

`
`Id. at 9:22-40. Walton explains that it is the graphics editor of the VSE that manages
`
`the drawing of graphical objects:
`
`The graphics editor 404 creates the graphics for an object, but
`generally that is all. Once created, the graphical object is responsible
`for controlling itself, and the graphics editor 404 simply makes
`requests of the graphical object. During operation, the graphics editor
`404 queries the universe 420 to determine what object it is dealing with
`(i.e., what graphical object is selected), and then asks the object itself
`what requests are legal. . . .
`The graphics editor 404 in a preferred embodiment of the
`invention manages two types of files, a graphical file and a design file.
`The graphical file is created to store the graphical representations of
`objects for displaying or printing the appearance of those objects, while
`the design file contains the information the graphical file does along
`with descriptions of object relationships and object behavior functions.
`In other words, the graphical file stores pictures of objects, while the
`design file stores the appearance and behavior of objects.
`
`Id. at 11:7-30 (emphases added). Walton makes clear that even in the end product,
`
`the graphics editor of the VSE controls the drawing of graphical images:
`
`Because the VSE system 400 of the invention may be an integral
`part of the final product as well as a tool to create the final product, the
`VSE system 400 will preferably have two modes that greatly influence
`the behavior and appearance of the graphics editor 404. Edit mode is a
`mode in which the graphics editor 404 appears with all of its menus and
`palettes to allow the user to create a picture or model. In run mode,
`
`10
`
`

`
`however, these menus and palettes disappear to let the user exercise
`the created model with no indication that the VSE system 400 or the
`graphics editor 404 is present. Thus, in essence, the appearance and
`behavior of the VSE system 400 in run mode is the final product.
`
`Id. at 11:31-42 (emphasis added). Thus, Walton makes clear that the final product is
`
`not a library of external shapes but the VSE system as a whole including the graphics
`
`editor. Although Walton mentions that “the graphical object is responsible for
`
`controlling itself,” in the same sentence it makes clear that the graphical object is
`
`only drawn as part of the VSE system as a whole when it states that “the graphics
`
`editor 404 simply makes requests of the graphical object.” Id. at 11:8-10.
`
`Petitioners rely on “user code” as the computer program required by the
`
`claims, but the user code interfaces with the VSE system and does not directly access
`
`any graphical objects in the VSE system. As Walton explains:
`
`The behavior router 412 is the part of the VSE system 400 that
`routes behavior events to the objects within the VSE system 400. As
`noted above, a behavior event is the setting of a given behavior state to a
`state value. User code, VSE objects, and the behavior editor 408 send
`out behavior events to the behavior router 412. The behavior router 412
`then sends the events to any objects or other VSE components
`registered for that particular behavior state name.
`
`Id. at 13:51-58. The user code simply interfaces with the VSE system as a client and
`
`not with the VSE objects themselves. In the VSE system, the graphical image is
`
`11
`
`

`
`produced by the VSE system as a whole. See GOOGLE1004 at Figure 4(a)
`
`reproduced below, showing that Client Server 414, which interfaces to user code, is
`
`merely a part of the VSE system as a whole:
`
`
`
`As Walton explains, the user code acts as a client of the VSE system:
`
`The client server 414 is the part of the VSE system 400 that
`connects user code to the VSE system 400. . . . As shown, client server
`414 establishes the connection between a user program and the VSE
`system 400 and passes information between the two as required.
`
`GOOGLE1004 at 21:10-16.
`
`Walton further explains that the universe portion of the VSE system is
`
`responsible for owning all VSE objects and causing drawing of the objects to occur:
`
`As noted above, the universe 420 is the part of the VSE system
`400 where all the VSE objects are kept. The universe 420 is also
`
`12
`
`

`
`responsible for updating all the views of an object when the object is
`changed. The universe 420 also allows objects to be saved and restored
`from disk files and views of the universe 420 to be added and deleted.
`The universe 420 also tells all the views when an object’s appearance
`has changed so that they can redraw the parts that need to be updated.
`The objects within the universe 420 are illustrated by way of example in
`Fig. 4(b). As shown, the universe 420 may include VSE composite
`objects 422, VSE primitive objects 424, view objects 426, VSE
`behavior objects 428, viewport behavior objects 430 and panner objects
`432.
`
`Id. at 21:41-53. Thus, it is the universe in the VSE system that owns and controls the
`
`various VSE objects.
`
`ii. Walton cannot anticipate claims 1-4, 6, 8-11, 13, and 15 because it does
`not disclose a “computer program [further] operable to: . . . delegate
`the production of a graphical image of the external shape to the
`external capabilities”
`
`Each of the claims of the ’633 patent challenged under Ground 1 requires a
`
`computer program that is operable to delegate the production of a graphical image of
`
`an external shape to external capabilities, where the external shape comprises the
`
`external capabilities:
`
`Claims
`Independent Claim 1 and
`Dependent Claims 2-4 and
`6
`
`Limitation
`“A computerized system comprising: . . . a
`computer program . . . further operable to: access an
`external shape . . . , the external shape comprising
`external capabilities; and delegate the production of
`a graphical image of the external shape to the
`external capabilities.”
`
`13
`
`

`
`Claims
`Independent Claim 8 and
`Dependent Claims 9-11, 13,
`and 15
`
`
`Limitation
`“A computer program . . . operable to: access an
`external shape . . . , the external shape comprising
`external capabilities; and delegate the production of
`a graphical image of the external shape to the
`external capabilities.”
`
`
`
`
`Walton does not disclose a computer program that is operable to delegate the
`
`production of a graphical image of an external shape to the external capabilities
`
`where the external shape comprises the external capabilities. Instead, the graphical
`
`objects of Walton may only be drawn by the Visual Software Engineering (“VSE”)
`
`system as a whole. Walton discloses an entire VSE system that draws graphics
`
`objects. The entire VSE system is not an external shape, and Petitioners do not
`
`contend that the entire VSE system is an external shape.
`
`Independent claims 1 and 8 both require that the computer program be
`
`operable to access an external shape, “the external shape comprising external
`
`capabilities.” Moreover, the claims require that the computer program also be
`
`operable to “delegate the production of a graphical image of the external shape to the
`
`external capabilities.” Thus, the claims require that the computer program be
`
`operable to delegate the production of a graphical image of the external shape to
`
`external capabilities that are part of the external shape.
`
`Petitioners contend that a “graphic element” within Walton is an external
`
`shape but refer in their Petition repeatedly to “graphical objects” as being external
`
`14
`
`

`
`shapes. Paper 5 at 22-26. Whichever is Petitioners’ contention, neither is an external
`
`shape as required by the claims.
`
`The graphic element or graphical objects of Walton are not external shapes
`
`because they do not contain external capabilities to which the production of a
`
`graphical image can be delegated. As discussed above, the VSE system operates as a
`
`whole. The user code, asserted by Petitioners to be a computer program, can only
`
`reference the system as a client. As discussed above, Walton’s VSE system controls
`
`the production of graphical images of objects within the VSE system. Thus, there are
`
`no external capabilities in the graphical objects of Walton to which the production of
`
`a graphical image of the external shape could be delegated. The graphical objects of
`
`Walton simply do not work outside the VSE system and thus do not meet the claim
`
`limitations.
`
`Petitioners rely on “behavior elements” disclosed in Walton as providing the
`
`external capabilities required by the claims. But Petitioners’ reliance is misplaced.
`
`Petitioners quote from passages in Walton, such as the following with Petitioners’
`
`quoted language underlined:
`
`As is typical of objects in object-oriented systems, a graphical
`object in accordance with the invention must be able to draw itself if
`asked to do so and to indicate that it has been selected. This may be
`done using little boxes that appear on the object. A whole composite
`
`15
`
`

`
`object may be selected or it may be selected to show that all of its
`children are selected.
`
`GOOGLE1004 at 13:19-25. But the underlined language, when read in context, is
`
`not saying that a VSE object must be able to draw itself outside the context of the
`
`VSE system. That would contradict the description of the VSE system in Walton
`
`discussed in detail above. It is simply saying that from a user’s perspective, a
`
`“graphical object” must be able to draw itself—i.e., when requested via user
`
`interaction, such as by selection of a symbol, the system must be able to draw the
`
`selected graphical object. That interpretation is consistent with the sentence that
`
`follows, which states, “This may be done using little boxes that appear on the object.”
`
`Thus, a user may request that the VSE system draw the graphical object “using little
`
`boxes that appear on the object.” Petitioners’ interpretation of the underlined
`
`sentence as meaning that a VSE object must be able to draw itself without the VSE
`
`system, however, would make the sentence that follows illogical.
`
`Petitioners also quote a portion of the passage block-quoted above that states,
`
`“Once created, the graphical object is responsible for controlling itself, and the
`
`graphics editor 404 simply makes requests of the graphical object.” GOOGLE1004
`
`at 11:8-9. But in context, Walton is not saying that a graphical object can draw itself
`
`or even actually control itself from the perspective of separate code, such as user
`
`16
`
`

`
`code. The paragraph containing that sentence makes clear that it is the graphics
`
`editor (i.e., a component of the VSE) that manages drawing, not a VSE object itself:
`
`The graphics editor 404 creates the graphics for an object, but
`generally that is all. Once created, the graphical object is responsible
`for controlling itself, and the graphics editor 404 simply makes
`requests of the graphical object. During operation, the graphics editor
`404 queries the universe 420 to determine what object it is dealing with
`(i.e., what graphical object is selected), and then asks the object itself
`what requests are legal. The graphics editor 404 then dynamically
`updates its “menu” to reflect the graphical object’s capabilities. The
`graphics editor 404 also manages the work area, or main window,
`where objects are created and manipulated. For this purpose, the
`graphics editor 404 makes sure that all views (when the graphics
`editor 404 supports multiple views) of the objects are always current.
`
`Id. at 11:7-20 (emphases added). This paragraph and Walton in general make clear
`
`that the VSE system is an entire system for managing drawing of graphical objects
`
`and interaction with such objects. Nothing in Walton indicates that user code can
`
`delegate any task or activity to VSE objects.
`
`User code interfaces to the system, but it cannot delegate tasks to VSE objects
`
`within the system. Thus, it is impossible for user code to delegate the production of a
`
`graphical image of any external shape to any of the behavior elements identified by
`
`Petitioners. Behavior elements in Walton cannot be accessed by user code and
`
`cannot act apart from the VSE system to draw a graphical image.
`
`17
`
`

`
`Because both claim 1 and claim 8 and all of their dependent claims require that
`
`the computer program be operable to delegate the production of a graphical image of
`
`an external shape to external capabilities that are part of the external shape,
`
`Petitioners cannot show a reasonable likelihood that one or more of the claims at
`
`issue is invalid because it is anticipated by Walton.
`
`iii. Petitioners’ attempt to introduce obviousness with conclusory
`boilerplate language in their petition and expert declaration is
`improper, unsupported by evidence, and cannot meet their burden to
`justify instituting a trial
`
`The only ground upon which Petitioners challenge the claims based on Walton
`
`is anticipation under 35 U.S.C. § 102. Paper 5 at 4. Nevertheless, certain portions of
`
`the petition and the accompanying expert declaration make boilerplate and
`
`conclusory assertions of obviousness. See Paper 5 at 13-14; GOOGLE1003 at 45-46,
`
`¶ 88. Petitioners did not properly raise a ground of obviousness under 35 U.S.C.
`
`§ 103 based on Walton, and conclusory obviousness allegations cannot give rise to a
`
`reasonable likelihood of unpatentability. Trial should not be instituted on any
`
`obviousness grounds involving Walton. See TRW Automotive US LLC v. Magna
`
`Electronics, Inc., IPR2014-00258, Paper 16, at 15 (June 26, 2014) (denying
`
`institution on obviousness grounds because “TRW’s analysis falls short, as it is based
`
`on mere conclusory statements that cannot support an obviousness rejection.”)
`
`(quotation marks omitted); Toshiba Corp. v. Intellectual Ventures II LLC, IPR2014-
`
`00201, Paper 9, at 17 (May 21, 2014) (denying petition where petitioner’s
`
`18
`
`

`
`obviousness argument and expert declaration were “entirely conclusory”); Wowza
`
`Media Systems, LLC v. Adobe Systems Inc., IPR2013-00054, Paper No. 12, at 15
`
`(April 8, 2013) (denying petition where petitioner offered only “mere conclusory
`
`statements in support of the legal conclusion of obviousness.”).
`
`D. The Petition Does Not Demonstrate a Reasonable Likelihood of
`Prevailing on Proposed Ground 2: Obviousness Under § 103 by Eick
`in view of Inside Visual C++
`
`Ground 2 of the petition proposes that claims 1-4, 6, 8-11, 13, and 15 would
`
`have been obvious under 35 U.S.C. § 103 over U.S. Patent 5,564,048 (hereinafter,
`
`“Eick”) in view of Inside Visual C++, Second Edition: Version 1.5 by David J.
`
`Kruglinski (“Kruglinski”). Paper 5 at 4.
`
`The claims at issue would not have been obvious in view of Eick and
`
`Kruglinksi because the references alone or in combination do not disclose external
`
`shapes. Each of the challenged claims requires an “external shape,” but Petitioners
`
`concede that Eick does not disclose external shapes. Paper 5 at 15. One of ordinary
`
`skill in the art would not have been motivated to combine the teachings of Kruglinski
`
`with the teachings of Eick to fill the deficiencies of Eick because Eick teaches away
`
`from such a combination. For these and the additional reasons stated below, Patent
`
`Owner respectfully requests that Petitioners’ request for trial on Ground 2 be denied.
`
`19
`
`

`
`i. Overview of Eick
`
`Eick is focused on providing a solution to the “difficulties of existing libraries
`
`for programming graphical user interfaces.” GOOGLE1005 at 2:57-59. Eick
`
`discloses a proffered solution in the form of a “library of C++ classes called Vz.” Id.
`
`at 2:64. As Eick explains:
`
`The classes in the library fall into two categories: area classes, which
`specify a kind of area of the display, and functionality classes, which
`specify functionalities which may be added to an o