`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`FACEBOOK, INC.,
`Petitioner
`
`v.
`
`EXPRESS MOBILE, INC.,
`Patent Owner
`
`
`
`Case IPR2021-01457
`U.S. Patent No. 9,928,044 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
`Patent Owner’s Motivation to Combine Arguments Fail. ................. 16
`
`Patent Owner’s Superficial “Client-Side” / “Server-Side”
`Arguments Ignore Express Teachings in Anderson. ............... 16
`Anderson and Ambrose-Haynes Are Properly
`Combinable. ............................................................................. 20
`Patent Owner’s Generalized Attacks on the Prior Art
`Combination Are Without Merit. ............................................. 23
`III. CONCLUSION ............................................................................................. 24
`
`
`
`
`
`B.
`C.
`
`
`
`
`
`
`
`
`
`-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.
`
`With respect to motivations to combine, Patent Owner mischaracterizes the
`
`proposed combination as using client-side Java applets, but the Java application
`
`described in Anderson instead relies on server-side Java programs (servlets)
`
`executing on the same computer as the web browser, consistent with known software
`
`
`
`
`
`1
`
`
`
`
`
`
`
`
`
`
`
`
`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.”2 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, 63-64; 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 The challenged claims of the ’044 patent do not expressly recite that the claimed
`“application” of claim 1[b][vii] is device-independent code, but as explained in the
`Petition, the parties in the pending litigation have proposed constructions that would
`require that an application have device-independent code. (Petition, 11, 63-64.)
`
`2
`
`
`
`
`
`
`
`
`
`
`
`
`
`¶148.) 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”[.]
`
`(’044, 5:13-19.)3 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.
`
`(’044, 5:60-6:2.) 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
`
`
`3 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, 16-17.) 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. (’044, 5:60-6:2, 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. (’044, 5:63-6:2
`
`(“…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.” (’044, 5:61-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.” (’044, 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. (’044, 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, 16-17, 63-64; EX1002, ¶¶46, 76,
`
`5
`
`
`
`
`
`
`
`
`
`
`
`
`
`148-149; 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, ¶148
`
`(“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, 13-16.)4
`
`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
`
`
`4 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, ¶148.) This is why Java programming is
`
`so widely regarded as being independent of the device on which the application is
`
`running. (EX1021, ¶25; EX1002, ¶148; 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. (’044, 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.’” (’044, 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.” (’044, 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, 76, 148-
`
`
`
`
`
`9
`
`
`
`
`
`
`
`
`
`
`
`
`149; 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.
`
`(’044, 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,
`
`15), 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; ’044, 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, 65-
`
`66; EX1002, ¶¶153-154; 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.5
`
`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, 17-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, 20.) 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, 65-66, 77-79; 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
`
`
`5 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, ¶152; Petition, 65-
`66.) 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:
`
`
`(’044, 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. (’044,
`
`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. (’044, 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, dependent claim 14 states that the “player” of claim 1 “is a native
`
`program,” thus expressly reciting this alternative embodiment that does not use a
`
`separate virtual machine, and confirming that claim 1 encompasses this embodiment.
`
`(’044, 39:16-17.)
`
`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, 151-
`
`152; Petition, 65.) 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
`
`
`
`
`
`15
`
`
`
`
`
`
`
`
`
`
`
`
`133a3 to execute the application. (EX1021, ¶31.) Patent Owner’s superficial focus
`
`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.6
`
`C.
`
`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, 20-26.) 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, 67 (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.
`
`
`6 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 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, 21-24.) 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
`
`application executed by JVM) functionality. (Petition, 67; EX1002, ¶¶146, 150,
`
`155-156.) For example, Anderson describes using the same machine – “localhost” –
`
`to run the GoogleSearch Java application and display its output in a web browser.
`
`(Petition, 67; EX1002, ¶156 (citing Anderson, p.00303).) The term “localhost”
`
`refers to a well-known functionality in which a computer can issue a request to itself.
`
`(EX1021, ¶48; see also Microsoft Computer Dictionary (5th ed. 2002), EX1022,
`
`p.007 (“localhost n. The name that is used to represent the same computer on which
`
`a TCP/IP message originates. An IP packet sent to localhost has the IP address
`
`127.0.0.1 and does not actually go out to the Internet.”) (boldface and italics in
`
`original).) From the standpoint of a software application that transmits and receives
`
`information, requests directed to “localhost” (e.g. IP address “127.0.0.1”) behave no
`
`differently from requests directed to a remote computer over a network. (EX2021,
`
`¶48 n.2.) The “localhost” technique dates back to at least the 1980s. (Id.)
`
`The “localhost” technique disclosed in Anderson thus allows a single
`
`
`
`
`
`17
`
`
`
`
`
`
`
`
`
`
`
`
`computer to execute both the “server-side” and “client side” functionality of a Java
`
`application – a common technique for development of networked applications to
`
`simplify implementation and testing. (EX1021, ¶48 & n.2.)7 Thus, contrary to
`
`Patent Owner’s suggestions, there is nothing unusual about using the same computer
`
`in Anderson to execute both the “server-side” Java servlets (via the JVM) and the
`
`“client-side” web browser that accepts user input and displays search results.8
`
`Patent Owner next argues that “the Web browser, and not the alleged player,
`
`would provide any instructions for the display of the device to present any output
`
`values or other display.” (Response, 27.) But this argument ignores the claim
`
`language, which merely recites a player that “provides instructions for the display
`
`of the device to present an output value in the defined UI object.” The Petition
`
`explained that the JVM (“player”) on the device performs this step by carrying out
`
`the functions of the Java application, resulting in instructions that cause display of
`
`the user interface on the web browser. (Petition, 77-79; EX1002, ¶¶167-168.) The
`
`
`7 For example, another portion of Ambrose-Haynes attached by Patent Owner to its
`Response similarly describes using a single computer for client/server testing in the
`context of an exemplary application. (EX2034, p.31 (“In our case we have deployed
`the calculator.asmx file to the local machine for testing…”).)
`8 Patent Owner appears to suggest that the proposed combination relies on client-
`side Java applets, but it does not. (Response, e.g., 21, 25, 34.) As explained in the
`text and the Petition, the proposed combination instead relies on Java servlets
`executing on the developer computer. Patent Owner’s criticisms of Java applets
`therefore have no applicability to the proposed combination. (EX1021, ¶¶48, 57.)
`
`18
`
`
`
`
`
`
`
`
`
`
`
`
`
`result of those instructions is the display of the “Grid Panel” shown in Figure 10-1
`
`and in Figure 10-9 as it would appear in the web browser:
`
`
`(Petition, 78-79; EX1002, ¶¶167-168 (discussing Anderson, Figs. 10-1 & 10-9).)9
`
`
`
`
`
`Figure 10-9 above shows the output in the web browser generated from
`
`instructions (e.g., HTML code for the web page) received by the JVM running on
`
`the developer computer. (Petition, 77-79; EX1021, ¶50.) The JVM (“player”) is
`
`providing those instructions to the web browser and thus “provides instructions for
`
`the display of the device,” as claimed. (EX1021, ¶50.) Nothing in the challenged
`
`claims requires that the “player” directly present or physically draw the user
`
`interface for the user; the claim requires only that the player provide “instructions”
`
`
`9 Patent Owner argues that “the Java application described in Anderson is not
`executed in the web browser of the developer’s client-side computer.” (Response,
`20.) This argument is irrelevant because the claims do not require that the
`application be executed “in the web browser.” As shown in the text and in the
`Petition, moreover, the user interface of the Java application in Anderson is
`presented within “Mozilla Firefox,” a well-known Internet web browser. (Petition,
`62-63; Anderson, EX1003, p.00307, Fig. 10-9; EX1021, ¶47.)
`
`19
`
`
`
`
`
`
`
`
`
`
`
`
`
`for such display, which the JVM in Anderson does by providing instructions to the
`
`web browser as explained above.
`
`
`Anderson and Ambrose-Haynes Are Properly Combinable.
`Patent Owner next argues
`that because Ambrose-Haynes discloses
`
`ColdFusion, not Java, it teaches away from the proposed combination. (Response,
`
`30-31.) But Patent Owner’s f