`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`FACEBOOK, INC.,
`Petitioner
`
`v.
`
`EXPRESS MOBILE, INC.,
`Patent Owner
`
`
`
`Case IPR2021-01224
`U.S. Patent No. 6,546,397 B1
`
`
`PETITIONER’S REPLY
`
`
`
`
`
` 
`
`
`
` 
`
`
`
`

`

`Table of Contents
`
`
`Page
`
`B.
`
`C.
`
`D.
`E.
`
`
`INTRODUCTION .......................................................................................... 1 
`I.
`II. ARGUMENT .................................................................................................. 2 
`A.
`The Proposed Combination Renders Obvious the “Viewable
`Menu” and the Other Limitations of Claim 1[a][1] and 1[a][2]. ......... 2 
`The Proposed Combination Renders Obvious the “Generating a
`Display… Substantially Contemporaneously” and the Other
`Limitations of Claim 1[b]. .................................................................... 5 
`
`The Preview Feature in Bernardo Does Not Require Any
`Additional User Request or Action. ........................................... 5 
`Bernardo Is Not An “HTML Only” System. ............................. 9 
`
`Patent Owner’s “Slow Internet” Argument Also Fails. ........... 14 
`
`The Proposed Combination Renders Obvious the “Storing”
`Limitations of Claim 1[c]. .................................................................. 16 
`The Proposed Combination Renders Obvious Claim 1[d]. ............... 18 
`The Proposed Combination Renders Obvious a “Run Time
`File” and the Other Limitations of Claim 1[e]. .................................. 18 
`
`Patent Owner’s Arguments Attack Reynolds Individually
`and Ignore the Proposed Combination With Meyer. ............... 19 
`Patent Owner’s Reliance on BigCommerce Is Misplaced. ...... 21 
`Patent Owner Has Failed to Rebut the Compelling
`Motivation to Combine Reynolds and Meyer.......................... 22 
`Patent Owner’s Arguments About Ground 2 Should Be
`Rejected. ............................................................................................. 24 
`Patent Owner’s Remaining Arguments Are Meritless. ...................... 24 
`
`The Number of Prior Art References ....................................... 24 
`
`Patent Owner’s Baseless Attacks on Petitioner’s Expert ........ 25 
`III. CONCLUSION ............................................................................................. 26 
`
`
`
`
`F.
`
`G.
`
`
`
`
`
`-i-
`
`
`
`

`

`
`
`I.
`
`
`
`
`
`INTRODUCTION
`Patent Owner relies on a number of recurring flawed arguments, most notably
`
`attacking the prior art references individually and ignoring (and in some cases
`
`mischaracterizing) the proposed combination. Patent Owner’s primary argument is
`
`that Bernardo’s preview
`
`feature does not disclose
`
`the “substantially
`
`contemporaneously” limitation because, according to Patent Owner, the user must
`
`press a button or perform some additional act to cause the preview display. But
`
`Bernardo has no such requirement and fully discloses the claim limitation. Patent
`
`Owner’s arguments about motivations to combine make no serious attempt to rebut
`
`the compelling motivations to combine set forth in the Petition, and Patent Owner
`
`offers no evidence of secondary considerations.
`
`There are no claim construction issues for the Board to resolve. Patent Owner
`
`generically asserts that Petitioner did not apply the correct constructions, but Patent
`
`Owner does not identify any flaw in the constructions Petitioner applied – most of
`
`which were proposed by Patent Owner in prior or pending litigations. The Petition
`
`identified the various constructions that had been proposed and explained why each
`
`of them was disclosed by the prior art. Patent Owner proposes no alternative
`
`constructions. For the reasons expressed below and in the Petition, claim 1 should
`
`be found unpatentable based on the instituted grounds.
`
` 
`
`
`
`1
`
` 
`
`

`

`
`
`
`
`II. ARGUMENT
`A. The Proposed Combination Renders Obvious the “Viewable
`Menu” and the Other Limitations of Claim 1[a][1] and 1[a][2].
`Patent Owner attacks the proposed combination of Reynolds, Bernardo, and
`
`
`
`Meyer by arguing that the viewable menu in Bernardo cannot be incorporated into
`
`Reynolds. (Response at 25.) This is because, according to Patent Owner, Bernardo
`
`is “a server-side tool that renders the completed web pages as HTML before
`
`transmission to a browser,” and thus, “Bernardo’s tool cannot be an applet.”
`
`(Response at 25 (bold and italics in original).) As explained below for the
`
`“substantially contemporaneously” limitation, Patent Owner’s characterization of
`
`Bernardo as an “HTML-only” system that cannot use an applet is wrong.
`
`But Patent Owner’s characterization of Bernardo is irrelevant to claim 1[a]
`
`because Patent Owner attacks Bernardo individually and ignores the proposed
`
`combination with Reynolds and Meyer. Federal Circuit law is clear that “[a] finding
`
`of obviousness… cannot be overcome by attacking references individually where
`
`the rejection is based upon the teachings of a combination of references.” Bradium
`
`Techs. LLC v. Iancu, 923 F.3d 1032, 1050 (Fed. Cir. 2019) (citation omitted). The
`
`proposed combination does not rely on the technical implementation of Bernardo’s
`
`viewable menus, such as how Bernardo internally organizes and uses templates. It
`
`instead proposes adapting the ibook authoring tool 86 of Reynolds to present a
`
`viewable menu, based on the user interface examples in Bernardo, with a user
` 
`
`
`
`2
`
` 
`
`

`

`
`
`
`
`
`
`
`selectable panel of settings describing elements on a website. (Petition at 42-45;
`
`EX1002, ¶¶81-86; EX1030, ¶¶20-22.) And under the further combination with
`
`Meyer, the authoring tool 86 would have been implemented as a Java applet.
`
`(Petition at 48; EX1002, ¶93.) Patent Owner does not contend that a Java applet
`
`could not use conventional user interface tools such as drop down or pop-up menus,
`
`option lists, radio button selectors, or any of the other common user interface features
`
`disclosed in Bernardo – and it was common knowledge that they did. (EX1030, ¶22;
`
`EX1002, ¶73.) It is thus irrelevant how Bernardo technically implements the
`
`claimed viewable menus – whether it uses HTML, Java, or some other technology
`
`has no bearing on the proposed obviousness combination. (EX1030, ¶¶21-22.)
`
`Patent Owner’s arguments also assume that the proposed combination
`
`requires Bernardo’s technical and internal implementation of viewable menus to be
`
`physically combined into the Reynolds ibook system. (Response, e.g., at 29 (“For
`
`Reynolds to integrate the template-and-menu system of Bernardo would… require
`
`gutting the entire system of Reynolds….”).) But it does not, and Patent Owner’s
`
`repeated suggestions to the contrary violate the oft-cited principle that “‘[t]he test
`
`for obviousness is not whether the features of a secondary reference may be bodily
`
`incorporated into the structure of the primary reference,’” but rather, “whether ‘a
`
`skilled artisan would have been motivated to combine the teachings of the prior art
`
`references to achieve the claimed invention.” Allied Erecting & Dismantling Co.,
`
` 
`
`
`
`3
`
` 
`
`

`

`
`
`
`
`
`
`
`Inc. v. Genesis Attachments, LLC, 825 F.3d 1373, 1381 (Fed. Cir. 2016) (citations
`
`omitted). The proposed combination does not depend on bodily incorporating the
`
`entire template-based system of Bernardo into Reynolds. (EX1030, ¶22.)
`
`Patent Owner next attempts to draw superficial distinctions between Bernardo
`
`and Reynolds, arguing that it would have been improper to add viewable menus
`
`offering limited or predefined choices to Reynolds, which Patent Owner calls a
`
`“free-form ibook design tool.” (Response at 30.) But Patent Owner identifies
`
`nothing in Reynolds that prohibits or discourages viewable menus, or that limits the
`
`system only to “free-form” text entry. The Petition explained that, as has been
`
`known since at least the 1980s, viewable menus provided the distinct benefit of
`
`allowing a user to make selections without inputting characters on a keyboard – a
`
`benefit that would have directly inured to the system of Reynolds. (Petition at 45-
`
`46; EX1002, ¶¶87-88; EX1030, ¶¶47-48.) This is why “free-form” text entry user
`
`interfaces of the past, such as the “command line” interfaces of DOS and UNIX,
`
`have been supplanted by graphical user interfaces with viewable menus such as
`
`Microsoft Windows and Macintosh OS. The incorporation of viewable menus has
`
`been seen even with applications that also rely on free-form text entry, such as source
`
`code and software development tools. (EX1030, ¶48.)
`
` 
`
`
`
`4
`
` 
`
`

`

`
`
`
`
`
`
`
`B.
`
`The Proposed Combination Renders Obvious the “Generating a
`Display… Substantially Contemporaneously” and the Other
`Limitations of Claim 1[b].
`Most of Patent Owner’s arguments
`
`focus on
`
`the “substantially
`
`contemporaneously” feature of claim 1[b]. As explained in the Petition, Bernardo
`
`discloses a preview feature that “permits authorized content creators to preview
`
`proposed content as it is being created by rendering pages on-the-fly.” (Petition at
`
`52 (quoting Bernardo, 4:19-21) (emphasis in Petition); see also id. (quoting
`
`Bernardo, 10:5-13).) The Petition further explained that the “on-the-fly” rendering
`
`in Bernardo discloses generation of a display “substantially contemporaneously”
`
`with user selection. (Petition at 52-53; EX1002, ¶¶97-98.) Patent Owner presents
`
`various arguments in response, which Petitioner will address below.
`
`
`
`The Preview Feature in Bernardo Does Not Require Any
`Additional User Request or Action.
`Patent Owner first argues Bernardo requires that the user take some additional
`
`action to generate a preview, such as clicking on a link or pressing a button.
`
`(Response, e.g., at 13-14, 35-37, 40-41.) But Patent Owner cannot identify a single
`
`statement in Bernardo that suggests, let alone actually discloses, any additional user
`
`action required to cause display of a preview.
`
`As noted, Bernardo explains that “authorized content creators to preview
`
`proposed content as it is being created by rendering pages on-the-fly.” (Bernardo,
`
`4:19-21.) Bernardo describes the feature as directly displaying a preview in response
` 
`
`5
`
` 
`
`
`
`

`

`
`
`
`
`
`
`
`to user selection: “A preview function may enable the user to view the Web page as
`
`it is created. For example as various options are selected, a preview of the
`
`option(s) selected may be displayed for a user to observe.” (Bernardo, 10:6-9.)
`
`This latter sentence does not suggest, let alone disclose, any user step occurring
`
`between “various options [being] selected,” and “a preview of the option(s) selected
`
`[being] displayed.” (Id.) Patent Owner’s argument that the preview feature requires
`
`an intermediate or additional user action is based on little more than speculation.
`
`In fact, Bernardo discloses dozens of instances in which express user actions
`
`and selections are required by other (non-preview) features, such as approving or
`
`saving a completed web page.1 If the preview feature actually required further user
`
`
`1 (See Bernardo, e.g., 7:27-52 (feature/option selection by “pointing a cursor at the
`selection and clicking on it”), 8:28-35 (choosing whether to create new site or update
`existing site “is made, for example, by using a computer mouse and clicking on one
`of the radio buttons adjacent to the desired choice…”), 9:51-54 (“…a list of options
`to be selected using a radio button selector, a text entry box, or other suitable
`graphical selection interface.”), 14:39-41 (“FIG. 14 shows a page from the built-in
`site creator guide, which can be accessed, for example, by clicking a button on the
`view.”), 16:28-30 (“Users can see the description during Site Configuration step
`when they click the button for view area descriptions.”), 18:30-31 (“… click
`Contributor’s Menu, then click Contributor’s Menu again on the resulting page.”),
`18:32-33 (“Click Upload a file…”), 18:42 (“Click the Submit button to save the
`page…”), 18:43 & 22:42-43 (“…. Click the Go to Contributor’s menu link…”),
`22:25 (“Click the Edit/Approve This Page link.”), 22:31 (“… click Submit.”), 22:46-
`47 (“Click the link to Compose…”), 22:49-50 (“After completing the page, select
`Process, then click Submit.”), 23:10 (“Click the Edit/Approve This Page link.”),
`23:13 (“… select Yes to Republish the Page, then click Submit.”), 23:39-48 (“…
`click Edit/Approve This Page,” “Select an Approver, then click Submit.”), 23:62-63
`(“… click Subforms.”).)
` 
`
`
`
`6
`
` 
`
`

`

`
`
`
`
`
`
`
`action such as clicking a button or link, as Patent Owner contends, an ordinarily
`
`skilled artisan would have expected Bernardo to state that explicitly – as he did for
`
`so many other features. (EX1030, ¶30.) But Bernardo did not disclose any such
`
`requirement for the preview feature.
`
`It also makes perfect sense why Bernardo does not require user action to
`
`generate a preview. The purpose of the preview function is to allow “authorized
`
`content creators to preview proposed content as it is being created by rendering pages
`
`on-the-fly.” (Bernardo, 4:19-21.) The preview feature allows a content creator to
`
`see what a page will look like before the creator had completed and approved the
`
`page, thus allowing the creator to make further changes if needed. (Bernardo, 8:60-
`
`62 (“Once selections have been made, the user can preview the design and then make
`
`changes as desired.”).) But once the content creator finishes the page, Bernardo
`
`discloses explicit user action (such as clicking a “Submit” button) to approve the
`
`completed page for publication. (Bernardo, e.g., 18:42 (“Click the Submit button to
`
`save the page.”), 22:48-49 (“After completing the page, select Process, then click
`
`Submit.”), 23:13-14 (“After the desired changes have been made, select Yes to
`
`Republish, then click Submit.”), 23:46-48 (“After reviewing and/or editing the
`
`content, scroll down the page to the Approval Section. Select an Approver Action,
`
`then click submit.”).) It is thus entirely consistent with the purpose of the preview
`
`feature – to enable the content creator to review the page before its approval – to
`
` 
`
`
`
`7
`
` 
`
`

`

`
`
`
`
`
`
`
`produce the “on-the-fly” previews automatically without additional user action, but
`
`then rely on user action to save and/or approve the completed web page.
`
`And even if Patent Owner had evidence that the preview feature in Bernardo
`
`requires additional user action (which it does not), this would still not distinguish the
`
`prior art from claim 1[b]. Nothing in the claim language or any of the proposed
`
`constructions of “substantially contemporaneously” requires that the display be
`
`generated automatically or without any additional user action. The proposed
`
`constructions merely require that the display occur “immediately after” or “at the
`
`same time from a human perspective,” as the claimed user selection. (Petition at 17
`
`& 53.) A preview could be generated “substantially contemporaneously,” in
`
`response to additional user action, provided the user action and display occurred
`
`sufficiently quickly to satisfy the claim. (EX1030, ¶31.)
`
`For example, suppose Bernardo did require that the user press a “Preview”
`
`button to request a preview display. It would have been obvious that the user could
`
`have clicked the “Preview” button immediately after selecting an option affecting
`
`the appearance of the web page, thus resulting in the preview display being produced
`
`“substantially contemporaneously” with the user selection. (EX1030, ¶31.) As
`
`the web site creator became more familiar with the user interface features of the
`
`Bernardo system, their speed at activating a “Preview” feature would obviously have
`
`increased. For example, anyone who had quickly pressed the “Save” button in a
`
` 
`
`
`
`8
`
` 
`
`

`

`
`
`
`
`
`
`
`word processing program after making a change to a document, or had quickly
`
`pressed “Refresh” on a web browser or email program to repeatedly request updated
`
`information, would have appreciated that users can activate user interface controls
`
`very quickly once they become familiar with them. (Id.) Further user action to
`
`generate a preview, therefore, would not prevent Bernardo from satisfying the
`
`“substantially contemporaneously” claim limitation.
`
`
`Bernardo Is Not An “HTML Only” System.
`Patent Owner, unable to point to any specific disclosure in Bernardo of user
`
`action required to generate a preview, contends that such a requirement is an inherent
`
`characteristic of the system itself. Patent Owner describes Bernardo as an “HTML
`
`only” system that “is not capable of performing the type of real-time updates
`
`Petitioner suggests.” (Response at 37.) “An HTML-only system is static,”
`
`according to Patent Owner, “meaning that it does not do anything without a user
`
`taking an action, such as clicking on a button or a hyperlink.” (Id.) The gist of
`
`Patent Owner’s argument is that because Bernardo only supports primitive HTML
`
`web pages and does not support interactive technologies such as Java, according to
`
`Patent Owner, the system must require the user to press a button or take some other
`
`specific action to cause a preview to appear.
`
`At the outset, Petitioner notes that this argument – again – rests on attacking
`
`Bernardo individually and ignoring the proposed combination with Reynolds and
`
` 
`
`
`
`9
`
` 
`
`

`

`
`
`
`
`
`
`
`Meyer. Under the proposed combination, as explained in the Petition, the preview
`
`feature would have been implemented within a Java applet implementation of
`
`Reynolds’ authoring tool 86. (Petition at 54-55, 48-49.) Bernardo’s particular
`
`technical implementation of the preview feature is thus not relevant.
`
`In any case, Patent Owner’s assumption that Bernardo discloses an “HTML
`
`only” system that cannot use well-known interactive web page technologies, such as
`
`Java applets, is without basis. Nothing in Bernardo suggests that Java programs such
`
`as applets cannot be used to generate real-time web page displays. (EX1030, ¶25.)
`
`It is undisputed that Java applets and their use in creating interactive web pages were
`
`well-known to ordinarily skilled artisans. (EX1002, e.g., ¶¶49, 68; EX1030, ¶25.)
`
`Patent Owner’s expert testified that he considered use of Java and Java applets to be
`
`“fundamental knowledge” that an ordinarily skilled artisan would have possessed.
`
`(EX1031, 17:24-18:24.) He explained that “Java was a very popular programming
`
`language, especially in the late ’90s and they [a POSITA] would have had
`
`knowledge of Java and its role in web developments.” (EX1031, 18:10-14.) Patent
`
`Owner presents no evidence that an ordinarily skilled artisan would have somehow
`
`been precluded from using this “very popular programming language” in
`
`implementing the preview feature. (EX1030, ¶25.) As the Federal Circuit has long
`
`held, “[a] patent need not teach, and preferably omits, what is well known in the art.”
`
`Spectra-Physics, Inc. v. Coherent, Inc., 827 F.2d 1524, 1534 (Fed. Cir. 1987).
`
` 
`
`
`
`10
`
` 
`
`

`

`
`
`
`
`
`
`
`But Bernardo in fact does teach that Java can be used alongside HTML in
`
`creating web pages. (EX1030, ¶25.) This is shown in Figure 25:
`
`
`(Bernardo, Fig. 25 (highlighting added).) Figure 25 shows an overall block diagram
`
`
`
`including an HTTP server, which is part of the web server in Bernardo and is
`
`responsible for receiving requests from and sending requested objects to the web
`
`browser. (Bernardo, 5:62-67, 6:8-10, 9:26-28.) Figure 25 also shows HTTP server
`
`connected to a database that includes at least HTML files, GIF (Graphic Interchange
`
`Format) files, and JAVA files. These types of files contain information that could
`
`be provided as part of a web page transmitted to a browser. (EX1030, ¶26.) Figure
`
`25 thus undermines Patent Owner’s contention that the system of Bernardo cannot
`
`use Java applets with web pages on the user computer.
`
` 
`
`
`
`11
`
` 
`
`

`

`
`
`
`
`
`
`
`Patent Owner relies heavily on Bernardo’s “HTML translator” which,
`
`according to Patent Owner, would have prevented the user’s web browser from
`
`receiving any Java applets. (Response at 25-26.) But the HTML translator in
`
`Bernardo has nothing to do with Java applets or any other web objects. The HTML
`
`translator instead converts data that exists independently of and outside the context
`
`of web pages – such as a user directory entry in a database – to HTML format for
`
`display on a webpage. (E.g., EX1030, ¶28; Bernardo, 5:54-59 (“Preferably, non-
`
`HTML database 116 stores one or more non-HTML objects 118a-118n … and a user
`
`directory 120. User directory 120 includes one or more user objects 122a-122n.”),
`
`6:2-7.) An ordinarily skilled artisan would not have considered a Java applet to be
`
`a “non-HTML” object that would have been passed through the HTML translator.
`
`(EX1030, ¶¶28-29.) This is confirmed by comparing Figure 1, which shows a more
`
`detailed view of the system shown in Figure 25, with Figure 25 itself:
`
` 
`
`
`
`12
`
` 
`
`

`

`
`
`
`
`
`
`
`(Bernardo, Fig. 1 (highlighting added).)
`
`
`
`
`
`(Bernardo, Fig. 25 (highlighting added).) Figure 1 shown on the top above shows
`
`HTTP server module 130, which corresponds to the HTTP server of Figure 25.
` 
`
`
`
`13
`
` 
`
`

`

`
`
`
`
`
`
`
`Figure 1 also shows HTML database 148, which is a more detailed view of the
`
`database from Figure 25 that stores HTML, GIF, and JAVA files. Both databases
`
`feed into HTTP server (shown using the red lines). Critically, Figure 1 also shows
`
`HTML translator 144 that sits outside of – and behind – HTTP server module 130.
`
`Bernardo explains that HTML translator 144 translates non-HTML data from an
`
`entirely separate database – non-HTML database 116 – for delivery to the client.
`
`(Bernardo, 5:51-6:7.) Figure 1 confirms that HTML database 148, which is simply
`
`a more detailed version of the database of Figure 25, does not pass information
`
`through HTML translator 144. It is thus clear from Bernardo that JAVA files in the
`
`database – just like the GIF and HTML files in the database – would not qualify as
`
`“non-HTML” objects that must pass through the HTML translator before
`
`transmission to the user computer in Bernardo.
`
`
`Patent Owner’s “Slow Internet” Argument Also Fails.
`Patent Owner further argues that the preview in Bernardo could not have been
`
`provided “substantially contemporaneously” because of the allegedly slow speed
`
`of the Internet at the time of the invention. (Response at 38-49.) Patent Owner
`
`contends that “in the late 1990s, [the] Internet was still in its infancy and several
`
`orders of magnitude slower than what we experience nowadays.” (EX2009, ¶50.)
`
`This argument fails for at least three reasons. First, it assumes that Bernardo
`
`only contemplates an “HTML only” implementation, and as such, any preview
`
` 
`
`
`
`14
`
` 
`
`

`

`
`
`
`
`
`
`
`would have required transmission of a new page display from the server over a
`
`network. As explained previously, this assumption is incorrect, and Bernardo does
`
`not preclude a Java applet at the user computer producing on-the-fly previews.
`
`Second, even if the preview feature in Bernardo required that the browser
`
`request and receive a response from the server, Patent Owner’s arguments
`
`incorrectly assume that the browser and server must be connected over the Internet.
`
`(EX2009, ¶50.) But Reynolds and Bernardo confirm that the browser and server can
`
`instead be connected through a local area network (LAN), such as an intranet.
`
`(Reynolds, 2:61-64, 1:26-29; Bernardo, 5:59-61.) A local area network or intranet
`
`would have provided communication performance far exceeding the Internet.
`
`(EX1030, ¶33.) Bernardo’s preview generation and display would thus have
`
`occurred “substantially contemporaneously” with the selection of settings,
`
`because the server in a local area network or intranet would have nearly
`
`instantaneously received each selection change from the user and promptly
`
`responded by transmitting back a new page for display in the browser. (Id.)
`
`And finally, even if the Internet were used, Bernardo would still disclose the
`
`claim limitation. Patent Owner’s expert claims that the delay using the Internet
`
`could be “potentially several seconds to minutes” (EX2009, ¶50), but these claims
`
`are overblown. The Internet of today is certainly faster than that of the late 1990s,
`
`but Internet latency and bandwidth was sufficient in the late 1990s for Bernardo’s
`
` 
`
`
`
`15
`
` 
`
`

`

`
`
`
`
`
`
`
`display generation operations to require on the order of one second or considerably
`
`less – and thus would have been “substantially contemporaneous” with the
`
`selection of settings. (EX1030, ¶34.)
`
`C. The Proposed Combination Renders Obvious the “Storing”
`Limitations of Claim 1[c].
`Claim 1[c] recites “storing information representative of said one or more
`
`user selected settings in a database.” Patent Owner’s arguments feign ignorance
`
`as to the basis of the proposed combination for this limitation, but it is Patent
`
`Owner’s arguments that are difficult to follow. (Response at 42-43.) Patent Owner
`
`appears to fault Petitioner for not explaining why it would have been obvious to
`
`combine Reynolds and Witkowski with Bernardo for claim 1[c], but the proposed
`
`combination does not rely on Bernardo for this claim limitation.
`
`Patent Owner’s attempt to overcomplicate the proposed combination should
`
`be rejected. As explained for claim 1[a], the Petition relied on Bernardo to adapt the
`
`ibook authoring tool 86 of Reynolds to accept user input through a viewable menu,
`
`through the web browser 82 in Reynolds. (Petition at 42.) The “user selected
`
`settings describing elements of a website,” for purposes of claim 1[c], are therefore
`
`the settings received by the system of Reynolds as described for claim 1[a]. (Petition
`
`at 56.) And those one or more user selected settings are, under the proposed
`
`combination, stored in the database of Reynolds. (Petition at 56-57.) Patent Owner
`
`does not dispute that Reynolds discloses “a database,” as claimed, but the Petition
` 
`16
` 
`
`
`
`

`

`
`
`
`
`
`
`
`nevertheless also cited to Witkowski to account for a narrower definition of
`
`“database” from a pending litigation that Patent Owner does not appear to advance
`
`in this IPR. (Petition at 16, 57-59.)
`
`Patent Owner puzzlingly argues that the proposed combination does not teach
`
`“user selected settings describing elements of a website,” but the Petition made
`
`clear that the user selections were the same selections that the user made, discussed
`
`in connection with claim 1[a], using the ibook authoring tool 86 of Reynolds adapted
`
`to present a viewable menu based on the teachings of Bernardo. (Petition at 42, 56.)
`
`As explained, Patent Owner’s arguments about claim 1[a] rest on improperly
`
`attacking Bernardo individually. Patent Owner’s reliance on those flawed
`
`arguments for claim 1[c] should be rejected for the same reasons.
`
`For the same reasons, there is no merit to Patent Owner’s argument that
`
`Petitioner’s analysis “does not address a fundamental issue: what the ‘settings’
`
`Petitioner glosses over would be, or how exactly they would be stored in a database.”
`
`(Response at 43.) The Petition identified the settings that would have been stored in
`
`the database of Reynolds. (Petition at 56-57.) The Petition went on to explain that
`
`Reynolds itself discloses the use of conventional relational databases, which were
`
`well-known and widely-available. (Petition at 58-59.)
`
` 
`
`
`
`17
`
` 
`
`

`

`
`
`
`
`
`
`
`D. The Proposed Combination Renders Obvious Claim 1[d].
`Patent Owner’s arguments about claim 1[d] appear to rely on its flawed
`
`arguments about claim 1[a] and 1[c] discussed above. As with claim 1[c], Patent
`
`Owner mischaracterizes the proposed combination. The proposed combination
`
`generates a website by retrieving “information representative of said one or more
`
`user selected settings stored in said database,” which corresponds to the
`
`information stored in the Reynolds database as described for claim 1[c]. (Petition at
`
`63 (“Accordingly, as noted, Reynolds’ navigation tool 84 thus generates an ibook
`
`website by retrieving passages from Web pages database 76—where the retrieved
`
`passages include content representing selections made by the user—and presents the
`
`website via the browser.”).) The proposed combination fully discloses claim 1[d].
`
`E.
`
`The Proposed Combination Renders Obvious a “Run Time File”
`and the Other Limitations of Claim 1[e].
`The Petition explained that, under the proposed combination of Reynolds with
`
`Meyer, navigation tool 84 of Reynolds would have been implemented as a Java
`
`applet. (Petition at 66-69.) Patent Owner does not dispute that navigation tool 84,
`
`when implemented as a Java applet, actually discloses “at least one run time file.”
`
`The Petition further explained that the run time file would have generated “virtual
`
`machine commands for the display of at least a portion of said one or more web
`
`pages,” i.e., instructions of the Java applet implementing navigation tool 84, which
`
`are executed by the Java Virtual Machine (JVM) on the client computer. (Petition
` 
`
`
`
`18
`
` 
`
`

`

`
`
`
`
`
`
`
`at 66; see also id. at 67-68 (“The applet, in turn, would utilize information in the
`
`form of passages stored in and retrieved from ibook Web pages database 76… to
`
`generate and issue instructions to the Java Virtual Machine (JVM)… for displaying
`
`web pages built from those passages in the browser….”).) Patent Owner
`
`nevertheless presents a series of arguments about the “run time file” limitation,
`
`which Petitioner will address below.
`
`
`
`Patent Owner’s Arguments Attack Reynolds Individually
`and Ignore the Proposed Combination With Meyer.
`Patent Owner complains that that Reynolds by itself does not disclose a
`
`“virtual machine,” “virtual machine commands,” or a “run time file,” as claimed.
`
`(Response at 46-47.) These arguments again fail because they attack Reynolds
`
`individually. See Bradium Techs. LLC, 923 F.3d at 1050.
`
`Patent Owner next points to Reynolds’ disclosure of the standard Internet file
`
`transfer protocol (FTP), to suggest the combination with Meyer is somehow
`
`improper. (Response at 47.) But Reynolds only identifies using FTP to download
`
`client plug-ins 80 as one of a number of “standard techniques” for downloading.
`
`(Reynolds, 5:33-35 (“Downloading of client plug-ins 80 can be accomplished using
`
`standard techniques, such as the standard Internet file transfer protocol (FTP).”).)
`
`FTP is irrelevant to the proposed combination because, under the combination with
`
`Meyer, the functionality of navigation tool 84 would not have been provided by
`
`client plug-ins 80, but by a Java applet as discussed. (Petition at 68-69, 50-51.)
` 
`19
` 
`
`
`
`

`

`
`
`
`
`
`
`
`Meyer explains that “[a]pplets are mini-applications written in the Java language
`
`that are downloaded over the Internet on the fly, and executed on the user’s local
`
`computer.” (Petition at 27 (quoting Meyer, p.0016); EX1002, ¶61.) The
`
`downloading of the applet, under the proposed combination, would therefore have
`
`been accomplished using the Java applet download functionality that was built into
`
`the web browser and discussed in Meyer. (EX1030, ¶¶40-41; Meyer, p.0016.) The
`
`downloading of the applet, therefore, would have been accomplished using the
`
`Hypertext Transport Protocol (HTTP), another well-known protocol. (EX2009, ¶63;
`
`EX1030, ¶¶40-41, 49.)
`
`Reynolds confirms that navigation tool 84 (one of client plug-ins 80) is
`
`downloaded from the same ibook server 56 that provides ibook webpages to users.
`
`(Reynolds, Fig. 3 (showing client plug-ins 80 stored at ibook server 56), 5:3-8, 5:28-
`
`37; see also id., 2:57-58 (“Web server computers that support one or more ibooks
`
`are called ibook servers.”).) Navigation tool 84 in Reynolds would therefore have
`
`been downloaded when the browser is pointed to a web page. Under the proposed
`
`combination in which navigation tool 84 is implemented as a Java applet, this
`
`downloading would have occurred using the Hypertext Transport Protocol (HTTP),
`
`another well-known protocol. (EX1030, ¶¶40-41, 49; EX2009, ¶63.)
`
` 
`
`
`
`20
`
` 
`
`

`

`
`
`
`
`
`
`
`
`Patent Owner’s Reliance on BigCommerce Is Misplaced.
`Patent Owner next relies on the PTAB’s non-precedential decision denying
`
`institution in BigCommerce, Inc. v. Express Mobile, Inc., IPR2018-00750 (Paper 10)
`
`(PTAB August 30, 2018), an IPR petition filed by an unrelated