`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`FACEBOOK, INC.,
`Petitioner
`
`v.
`
`EXPRESS MOBILE, INC.,
`Patent Owner
`
`
`
`Case IPR2021-01456
`U.S. Patent No. 9,471,287 B2
`
`
`PETITIONER’S REPLY IN SUPPORT OF
`PETITION FOR INTER PARTES REVIEW
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Table of Contents
`
`
`Page
`
`
`INTRODUCTION .......................................................................................... 1
`I.
`II. ARGUMENT .................................................................................................. 2
`A.
`The Prior Art Combination Discloses an “Application” With
`“Device-Independent Code” ................................................................ 2
`
`The Patent Specification Expressly Confirms that a Java
`Application Is Device-Independent Code. ................................. 2
`The Prior Art Further Confirms that Java Applications
`Are “Device-Independent Code.” .............................................. 5
`Patent Owner’s Tortured Reading of the Litigation
`Construction of “Device-Independent Code” Is
`Unavailing and Would Render the Claims Inoperable. ............. 6
`The Prior Art Combination Discloses a “Player.” ............................. 12
`The Prior Art Combination Discloses an Authoring Tool
`Configured to “Produce” a Player. ..................................................... 16
`Patent Owner’s Motivation to Combine Arguments Fail. ................. 19
`
`Patent Owner’s Superficial “Client-Side” / “Server-Side”
`Arguments Ignore Express Teachings in Anderson. ............... 19
`Anderson and Ambrose-Haynes Are Properly
`Combinable. ............................................................................. 23
`Patent Owner’s Generalized Attacks on the Prior Art
`Combination Are Without Merit. ............................................. 26
`III. CONCLUSION ............................................................................................. 27
`
`B.
`C.
`
`D.
`
`
`
`
`
`
`
`
`
`
`
`
`
`-i-
`
`
`
`
`
`
`
`I.
`
`
`
`
`
`INTRODUCTION
`Patent Owner’s Response rests on a series of arguments that are directly
`
`contradicted by the intrinsic record and unsupported by the evidence. Patent Owner
`
`primarily argues that a Java application does not qualify as an “Application”
`
`because it does not have “device-independent code,” a remarkable yet
`
`demonstrably false assertion given that the device-independent nature of Java code
`
`is a key reason for Java’s existence. Patent Owner ignores statements in its own
`
`patent specification expressly identifying Java programming as device-independent
`
`code, consistent with the prior art and the basic knowledge of a skilled artisan.
`
`Patent Owner also contends that the Java Virtual Machine (JVM) does not
`
`qualify as a “Player” because the JVM is referred to as a “virtual machine,” but
`
`Patent Owner does not explain how this has any bearing on the challenged claims.
`
`Patent Owner has consistently construed “Player” as “software code that facilitates
`
`the execution of an application on a device,” and the Response does not appear to
`
`depart from that position. The fact that the JVM is called a “virtual machine” has
`
`no bearing on whether it qualifies as a Player as claimed. Patent Owner also recycles
`
`its pre-institution argument that the authoring tool in Anderson does not “produce”
`
`a Player, which the Board properly rejected.
`
`With respect to motivations to combine, Patent Owner mischaracterizes the
`
`proposed combination as using client-side Java applets, but the Java application
`
`
`
`
`
`1
`
`
`
`
`
`
`
`
`
`
`
`
`described in Anderson instead relies on server-side Java programs (servlets)
`
`executing on the same computer as the web browser, consistent with known software
`
`development techniques. Patent Owner’s arguments do not overcome the clear
`
`motivations to combine set forth in the Petition. For the reasons set forth below and
`
`in the Petition, the Board should find the challenged claims unpatentable.
`
`II. ARGUMENT
`A. The Prior Art Combination Discloses an “Application” With
`“Device-Independent Code”
`The challenged claims recite nothing more than standard techniques for
`
`accessing a web service through a Java application.1 Patent Owner nevertheless
`
`argues that the Java application disclosed in Anderson is not an “Application” as
`
`claimed because it is not “device-independent code.” This argument suffers from
`
`multiple independent flaws and should be rejected.
`
`
`
`The Patent Specification Expressly Confirms that a Java
`Application Is Device-Independent Code.
`Patent Owner’s arguments cannot be reconciled with the specification of its
`
`own patent, which describes “device-independent code” and then expressly
`
`identifies a Java application as an example of such code. (Petition, 60-61; EX1002,
`
`
`1 Patent Owner argues that the alleged invention was developed to meet the needs
`of mobile devices. (Response, 9-12.) These arguments, even if true, are irrelevant
`as the challenged claims neither recite a mobile device nor are limited to a mobile
`device. (EX1021, ¶¶8-9.) Patent Owner does not contend otherwise.
`
`2
`
`
`
`
`
`
`
`
`
`
`
`
`
`¶139.) First, the specification distinguishes an “Application” from a “Player” by
`
`explaining that the former is a device-independent program:
`
`In one embodiment, system 100 provides permits a user of authoring
`platform 110 to provide instructions to each of the plurality of devices
`130 in the form of a device- or device-platform specific instructions for
`processor 135 of the device, referred to herein and without limitation as
`a “Player,” and a device-independent program, referred to herein and
`without limitation as an “Application”[.]
`
`(’287, 5:13-19.)2 The specification then goes on to explain that a Java program
`
`provides an example of a device-independent “Application”:
`
`Thus, for example and without limitation, in one embodiment, the
`Player transforms device-independent instructions of the Application
`into device-specific instructions that are executable by device 130.
`Thus, by way of example and without limitation, the Application may
`include Java programming for generating a display on screen 137, and
`the Player may interpret the Java and instruct processor 135 to produce
`the display according to the Application for execution on a specific
`device 130 according to the device platform.
`
`(’287, 5:60-6:1.) The passages quoted above conclusively establish that a Java
`
`program is an example of a device-independent Application. (EX1021, ¶¶14-17.)
`
`Patent Owner attempts to dismiss the specification’s explicit mention of Java
`
`by arguing that while an application generally may include Java programming, the
`
`
`2 Except as otherwise noted, all emphasis was added by Petitioner.
`
`3
`
`
`
`
`
`
`
`
`
`
`
`
`
`specification goes on to teach converting a Java application into Portable Document
`
`Language (PDL) format that lacks dependencies on the original Java programming
`
`language. (Response, 15-16.) But the specification does not describe a Java
`
`program as merely a generic application, but as an example of an “Application” –
`
`expressly referencing the patent’s own specialized description of an “Application”
`
`(with capital “A”) as a device-independent program. (’287, 5:60-6:1, 5:13-19.)
`
`The passage quoted above drives this point home further by explaining that
`
`the Java instructions of an Application are interpreted by the Player. (’287, 5:63-6:1
`
`(“…the Application may include Java programming for generating a display on
`
`screen 137, and the Player may interpret the Java and instruct processor 135 to
`
`produce the display according to the Application for execution on a specific device
`
`130 according to the device platform.”).) The fact that a Java program must be
`
`interpreted by “the Player” further confirms that the program is “device-
`
`independent code.” As explained in the previous sentence in that same passage,
`
`“the Player transforms device-independent instructions of the Application into
`
`device-specific instructions that are executable by device 130.” (’287, 5:60-63.) If
`
`Java programming was device-dependent code, as Patent Owner contends, it would
`
`not need the Player to transform its “device-independent instructions… into device-
`
`specific instructions.” (EX1021, ¶16.) The specification thus leaves no doubt that
`
`a Java program is “device-independent code.”
`
`
`
`
`
`4
`
`
`
`
`
`
`
`
`
`
`
`
`Patent Owner’s reliance on PDL also fails because PDL merely refers to an
`
`exemplary embodiment that does not limit the scope of the claimed “Application.”
`
`The specification states that “[i]n certain embodiments, the applicant model in
`
`developing and providing Applications is a PDL.” (’287, 6:54-55.) Patent Owner
`
`does not contend that the challenged claims are limited to PDL or that anything in
`
`the specification describing PDL constitutes a disclaimer or disavowal that could
`
`restrict the scope of the challenged claims.
`
`PDL simply refers to a device-independent format in which device-
`
`independent code, such as Java, can be further translated and packaged with data
`
`into a compressed format. (’287, 6:54-7:20.) The challenged claims do not recite
`
`PDL or any other limitations relating to the format of device-independent code. The
`
`challenged claims only require an “Application” which has “device-independent
`
`code” – which a Java application clearly has. The fact that PDL describes a device-
`
`independent format does not mean that a Java application by itself is not device-
`
`independent code. Stated differently, the ability of device-independent Java code to
`
`be further translated and packaged into PDL format is, at most, an optional and
`
`unclaimed feature. (EX1021, ¶18.)
`
`
`
`The Prior Art Further Confirms that Java Applications Are
`“Device-Independent Code.”
`The prior art also confirms that Java programs are made up of bytecode
`
`instructions that are device-independent. (Petition, 15-16, 60-61; EX1002, ¶¶46, 60,
`
`5
`
`
`
`
`
`
`
`
`
`
`
`
`
`139-140; EX1021, ¶13.) For example, Anderson explains that “Java includes a
`
`compiler that produces portable bytecode and a Java Virtual Machine (JVM) that
`
`runs this bytecode on any processor.” (Anderson, EX1003, p.0035.) Ambrose-
`
`Haynes similarly explains that “code compiled from Java is not executable code;
`
`rather it’s byte code. Byte code is a set of instructions that is interpreted within a
`
`Java Runtime Environment (JRE), consisting of… a Java Virtual Machine (JVM)
`
`which actually executes the byte code.” (Ambrose-Haynes, EX1006, p.0055.)
`
`These disclosures further confirm that Java bytecode cannot be directly executed by
`
`the device and is thus device-independent. (EX1021, ¶13; see also EX1002, ¶139
`
`(“A Java application thus qualifies as ‘a device-independent code,’ because the
`
`bytecode instructions for the Java application can run on any processor that has a
`
`Java Virtual Machine (JVM), and therefore, is independent of the hardware or
`
`operating system of any particular device.”) (boldface in original).)
`
`
`
`Patent Owner’s Tortured Reading of the Litigation
`Construction of “Device-Independent Code” Is Unavailing
`and Would Render the Claims Inoperable.
`Patent Owner’s argument depends almost entirely on a construction of
`
`“device-independent code” in the pending litigation as “code that is not specific to
`
`the operating system, programming language, or platform of a device.” (EX2024,
`
`6.) Patent Owner argues that a Java application does not qualify as “device-
`
`
`
`
`
`6
`
`
`
`
`
`
`
`
`
`
`
`
`independent code” because a Java application is specific to the “programming
`
`language” and “platform” of a device. (Response, 12-16.)3
`
`But Patent Owner’s arguments rest on a gross misreading of the proposed
`
`construction. By stating that device-independent code is not specific to “the
`
`operating system programming language, or platform of a device,” the proposed
`
`construction was intended to make clear that the code of an Application must not be
`
`dependent on the specific operating system, programming language or platform of
`
`the device on which the Application is executing. (EX1021, ¶¶24-26.)
`
`For example, the “programming language… of a device” does not, contrary
`
`to Patent Owner’s arguments, refer to any programming language that can be used
`
`to write a software application for a device. An example of the “programming
`
`language… of a device” would include the specific programming language used
`
`internally by the device to carry out its operations, such as its “machine” language.
`
`(EX1021, ¶24; see also Microsoft Computer Dictionary (5th ed. 2002), EX1022,
`
`p.008 (“machine language n. See machine code.”); id. (“machine code n. The
`
`ultimate result of the compilation of assembly language or any high-level language
`
`such as C or Pascal: sequences of 1s and 0s that are loaded and executed by a
`
`
`3 Patent Owner does not appear to dispute that a Java application is “not specific to
`the operating system… of a device,” and thus focuses its argument on the
`“programming language” and “platform” aspects of the construction.
`
`7
`
`
`
`
`
`
`
`
`
`
`
`
`
`microprocessor. Machine code is the only language computers understand; all other
`
`programming languages represent ways of structuring human language so that
`
`humans can get computers to perform specific tasks. Also called: machine
`
`language.”) (boldface and italics in original).) For illustration, the “programming
`
`language… of a device” that uses an Intel-based microprocessor would include its
`
`machine language (known as the “Intel x86 instruction set”) that defines instructions
`
`for particular operations carried out by the specific processor in that device.
`
`(EX1021, ¶24.)
`
`This stands in stark contrast to Java bytecode instructions – they do not
`
`provide “the… programming language… of [any] device.” This is because bytecode
`
`instructions can run on any type of processor in any device that has a Java Virtual
`
`Machine (JVM). (EX1021, ¶25; EX1002, ¶139.) This is why Java programming is
`
`so widely regarded as being independent of the device on which the application is
`
`running. (EX1021, ¶25; EX1002, ¶139; see also Microsoft Computer Dictionary
`
`(5th ed. 2002), EX1022, pp.005-006 (“Java n. An object-oriented programming
`
`language developed by Sun Microsystems, Inc… Java was also designed to be
`
`secure and platform-neutral (meaning that it can be run on any platform) through the
`
`fact that Java programs are compiled into bytecode, which is not refined to the point
`
`of relying on platform-specific instructions and runs on a computer in a special
`
`software environment known as a virtual machine.”) (boldface and italics in
`
`
`
`
`
`8
`
`
`
`
`
`
`
`
`
`
`
`
`original).) This is consistent with the specification, which explains that authoring
`
`platform 110 may generate “programming” that includes “instructions that are
`
`independent of a device platform,” i.e., the Application. (’287, 5:19-28.) Java
`
`bytecodes are not “the… programming language… of a device” because they do not
`
`use a programming language specific to the device.
`
`For substantially the same reasons, the phrase “the… platform of a device” in
`
`the proposed construction refers to the specific technology platform of the device
`
`such as its hardware and processor as described above. (EX1021, ¶26.) This is also
`
`consistent with the specification, which describes the “platform” of a device in the
`
`context of its particular instruction set. The specification explains that “different
`
`devices 130 may be operable using different sets of instructions, that is having one
`
`of a variety of different ‘device platforms.’” (’287, 5:4-6; see also id., 5:13-17
`
`(describing “device-platform specific instructions for processor 135 of the device”).)
`
`It is these different “sets of instructions” that may require “different operating
`
`systems, different versions of an operating system, or different versions of virtual
`
`machines on the same operating system.” (’287, 5:6-10.)
`
`The “device platforms” described in the patent specification, defined by their
`
`different sets of instructions, also stand in stark contrast to Java bytecodes that are
`
`platform-independent and thus the same regardless of the underlying device-
`
`dependent instruction set used by the device. (EX1021, ¶26; EX1002, ¶¶46, 60, 139-
`
`
`
`
`
`9
`
`
`
`
`
`
`
`
`
`
`
`
`140; see also supra, Microsoft Computer Dictionary (5th ed. 2002), EX1022,
`
`pp.005-006 (“Java n. … Java programs are compiled into bytecode, which is not
`
`refined to the point of relying on platform-specific instructions and runs on a
`
`computer in a special software environment known as a virtual machine.”); New
`
`Penguin Dictionary of Computing (2001), EX1023, p.003 (“Java… Java is a semi-
`
`compiled language that compiles down to a platform-independent bytecode which
`
`can be run on any kind of processor, provided that there is a Java Virtual Machine
`
`available for that processor.”) (boldface and italics in original).) A Java application
`
`is therefore not “specific to the… platform of a device,” because Java bytecode is
`
`independent of the specific platform of the device on which it is executing.
`
`The proposed construction of “device-independent code” was never intended
`
`to exclude a Java application, and any such interpretation should be rejected as
`
`inconsistent with the intrinsic record as explained in detail above. Patent Owner’s
`
`interpretation of the proposed construction would also render the claims inoperable
`
`because no program could ever have the required “device-independent code.” The
`
`gist of Patent Owner’s argument appears to be that Java programs are not “device-
`
`independent code” because they are “specific” to the Java programming language
`
`and “specific” to the Java development platform that can run on a device. But all
`
`software applications require use of a programming language and development
`
`platform on a device to generate the instructions for the applications. (EX1021,
`
`
`
`
`
`10
`
`
`
`
`
`
`
`
`
`
`
`
`¶¶21-23.) The specification, for example, describes an authoring platform that runs
`
`on a device that provides the device-independent instructions for the “Application”
`
`and the device-dependent instructions for the “Player” that executes the Application.
`
`(’287, 3:35-37 (“Authoring platform 110 includes a computer or computer system
`
`having a memory 111, a processor 113, a screen 115, and an input device 117.”),
`
`24:1-3 (“Authoring platform 110 then generates an Application and a Player specific
`
`to device 130 of FIG. 4B.”), 5:13-19.) Patent Owner contends that a Java application
`
`is not “device-independent code” because it is “specific to a platform” (Response,
`
`14), but that same argument could be applied to any application including the
`
`“Application” described throughout the specification that is specific to the authoring
`
`platform used to generate it. (EX1021, ¶¶20-22.)
`
`In fact, even an Application in PDL format (the only thing Patent Owner
`
`appears to concede is actually “device-independent code”) would not qualify as
`
`device-independent code based on Patent Owner’s argument. This is because PDL
`
`format still requires a Player – provided by the authoring platform – to interpret and
`
`execute the Application (precisely mirroring the way that a Java application requires
`
`a JVM to interpret and execute its bytecode instructions). (EX1021, ¶23; ’287, 6:8-
`
`15 (“The Application is preferably code in a device-independent format, referred to
`
`herein and without limitation as a Portable Description Language (PDL). The
`
`device’s Player interprets or executes the Application to generate one or more
`
`
`
`
`
`11
`
`
`
`
`
`
`
`
`
`
`
`
`‘pages’ (‘Applications Pages’) on a display as defined by the PDL. The Player may
`
`include code that is device-specific—that it [sic; is], each device is provided with a
`
`Player that is used in the interpretation and execution of Applications.”); see also
`
`id., 5:27-28, 14:3-6.) Under Patent Owner’s argument, therefore, no “Application”
`
`could ever be “device-independent code” because even Applications in PDL format
`
`are generated using the authoring platform running on a device, and rely on that
`
`platform’s programming language and Player to execute the resulting Application.
`
`All of these problems are avoided by interpreting the proposed construction of
`
`“device-independent code” as it was intended, i.e., as excluding code that is
`
`dependent on the specific platform of the device.
`
`B.
`The Prior Art Combination Discloses a “Player.”
`The Petition explained that the Java Virtual Machine (JVM) qualifies as a
`
`“Player” because it carries out all functions of the Java application. (Petition, 61-
`
`62, 75-77; EX1002, ¶¶59-60, 165; EX1021, ¶33.) Patent Owner argues that the prior
`
`art combination fails to disclose a “Player,” but the basis of this argument is unclear.
`
`In every litigation in which it has asserted the challenged patent, Patent Owner has
`
`consistently argued that a Player is simply “software code that facilitates the
`
`execution of an application on a device.” (Petition, 11; see also EX1024, 004;
`
`EX1025, 009; EX1026, 0015; EX1027, 0013.) Patent Owner makes no direct
`
`mention of this proposed construction in its Response, but Patent Owner also does
`
`
`
`
`
`12
`
`
`
`
`
`
`
`
`
`
`
`
`not appear to propose any alternative construction.4
`
`Patent Owner instead argues that the JVM does not qualify as a “Player”
`
`because the specification describes a Player and virtual machine as separate
`
`components. (Response, 16-20.) But Patent Owner does not explain the legal
`
`significance of this argument, as its proposed construction of “Player” makes no
`
`reference to virtual machines. For example, in arguing that the JVM is not a
`
`“Player,” Patent Owner argues that “[a] Player is not a machine, or a machine
`
`emulated in software; instead, a Player facilitates the execution of an Application on
`
`a machine.” (Response, 19.) But these concepts are not mutually exclusive;
`
`something that calls itself a virtual machine can also “facilitate[] the execution of an
`
`Application on a device,” under Patent Owner’s construction, and the JVM does
`
`precisely that as explained. (Petition, 61-62, 75-77; EX1021, ¶34.)
`
`Nevertheless, to the extent Patent Owner now seeks to impose a new negative
`
`limitation on “Player” excluding any software component labeled a “virtual
`
`machine,” the intrinsic support does not support any such restriction. Patent Owner
`
`
`4 Petitioner is aware of only one court order actually construing “Player,” which
`construed it as “device-specific code which contains instructions for a device and
`which is separate from the Application.” (EX1025, 009.) Patent Owner does not
`contend that this construction should apply here; nevertheless, as Petitioner
`previously explained, the JVM satisfies this definition because “the JVM includes
`device-specific instructions for a particular device, and the JVM is a separate
`component from the Java application it is executing.” (EX1002, ¶144; Petition, 61-
`62.) Patent Owner does not argue otherwise.
`
`13
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`relies on Figure 2B (reproduced below), and specifically on its depiction of “Player”
`
`133a2 and “Virtual Machine” 133a3 using separate boxes:
`
`
`(’287, Fig. 2B.) Patent Owner’s reliance on Figure 2B fails because the arrangement
`
`
`
`shown above, in which Player 133a2 interfaces with Virtual Machine 133a3, which
`
`in turn interfaces with Operating System 133a4, is simply an embodiment. (’287,
`
`11:11-13 (“FIG. 2B is a schematic of one embodiment of a device 130 illustrating
`
`an embodiment of the programming generated by authoring platform 110.”).) Patent
`
`
`
`
`
`14
`
`
`
`
`
`
`
`
`
`
`
`
`Owner does not explain how this embodiment limits the claim scope.
`
`The specification also discloses a far more pertinent embodiment in which
`
`Virtual Machine 133a3 is not required because Player 133a2 is a native program that
`
`communicates directly with Operating System 133a4. (’287, 12:10-11 (“In another
`
`embodiment, the Player is a native program that interacts directly with the operating
`
`system.”).) The challenged claims reflect this embodiment by reciting a native or
`
`device-dependent “Player” and making no mention of any virtual machine. For
`
`example, claim 1 states that the Player is “device-dependent code,” thus expressly
`
`encompassing this alternative embodiment of a native player that does not use a
`
`separate virtual machine.
`
`This alternative embodiment mirrors the functions of the JVM, which is a
`
`device-dependent / native program that communicates with the operating system of
`
`the device. (EX1021, ¶32; Ambrose-Haynes, EX1006, 0055 (“… JVMs are written
`
`for each operating platform. In this way it is the JVM which is linked to the
`
`operating system, and handles all of the platform-specific details, while the source
`
`code you write for interpretation is platform independent.”); EX1002, ¶¶60, 142-
`
`144; Petition, 61.) The arrangement in Figure 2B showing an intermediate Virtual
`
`Machine 133a3 discloses at best an unclaimed embodiment in which Player 133a2
`
`is non-native (and thus not device-dependent) code, thus requiring Virtual Machine
`
`133a3 to execute the Application. (EX1021, ¶31.) Patent Owner’s superficial focus
`
`
`
`
`
`15
`
`
`
`
`
`
`
`
`
`
`
`
`on the fact that the JVM has the words “virtual machine” in its name is irrelevant,
`
`because the JVM clearly qualifies as a “Player” as that term is used in the patent.5
`
`C. The Prior Art Combination Discloses an Authoring Tool
`Configured to “Produce” a Player.
`The Board determined in its Institution Decision that claim 1 of the ’287
`
`patent does not require that the authoring tool “produce” a Player. (Institution
`
`Decision, 15-22.) Patent Owner’s arguments appear to assume that such a
`
`requirement exists in claim 1, but Patent Owner has not addressed any aspect of the
`
`Board’s analysis of this issue. (Response, 20.) Patent Owner’s argument
`
`nevertheless fails even if claim 1 were construed to include such a requirement.
`
`Petitioner identified two theories to explain how the authoring tool under the
`
`proposed combination produces the JVM (the “Player”). First, the JVM is loaded
`
`into the memory of the device and executed either (a) when the authoring tool starts
`
`up, or (b) when the Java application is built and launched by the authoring tool. The
`
`Petition explained that “[e]ither way, the JVM is brought forth (or ‘produced’), by
`
`being loaded into memory” and made available to the computer. (EX1002, ¶145.)
`
`
`5 Patent Owner also points to an Office Action response in U.S. Patent No.
`9,063,755 (the subject of IPR2021-01455), in which the applicants stated that “the
`Player (being device-dependent) is executed to interpret non-binary, device
`independent [sic; code] contained in the Application.” (EX2037, 9; Response, 19-
`20.) Patent Owner seizes on the word “non-binary,” but the sentence merely uses
`that term as a synonym for device-independent. (EX1021, ¶35.) Patent Owner
`identifies nothing in the file history suggesting that “Player” excludes the JVM.
`
`16
`
`
`
`
`
`
`
`
`
`
`
`
`
`Patent Owner speculates that the Creator in Anderson under this first theory does not
`
`actually load the JVM, but as explained, a Java application cannot even execute
`
`without the JVM. The Creator in Anderson thus could not “build[] the application,
`
`deploy[] it, and bring[] up a browser with the [developer’s] web application running”
`
`(Anderson, EX1003, p.0087), if it did not load the JVM. (EX1021, ¶38.)
`
`Patent Owner next argues that the authoring tool cannot “produce” the JVM
`
`because it already resides on the computer. But nothing in claim 1 requires that the
`
`Player be obtained from another computer. (Petition, 65.) In fact, dependent claim
`
`11 separately recites that the code for the Player is obtained over a network, and the
`
`Petition explained (for Ground 2) that this would have been obvious. (Petition, 81-
`
`85.) Claim 1 would therefore have been obvious even if it required producing the
`
`JVM by obtaining it from another computer. (EX1021, ¶¶39-40.)
`
`Patent Owner also challenges Petitioner’s citation to Ambrose-Haynes by
`
`asserting that it is actually the ColdFusion server, rather than the ColdFusion Studio,
`
`that launches the JVM. (Response, 24-25.) Patent Owner’s argument appears to
`
`assume that the claimed “authoring tool” as applied to Ambrose-Haynes can only
`
`include the Studio component of ColdFusion, but nothing in the claims requires that
`
`the authoring tool include only one component of the ColdFusion system. In the
`
`pending litigation, Patent Owner stipulated that “authoring tool” simply means “[a]
`
`system, with a graphical user interface, for generating code to display content on a
`
`
`
`
`
`17
`
`
`
`
`
`
`
`
`
`
`
`
`device screen.” (EX1024, 002.) ColdFusion clearly qualifies as such a “system,”
`
`and the fact that it includes both application server and Studio components does not
`
`prevent ColdFusion from being an authoring tool. (EX1021, ¶41.) And even if there
`
`was merit to Patent Owner’s line-drawing argument, Patent Owner’s argument still
`
`fails because the JVM could be loaded the first time the application attempts to
`
`utilize Java. (EX1002, ¶¶145, 147.) Patent Owner does not explain why it makes
`
`any difference whether the “authoring tool,” even narrowly drawn as Patent Owner
`
`suggests, directly loads the JVM or indirectly causes it to be loaded via the
`
`application server. Patent Owner’s argument is akin to saying that activating a car’s
`
`ignition switch does not start a car’s engine because the switch activates a starter
`
`that does that. (EX1021, ¶41.)6
`
`Petitioner also described a second way in which prior art discloses the
`
`producing step, i.e., when the authoring tool installs the Java Development Kit (JDK)
`
`on the computer’s storage. (EX1002, ¶¶146-147.) Patent Owner contends that “a
`
`JDK does not even include a Java virtual machine” (Response, 25), but this is
`
`demonstrably incorrect. Exhibit 2030, which Patent Owner cites for this assertion,
`
`
`6 Patent Owner also argues that Ambrose-Haynes discloses a “server-side
`technology” in which applications are executed on a physically separate back-end
`computer. (Response, 22-24.) This argument fails for the reasons explained in the
`next section because the “server-side technology” of the Java application in
`Anderson under the proposed combination executes on the developer’s computer.
`
`18
`
`
`
`
`
`
`
`
`
`
`
`
`
`affirmatively confirms that the JDK includes the Java Runtime Environment (JRE),
`
`which in turn includes the JVM. (EX2030, p.1; EX1021, ¶45.)
`
`D.
`
`Patent Owner’s Motivation to Combine Arguments Fail.
`
`Patent Owner’s Superficial “Client-Side” / “Server-Side”
`Arguments Ignore Express Teachings in Anderson.
`Patent Owner argues that it would not have been obvious to implement the
`
`proposed combination such that the “authoring tool,” “Application,” and “Player”
`
`all execute on the same computer. (Response, 26-32.) As noted in the Petition, the
`
`Java application in Anderson can be run on either the same or a different machine
`
`from the one used to create the application using Creator. (Petition, 63-64 (citing
`
`Anderson, EX1003, 0077 (“You use localhost if you’re running the application
`
`server on your own machine; otherwise, use the Internet address or host name where
`
`the server is running.”).) The Petition relied on the “same machine” implementation
`
`because it provided a more straightforward way to show the full sequence of
`
`development and execution of a Java web application recited in the claims.
`
`Patent Owner argues that the Java application in Anderson relies on both
`
`“client-side” and “server-side” components, which Patent Owner contends must be
`
`implemented using physically-separate computers connected over a network.
`
`(Response, 27-30.) But this is inaccurate.
`
`As noted, Anderson expressly teaches an implementation in which a single
`
`computer contains both the client-side (e.g. web browser) and server-side (e.g. Java
`
`
`
`
`19
`
`
`
`
`
`
`
`
`
`
`
`
`application executed by JVM) functionality. (Petition, 63-64; EX1002, ¶¶136, 152-
`
`153.) For example, Anderson describes using the same machine – “localhost” – to
`
`run the GoogleSearch Java application and display its output in a web browser.
`
`(Petition, 63-64; EX1002, ¶153 (citing Anderson, p.00303).) The te
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
