Implicit, LLC v. Trend Micro, Inc.

Filing 115

CLAIM CONSTRUCTION MEMORANDUM AND OPINION AND ORDER. Signed by Judge Rodney Gilstrap on 3/29/2017. (gsg)

IN THE UNITED STATES DISTRICT COURT
FOR THE EASTERN DISTRICT OF TEXAS
TYLER DIVISION
Implicit, LLC,
Plaintiff,
v.

Case No. 6:16-cv-80-JRG
LEAD CASE

Trend Micro, Inc.,
Defendant.

CLAIM CONSTRUCTION MEMORANDUM OPINION AND ORDER
Before the Court is the opening claim construction brief of Implicit, LLC (“Plaintiff”) (Dkt.
No. 101, filed on January 17, 2017),1 the response of Trend Micro, Inc., Ericsson Inc., and Huawei
Technologies USA, Inc. (collectively “Defendants”) (Dkt. No. 103, filed on January 31, 2017),
and the reply of Plaintiff (Dkt. No. 106, filed on February 10, 2017). The Court held a hearing on
the issues of claim construction and claim definiteness on February 28, 2017. Having considered
the arguments and evidence presented by the parties at the hearing and in their briefing, the Court
issues this Order.

Citations to the parties’ filings are to the filing’s number in the docket (Dkt. No.) and pin cites
are to the page numbers assigned through ECF.
1

1

Table of Contents
I.

BACKGROUND ............................................................................................................... 3
A.

B.
II.

The Demultiplexing Patents .................................................................................... 4
A-1. Technology ................................................................................................. 4
A-2. Related Litigation........................................................................................ 5
The Applet Patents .................................................................................................. 6

LEGAL PRINCIPLES ..................................................................................................... 9
A.

Claim Construction ................................................................................................. 9

B.

Departing from the Ordinary Meaning of a Claim Term ...................................... 11

III.

AGREED CONSTRUCTIONS...................................................................................... 12

IV.

CONSTRUCTION OF DISPUTED TERMS ............................................................... 13
A.

The Demultiplexing Patents .................................................................................. 13

B.

A-1. “sequence of routines” and “sequence of two or more routines” ............. 13
A-2. “processing packets” and “process … packets”........................................ 20
A-3. “create” ..................................................................................................... 23
A-4. “the packet of the message” ...................................................................... 24
A-5. “list of conversion routines” ..................................................................... 28
The Applet Patents ................................................................................................ 30

“form of the application” .......................................................................... 30
“resource” ................................................................................................. 34
“generating the identified form of the application from another
form of the application” and “generated the identified form of the
application from another form of the application” ................................... 37
B-4. “source code that is in a form based on the specified one or more
client parameters for the first client computer” ........................................ 40
B-5. “a specific form of the particular applet that includes source code,
based on the specified one or more parameters in the applet
request, wherein the specific form complies with the specified one
or more parameters” .................................................................................. 42
B-6. “transformation operation” ....................................................................... 43
CONCLUSION ............................................................................................................... 45
B-1.
B-2.
B-3.

V.

2

I.

BACKGROUND
Plaintiff alleges infringement of five U.S. Patents: No. 6,324,685 (the “’685 Patent”), No.

8,694,683 (the “’683 Patent”), No. 8,856,779 (the “’779 Patent”), No. 9,270,790 (the “’790
Patent”), and No. 9,325,740 (the “’740 Patent”) (collectively, the “Asserted Patents”). The ’685
Patent is entitled “Applet Server That Provides Applets in Various Forms.” The application leading
to the ’685 Patent was filed on March 18, 1998 and the patent issued on November 27, 2001. The
’683 Patent is entitled “Method and System for Data Demultiplexing.” The application leading to
the ’683 Patent was filed on June 6, 2013 and the patent issued on April 8, 2014. The ’779 Patent
is entitled “Application Server for Delivering Applets to Client Computing Devices in a
Distributed Environment.” The application leading to the ’779 Patent was filed on October 10,
2011 and the patent issued on October 7, 2014. The ’790 Patent is entitled “Method and System
for Data Demultiplexing.” The application leading to the ’790 Patent was filed on March 31, 2014
and the patent issued on February 23, 2016. The ’740 Patent is entitled “Application Server for
Delivering Applets to Client Computing Devices in a Distributed Environment.” The application
leading to the ’740 Patent was filed on October 6, 2014 and the patent issued on April 26, 2016.
The Asserted Patents are part of two patent families: the Demultiplexing Patents (the ’683
Patent and the ’790 Patent) and the Applet Patents (the ’685 Patent, the ’779 Patent, and the ’740
Patent). With respect to the Demultiplexing Patents: The ’790 Patent claims priority to the ’683
Patent’s application as a continuation. Through a series of continuation applications, the ’790
Patent and the ’683 Patent each claim priority to an application filed on December 29, 1999 and
issued as U.S. Patent No. 6,629,163 (the “’163 Patent”). With Respect to the Applet Patents: The
’740 Patent claims priority to the ’779 Patent’s application as a continuation. The ’740 Patent and

3

the ’779 Patent each claim priority to the application that issued as the ’685 Patent, through a series
of continuation applications.
A.

The Demultiplexing Patents
A-1.

Technology

The Demultiplexing Patents are generally directed to technology for computer messageexchange processing and more specifically to technology for dynamically converting the form of
the messages as the messages are being exchanged.
The abstract of the ’683 Patent provides:
A method and system for demultiplexing packets of a message is provided. The
demultiplexing system receives packets of a message, identifies a sequence of
message handlers for processing the message, identifies state information
associated with the message for each message handler, and invokes the message
handlers passing the message and the associated state information. The system
identifies the message handlers based on the initial data type of the message and a
target data type. The identified message handlers effect the conversion of the data
to the target data type through various intermediate data types.
The abstract of the ’790 Patent provides:
A method and system for demultiplexing packets of a message is provided. The
demultiplexing system receives packets of a message, identifies a sequence of
message handlers for processing the message, identifies state information
associated with the message for each message handler, and invokes the message
handlers passing the message and the associated state information. The system
identifies the message handlers based on the initial data type of the message and a
target data type. The identified message handlers effect the conversion of the data
to the target data type through various intermediate data types.
Claim 1 of the ’683 Patent, provided here as an example, recites:
1. A first apparatus for receiving data from a second apparatus, the first
apparatus comprising:
a processing unit; and
a memory storing instructions executable by the processing unit to:
create, based on an identification of information in a received packet of a
message, a path that includes one or more data structures that indicate a
sequence of routines for processing packets in the message;
store the created path; and

4

process subsequent packets in the message using the sequence of routines
indicated in the stored path, wherein the sequence includes a routine that
is used to execute a Transmission Control Protocol (TCP) to convert one
or more packets having a TCP format into a different format.
Claim 8 of the ’790 Patent, provided here as an example, recites:
8. An apparatus, comprising:
a processing unit; and
a memory storing instructions executable by the processing unit to:
receive one or more packets of a message;
identify, using an IP address and one or more port addresses located in one
of the received packets, a sequence of two or more routines for
processing packets in the message; and
process the one or more received packets using the identified sequence of
routines, wherein the sequence includes a routine that is executable to
perform a Transmission Control Protocol (TCP) to convert at least one
of the packets of the message into a different format.
A-2.

Related Litigation

Two of the Demultiplexing Patents have previously been litigated in the U.S. District Court
for the Northern District of California. That court construed the ’163 Patent in Implicit Networks,
Inc. v. F5 Networks, Inc., No. 3:10-cv-3365-SI, 2012 U.S. Dist. LEXIS 27238 (N.D. Cal. Feb. 29,
2012) (“F5 Networks I”). The California court later construed the ’683 Patent in Implicit L.L.C. v.
F5 Networks, Inc., No. 3:14-cv-2856-SI, 2015 U.S. Dist. LEXIS 60197 (N.D. Cal. May 6, 2015)
(“F5 Networks II”). The F5 Networks I and F5 Networks II constructions relate to the “sequence
of routines,” “sequence of two or more routines” and “list of conversion routines” limitations of
the Asserted Patents.
In F5 Networks I, the court construed the term “non-predefined sequence of components”
found in claims of the ’163 Patent. First, the court held that the term “components” was defined in
the ’163 Patent to mean “software routines.” 2012 U.S. Dist. LEXIS 27238, at *9–10. Then the
court determined that a description of the prior art found in the ’163 Patent and patent-owner
statements made during reexamination of the ’163 Patent amounted to disclaimer of preconfigured
5

sequences of software routines. Id. at *10–13. Thus, the court construed “non-predefined sequence
of components” as “a sequence of software routines that was not identified before the first packet
of a message was received.” Id. at *13.
In F5 Networks II, the court construed the terms “sequence of routines” and “list of
conversion routines” found in claims of the ’683 Patent. These terms are presently before the
Court, as is the similar term “sequence of two or more routines” from the ’790 Patent. The F5
Networks II court determined that the disclaimer of preconfigured sequences of software routines
was tied to the invention described in the ’163 Patent—and not limited to specific language recited
in the claims of the ’163 Patent. 2015 U.S. Dist. LEXIS 60197, at *9–12. F5 Networks II reiterated
its analysis of the description of the prior art in the ’163 and ’683 Patents and the patent owner’s
explanation of that disavowal in the reexamination of the ’163 Patent. Id. at *34–37 (noting that
the patent owner “devoted an entire section of its [reexamination] response to further explain these
prior art disavowals in the first column of the specification shared by the ’163 and ’683 patents”).
Ultimately, F5 Networks II held that the patent owner “made it definitively clear to the PTO and
the public that the sequence of routines (or ‘path’) as disclosed in the ’163 patent specification is
not configured before receiving the first packet of a message” and that this disclaimer applies
equally to the ’683 Patent. Id. at *37–39. The court construed “sequence of routines” and “list of
conversion routines” as “a sequence of software routines that was not identified (i.e., configured)
prior to receiving a first packet of the message” and “a list of software routines that was not
identified (i.e., configured) prior to receiving a first packet of the message,” respectively. Id. at
*42.
B.

The Applet Patents

In general, the Applet Patents are directed to server technology for providing applets and
applications to a client computer.
6

The abstract of the ’685 Patent provides:
The present invention is an applet server which accepts requests for applets from
client computers. A request specifies the format in which an applet is to be delivered
to the requesting client computer. The applet server has a cache which it uses to
store applets for distribution to client computers. If the specified form of the
requested applet is available in the cache, the applet server transmits the applet to
the requesting client. If the applet is not available in the cache, the server will
attempt to build the applet from local resources (program code modules and
compilers) and transformer programs (verifiers and optimizers). If the applet server
is able to build the requested applet, it will then transmit the applet to the requesting
client computer. If the applet server is unable to build the requested applet, it will
pass the request to another applet server on the network for fulfillment of the
request.
The abstract of the ’779 Patent provides:
An applet server accepts requests for applets from client computers. A request
specifies the format in which an applet is to be delivered to the requesting client
computer. The applet server has a cache used to store applets for distribution to
client computers. If the specified form of the requested applet is available in the
cache, the applet server transmits the applet to the requesting client. If the applet is
not available in the cache, the server will attempt to build the applet from local
resources (program code modules and compilers) and transformer programs
(verifiers and optimizers). If the applet server is able to build the requested applet,
it will transmit the applet to the requesting client computer. If the applet server is
unable to build the requested applet, it will pass the request to another applet server
on the network for fulfillment of the request.
The abstract of the ’740 Patent provides:
An applet server accepts requests for applets from client computers. A request
specifies the format in which an applet is to be delivered to the requesting client
computer. The applet server has a cache used to store applets for distribution to
client computers. If the specified form of the requested applet is available in the
cache, the applet server transmits the applet to the requesting client. If the applet is
not available in the cache, the server will attempt to build the applet from local
resources (program code modules and compilers) and transformer programs
(verifiers and optimizers). If the applet server is able to build the requested applet,
it will transmit the applet to the requesting client computer. If the applet server is
unable to build the requested applet, it will pass the request to another applet server
on the network for fulfillment of the request.
Claim 1 of the ’685 Patent, provided here as an example, recites:
1. A method in a server computer for providing applications to client
computers, the method comprising:
7

receiving a request from a client computer, the request identifying an
application and identifying a form of the application, the identified form
being one of a plurality of available forms;
in response to receiving the request,
generating the identified form of the application from another form of the
application; and
sending the identified form of the application to the client computer; and
caching the identified form of the application so that when another request is
received for the application in the identified form, the identified form of the
application can be sent without regenerating the identified form of the
application.
Claim 12 of the ’779 Patent, provided here as an example, recites:
12. A non-transitory computer-readable storage medium having stored thereon
instructions that are executable to cause a computer system to perform
operations comprising:
receiving an applet request from a first client computer for a particular applet,
wherein the applet request specifies one or more parameters for the particular
applet that are based on one or more characteristics of the client computer;
acquiring a specific form of the particular applet that includes source code,
based on the specified one or more parameters in the applet request, wherein
the specific form complies with the specified one or more parameters; and
sending the specific form of the particular applet to the first client computer in
response to the applet request.
Claim 1 of the ’740 Patent, provided here as an example, recites:
1. A non-transitory computer-readable storage medium having stored thereon
instructions that are executable to cause a computer system to perform
operations comprising:
receiving, at the computer system, a first HTTP request from a first client
computer for a resource, wherein the resource includes source code;
producing, by the computer system, the resource for the first client computer,
wherein the producing includes:
conveying, by the computer system, a request for the resource to an
external network;
receiving, at the computer system, the resource from the external network;
and
performing, by the computer system, a transformation operation on the
resource; and
sending, by the computer system, the produced resource to the first client
computer in response to the first HTTP request.

8

II.

LEGAL PRINCIPLES
A.

Claim Construction

“It is a ‘bedrock principle’ of patent law that ‘the claims of a patent define the invention to
which the patentee is entitled the right to exclude.’” Phillips v. AWH Corp., 415 F.3d 1303, 1312
(Fed. Cir. 2005) (en banc) (quoting Innova/Pure Water Inc. v. Safari Water Filtration Sys., Inc.,
381 F.3d 1111, 1115 (Fed. Cir. 2004)). To determine the meaning of the claims, courts start by
considering the intrinsic evidence. Id. at 1313. The intrinsic evidence includes the claims
themselves, the specification, and the prosecution history. Id. at 1314. The general rule—subject
to certain specific exceptions discussed infra—is that each claim term is construed according to
its ordinary and accustomed meaning as understood by one of ordinary skill in the art at the time
of the invention in the context of the patent. Id. at 1312–13; see also Azure Networks, LLC v. CSR
PLC, 771 F.3d 1336, 1347 (Fed. Cir. 2014) (“There is a heavy presumption that claim terms carry
their accustomed meaning in the relevant community at the relevant time.”) (vacated on other
grounds).
“[I]n all aspects of claim construction, ‘the name of the game is the claim.’” Apple Inc. v.
Motorola, Inc., 757 F.3d 1286, 1298 (Fed. Cir. 2014) (quoting In re Hiniker Co., 150 F.3d 1362,
1369 (Fed. Cir. 1998)). First, a term’s context in the asserted claim can be instructive. Phillips,
415 F.3d at 1314. Other asserted or unasserted claims can also aid in determining the claim’s
meaning, because claim terms are typically used consistently throughout the patent. Id. Differences
among the claim terms can also assist in understanding a term’s meaning. Id. For example, when
a dependent claim adds a limitation to an independent claim, it is presumed that the independent
claim does not include the limitation. Id. at 1314–15.
“[C]laims [also] ‘must be read in view of the specification, of which they are a part.’” Id.
(quoting Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995) (en banc)).
9

“[T]he specification ‘is always highly relevant to the claim construction analysis. Usually, it is
dispositive; it is the single best guide to the meaning of a disputed term.’” Id. (quoting Vitronics
Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)). However, “‘[a]lthough the
specification may aid the court in interpreting the meaning of disputed claim language, particular
embodiments and examples appearing in the specification will not generally be read into the
claims.’” Comark Commc’ns, Inc. v. Harris Corp., 156 F.3d 1182, 1187 (Fed. Cir. 1998) (quoting
Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed. Cir. 1988)); see also
Phillips, 415 F.3d at 1323. “[I]t is improper to read limitations from a preferred embodiment
described in the specification—even if it is the only embodiment—into the claims absent a clear
indication in the intrinsic record that the patentee intended the claims to be so limited.” LiebelFlarsheim Co. v. Medrad, Inc., 358 F.3d 898, 913 (Fed. Cir. 2004).
The prosecution history is another tool to supply the proper context for claim construction
because, like the specification, the prosecution history provides evidence of how the U.S. Patent
and Trademark Office (“PTO”) and the inventor understood the patent. Phillips, 415 F.3d at 1317.
However, “because the prosecution history represents an ongoing negotiation between the PTO
and the applicant, rather than the final product of that negotiation, it often lacks the clarity of the
specification and thus is less useful for claim construction purposes.” Id. at 1318; see also Athletic
Alternatives, Inc. v. Prince Mfg., 73 F.3d 1573, 1580 (Fed. Cir. 1996) (ambiguous prosecution
history may be “unhelpful as an interpretive resource”).
Although extrinsic evidence can also be useful, it is “‘less significant than the intrinsic
record in determining the legally operative meaning of claim language.’” Phillips, 415 F.3d at
1317 (quoting C.R. Bard, Inc., 388 F.3d at 862). Technical dictionaries and treatises may help a
court understand the underlying technology and the manner in which one skilled in the art might

10

use claim terms, but they may provide definitions that are too broad or may not be indicative of
how the term is used in the patent. Id. at 1318. Similarly, expert testimony may aid a court in
understanding the underlying technology and determining the particular meaning of a term in the
pertinent field, but an expert’s conclusory, unsupported assertions as to a term’s definition are not
helpful to a court. Id. Thus, extrinsic evidence is typically “less reliable than the patent and its
prosecution history in determining how to read claim terms.” Id. The Supreme Court recently
explained the role of extrinsic evidence in claim construction:
In some cases, however, the district court will need to look beyond the patent’s
intrinsic evidence and to consult extrinsic evidence in order to understand, for
example, the background science or the meaning of a term in the relevant art during
the relevant time period. See, e.g., Seymour v. Osborne, 11 Wall. 516, 546 (1871)
(a patent may be “so interspersed with technical terms and terms of art that the
testimony of scientific witnesses is indispensable to a correct understanding of its
meaning”). In cases where those subsidiary facts are in dispute, courts will need to
make subsidiary factual findings about that extrinsic evidence. These are the
“evidentiary underpinnings” of claim construction that we discussed in Markman,
and this subsidiary factfinding must be reviewed for clear error on appeal.
Teva Pharm. USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 841 (2015).
B.

Departing from the Ordinary Meaning of a Claim Term

There are “only two exceptions to [the] general rule” that claim terms are construed
according to their plain and ordinary meaning: “1) when a patentee sets out a definition and acts
as his own lexicographer, or 2) when the patentee disavows the full scope of the claim term either
in the specification or during prosecution.”2 Golden Bridge Tech., Inc. v. Apple Inc., 758 F.3d
1362, 1365 (Fed. Cir. 2014) (quoting Thorner v. Sony Computer Entm’t Am. LLC, 669 F.3d 1362,
1365 (Fed. Cir. 2012)); see also GE Lighting Solutions, LLC v. AgiLight, Inc., 750 F.3d 1304, 1309

Some cases have characterized other principles of claim construction as “exceptions” to the
general rule, such as the statutory requirement that a means-plus-function term is construed to
cover the corresponding structure disclosed in the specification. See, e.g., CCS Fitness, Inc. v.
Brunswick Corp., 288 F.3d 1359, 1367 (Fed. Cir. 2002).
2

11

(Fed. Cir. 2014) (“[T]he specification and prosecution history only compel departure from the
plain meaning in two instances: lexicography and disavowal.”). The standards for finding
lexicography or disavowal are “exacting.” GE Lighting Solutions, 750 F.3d at 1309.
To act as his own lexicographer, the patentee must “clearly set forth a definition of the
disputed claim term,” and “clearly express an intent to define the term.” Id. (quoting Thorner, 669
F.3d at 1365); see also Renishaw, 158 F.3d at 1249. The patentee’s lexicography must appear
“with reasonable clarity, deliberateness, and precision.” Renishaw, 158 F.3d at 1249.
To disavow or disclaim the full scope of a claim term, the patentee’s statements in the
specification or prosecution history must amount to a “clear and unmistakable” surrender. Cordis
Corp. v. Boston Sci. Corp., 561 F.3d 1319, 1329 (Fed. Cir. 2009). “Where an applicant’s
statements are amenable to multiple reasonable interpretations, they cannot be deemed clear and
unmistakable.” 3M Innovative Props. Co. v. Tredegar Corp., 725 F.3d 1315, 1326 (Fed. Cir. 2013).
III.

AGREED CONSTRUCTIONS
The parties have agreed to the following constructions set forth in their Joint Claim

Construction Chart Statement (Dkt. No. 107).
Term3
“message”



’683 Patent Claims 1, 10, 24
’790 Patent Claims 8, 15

“applet”



’685 Patent Claims 18, 49
’779 Patent Claims 1, 12, 18

Agreed Construction
a collection of data that is related in some
way, such as a stream of video or audio data
or an email message
program instructions provided as a selfcontained program or as a code fragment
associated with a larger application

3

For all term charts in this order, the claims in which the term is found are listed with the term
but: (1) only the highest-level claim in each dependency chain is listed, and (2) only asserted claims
identified in the parties’ Joint Claim Construction Chart Statement (Dkt. No. 107) are listed.
12

Term3

Agreed Construction
program designed to assist in the performance
of a specific task

“application”



’685 Patent Claims 1, 3, 15, 18, 34, 49
’740 Patent Claim 11

“cache”



temporary memory for storing an
application/applet or a portion thereof

’685 Patent Claims 15, 34
’779 Patent Claims 4, 5, 6

“caching”



temporarily storing in memory an
application/applet or a portion thereof

’685 Patent Claims 1, 15
’779 Patent Claim 19

“source code”



code in the form of a higher level language
such as C, C++, Java, Visual Basic, ActiveX,
Fortran, and Modula

’779 Patent Claim 1, 12, 18
’740 Patent Claims 1, 19

“optimizing”



making improvements to applets by
substituting functionally equivalent code

’779 Patent Claim 20
’740 Patent Claim 15

Having reviewed the intrinsic and extrinsic evidence of record, the Court agrees with and
hereby adopts the parties’ agreed constructions.
IV.

CONSTRUCTION OF DISPUTED TERMS
A.

The Demultiplexing Patents
A-1.

“sequence of routines” and “sequence of two or more routines”

Disputed Term
“sequence of routines”


’683 Patent Claims 1, 24

“sequence of two or more
routines”


’790 Patent Claim 8

Plaintiff’s Proposed
Construction
an ordered arrangement of
software routines

Defendants’ Proposed
Construction
an ordered arrangement of
software routines that was not
identified (i.e., configured)
prior to receiving a first
packet of the message
an ordered arrangement of
an ordered arrangement of
two or more software routines two or more software routines
that was not identified (i.e.,
configured) prior to receiving
a first packet of the message
13

Because the parties’ arguments and proposed constructions with respect to these terms are
related, the Court addresses the terms together.
The Parties’ Positions
Plaintiff submits the claim constructions in Implicit Networks, Inc. v. F5 Networks, Inc.,
No. 3:10-cv-3365-SI, 2012 U.S. Dist. LEXIS 27238 (N.D. Cal. Feb. 29, 2012) (“F5 Networks I”)
and Implicit L.L.C. v. F5 Networks, Inc., No. 3:14-cv-2856-SI, 2015 U.S. Dist. LEXIS 60197 (N.D.
Cal. May 6, 2015) (“F5 Networks II”) are not binding on Plaintiff or the Court. Dkt. No. 101 at
10–11. Plaintiff argues that the plain and ordinary meanings of these terms govern and that there
was no disclaimer of preconfigured sequences. Id. at 11–13. According to Plaintiff, F5 Networks
II erred in holding disclaimer and the basis of this error was conflating “sequence” with “path.”
Id. at 11–13. Plaintiff argues that, in the Demultiplexing Patents, a “path is a sequence of sessions,
each session having associated with it its own sequence of conversion routines.” Id. at 11. Plaintiff
further argues that the patents explain that while sessions are dynamically configured (i.e., they
are not preconfigured), the sequences of the dynamically generated sessions may be preconfigured.
Id. at 11–12.
In addition to the claims themselves, Plaintiff cites the following intrinsic and extrinsic
evidence to support its position: Intrinsic evidence: ’683 Patent figs.5, 15, col.2 ll.44–49, col.3
ll.9–12, col.3 ll.34–35, col.3 ll.43–53, col.3 ll.62–67, col.6 ll.24–29, col.10 ll.46–49, col.11 ll.1–3,
col.11 ll.19–21. Extrinsic evidence: Authoritative Dictionary of IEEE Standards Terms, “routine”
and “sequence,” (6th ed. 1996); Microsoft Press Computer Dictionary, “routine” (1997).
Defendants respond that: (1) the statements made in reexamination of the ’163 Patent
constitute disclaimer of preconfigured sequences of routines in the Demultiplexing Patents, and
(2) Plaintiff is collaterally estopped from challenging the F5 Networks I holding of this disclaimer

14

with respect to the ’163 Patent and the F5 Networks II holding of this disclaimer with respect to
the Demultiplexing Patents. Dkt. No. 103 at 6–17. Defendants contend the patentee equated
“sequence of conversion routines” and “path” in the reexamination of the ’163 Patent. Id. at 15–
16.
In addition to the claims themselves, Defendants cite the following intrinsic evidence to
support their position: ’163 Patent File Wrapper September 1, 2009 Amendment and Response to
Office Action in Ex Parte Reexamination 90/010,356 (Defendants’ Ex. 1, Dkt. No. 103-1),
February 8, 2010 Amendment and Response to Advisory Action in Ex Parte Reexamination
90/010,356 (Defendants’ Ex. 2, Dkt. No. 103-2), October 23, 2009 Interview Summary in Ex Parte
Reexamination 90/010,356 (Defendants’ Ex. 4, Dkt. No. 103-4).
Plaintiff replies that neither F5 Networks I nor F5 Networks II triggers collateral estoppel.
Dkt. No. 106 at 5–8. With respect to F5 Networks I, Plaintiff contends: (1) the litigation involved
only the ’163 Patent, not any of the Asserted Patents and (2) the claim language there at issue—
“dynamically identifying a non-predefined sequence of components”—is meaningfully different
from the claim language here, thus the issues are not identical. Id. at 5, 7 (emphasis by Plaintiff).
With respect to F5 Networks II, Plaintiff contends: (1) the litigation ended by settlement rather
than judgment, and (2) the ’790 Patent was not at issue. Id. at 5–8.
Plaintiff further replies that rather than disclaiming preconfigured sequences, the patentee
expressly claimed such in Claim 9 of the ’683 Patent, which recites a sequence that is stored “prior
to receiving the packet of the message.” Id. at 7.

15

Analysis
The issue here distills to whether the inventions of the ’683 and ’790 Patents include
identifying or creating the message-processing sequence of routines before receipt of the first
packet of the message. They do not.
The ’683 and ’790 Patents are directed to dynamic configuration of conversion-processing
routines used to process packetized messages into the appropriate forms. For example, the patents
teach that “[i]t would be desirable to have a technique for dynamically identifying a series of
conversion routines for processing data.” ’683 Patent col.2 ll.4–6; ’790 Patent col.2 ll.5–7 (same).
The dynamic nature of the inventions is an answer to the static-nature failings of the disparaged
prior art. ’683 Patent col.1 l.45 – col.2 l.3; ’790 Patent col.1 l.46 – col.2 l.4. Specifically, the priorart “computer systems typically use predefined configuration information to load the correct
combination of conversion routines for processing data.” ’683 Patent col.1 ll.48–50; ’790 Patent
col.1 ll.49–51. These systems “may create a separate process for each conversion that needs to
take place.” ’683 Patent col.1 ll.52–54; ’790 Patent col.1 ll.53–55. However, data to be converted
“may take many different formats that may not be known until the data is received.” ’683 Patent
col.1 ll.54–57; ’790 Patent col.1 ll.55–58. Because of this, “[t]he overhead of statically providing
each possible series of conversion routines is very high.” ’683 Patent col.1 ll.57–59; ’790 Patent
col.1 ll.58–60. The patentee explained this disclosure—as identically found in the ’163 Patent at
column 1, line 38 to column 2, line 5: it “clearly states that the invention requires the sequence of
conversion routines (that form the paths) to be identified at run-time, and disavows prior art
systems (like Mosberger) that use pre-configured paths, which are defined at ‘build-time’ before
the first packet of a message is received.” ’163 Patent File Wrapper September 1, 2009

16

Amendment and Response to Office Action in Ex Parte Reexamination 90/010,356 at 18 (Dkt. No.
103-1 at 18).
The patents and related prosecution history help explain the inventive dynamicconfiguration approach. For example, the patents teach that “[w]hen a packet of a message is
received, the conversion system in one embodiment searches for and identifies a sequence of
conversion routines (or more generally message handlers) for processing the packets of the
message by comparing the input and output formats of the conversion routines.” ’683 Patent col.2
ll.44–49; ’790 Patent col.2 ll.45–50. The patentee explained this passage—as identically found in
the ‘163 Patent at column 2 lines 40–45—to mean “the sequence of conversion routines (or ‘path’)
is not configured prior to receiving the first packet of a message.” ’163 Patent File Wrapper
September 1, 2009 Amendment and Response to Office Action in Ex Parte Reexamination
90/010,356 at 18 (Dkt. No. 103-1 at 18). The patents also describe the invention with reference to
Figure 1 (reproduced in part below): a driver (101) sends the first packet of a message to a
“message send routine” (102) which invokes a “demux routine” (103) which invokes a “labelmap
get routine” (104) to identify a sequence of routines to process the message and the “demux
routine” (103) subsequently enter path entries for each of the identified routines. ’683 Patent col.4
ll.1–21; ’790 Patent col.4 ll.1–21. The patentee explained that this description—as identically
found in the ’163 Patent at column 3 line 65 to column 4 line 18—teaches that:
the path data structure containing the sequence of conversion routines (i.e.,
“sequence of components”) needed to process the message is not configured until
after the first packet of the message is received. In other words, all path
configuration and path creation happens at runtime, after the first packet of a
message is received.

17

’163 Patent File Wrapper September 1, 2009 Amendment and Response to Office Action in Ex
Parte Reexamination 90/010,356 at 18–19 (Dkt. No. 103-1 at 18–19).

Portion of Figure 1 of the ’683, ’790, and ’163 Patents

Ultimately, the teachings of the patents regarding the inventions’ dynamic-configuration
approach, and disparagement of the prior-art static-configuration approach, explain that the
sequence of conversion routines that together process the packets “cannot be configured before the
first packet of the message is received.” See ’163 Patent File Wrapper September 1, 2009
Amendment and Response to Office Action in Ex Parte Reexamination 90/010,356 at 20 (Dkt. No.
103-1 at 20); see also, ’163 Patent File Wrapper October 23, 2009 Interview Summary in Ex Parte
Reexamination 90/010,356 at 10 (Dkt. No. 103-4 at 10) (“’163 spec states sequence of components
is identified when first packet arrives and disavows prior art ‘predefined configuration’ (e.g., 1:4143, 1:64-66, 2:40-45)”). It is appropriate to limit the claims accordingly. See Inpro II Licensing,
S.A.R.L. v. T-Mobile USA Inc., 450 F.3d 1350, 1353–57 (Fed. Cir. 2006) (limiting a claim to
exclude certain technology when that technology was disparaged in the patent and prosecution
history and when overcoming the failing of that technology was described as a purpose of the
invention); see also, Chicago Bd. Options Exch., Inc. v. Int'l Sec. Exch., LLC, 677 F.3d 1361,
1371–72 (Fed. Cir. 2012) (disparaged technology excluded from claims); UltimatePointer, L.L.C.
v. Nintendo Co., 816 F.3d 816, 822–24 (Fed. Cir. 2016) (same).

18

Claim 9 does not dictate a different result. Rather, this claim should be understood to mean
that the sequence of routines may be dynamically configured by selecting preexisting sequences
of routines that are combined to form the dynamically generated sequence. See Phillips v. AWH
Corp., 415 F.3d 1303, 1316 (Fed. Cir. 2005) (en banc) (“‘The construction that stays true to the
claim language and most naturally aligns with the patent's description of the invention will be, in
the end, the correct construction.’” (quoting Renishaw PLC v. Marposs Societa' per Azioni, 158
F.3d 1243, 1250 (Fed. Cir. 1998)). The Court addresses Claim 9 in more detail in the section on
“the packet of the message” below.
The Court’s understanding of the “sequence of routines” that form the processing sequence
comports with the F5 Networks II determination that the invention disclosed in the ’683 Patent is
limited to sequences that are not configured before receipt of the first packet. The Court need not
reach issues relating to estoppel. Further, the Court agrees with the analysis in F5 Networks II.
Specifically, the statements in the prosecution history of the ’163 Patent are relevant to
interpretation of the ’683 and ’790 Patents and that the statements regarding preconfigured
sequences of routines are directed to the invention disclosed in the patents, and not specifically to
claim language unique to the ’163 Patent. Indeed, the prosecution-history statements explain a
disavowal of preconfigured sequences that is stated in the common specification of the ’163, ’683,
and ’790 Patents.
Accordingly, the Court construes “sequence of routines” and “sequence of two or more
routines” as follows:


“sequence of routines” means “an ordered arrangement of software routines that
was not identified (i.e., configured) prior to receiving a first packet of the
message”; and

19



“sequence of two or more routines” means “an ordered arrangement of two or
more software routines that was not identified (i.e., configured) prior to receiving
a first packet of the message.”
A-2.

“processing packets” and “process … packets”

Disputed Term
“processing packets”



’683 Patent Claims 1
’790 Patent Claim 8

“process … packets”



’683 Patent Claims 1, 10, 24
’790 Patent Claim 8

Plaintiff’s Proposed
Construction
applying one or more
routines to packets

Defendants’ Proposed
Construction
applying one or more
conversion routines to
packets

apply one or more
routines to packets

apply one or more conversion
routines to packets

Because the parties’ arguments and proposed constructions with respect to these terms are
related, the Court addresses the terms together.
The Parties’ Positions
Plaintiff submits packet processing of the claims is not limited to application of conversion
routines. Dkt. No. 101 at 13–14.
Defendants respond that the Demultiplexing Patents limit packet-processing routines to
conversion routines. Dkt. No. 103 at 19–20.
In addition to the claims themselves, Defendants cite the following intrinsic evidence to
support their position: ’683 Patent col.2 ll.44–49, col.2 l.65 – col.3 l.1, col.3 ll.17–20, col.4 ll.32–
34.
Plaintiff replies that “process” and “processing” are not specially defined as conversion
processing and are entitled their full plain and ordinary meaning. Dkt. No. 106 at 8.

20

Analysis
The parties agree that packet-processing limitations require application of one or more
routines to packets. The issue in dispute appears to be whether each routine in the sequence of
routines is a conversion routine. While the claims are directed to converting packets from one form
to another by processing with the sequence of routines, they do not require that each routine in the
sequence is necessarily a conversion routine.
Each claim is explicitly directed to processing data packets to convert from one form to
another. For example, ’683 Patent Claim 1 recites:
process subsequent packets in the message using the sequence of routines indicated
in the stored path, wherein the sequence includes a routine that is used to execute a
Transmission Control Protocol (TCP) to convert one or more packets having a TCP
format into a different format.
’683 Patent col.14 ll.30–35. Claim 24 recites:
process subsequent packets of the message using the sequence of routines
referenced by the one or more data structures, including by removing an outermost
header of a given packet using a first routine corresponding to a protocol in a first
layer and by removing the resulting outermost header using a second routine
corresponding to a different protocol in a different layer.”
Id. at col.16 ll.34–39. Similar conversion-process limitations are found in each independent claim
of the ’683 and ’790 Patents.
Other than Claim 10, however, the claims do not explicitly require that each of the
processing routines of the sequence be a “conversion routine.” The Court will not read such a
limitation into the claims. That the term “conversion routines” was used in Claim 10—and simply
“routines” in the other claims—strongly suggests that the patentee did not intend to limit all the
routines to “conversion routines.” See Phillips v. AWH Corp., 415 F.3d 1303, 1314 (Fed. Cir.
2005) (en banc) (noting that the use of the term “steel baffles” “strongly implies that the term
‘baffles’ does not inherently mean objects made of steel”). The Court is not persuaded that the
21

patents otherwise limited “routines” to conversion routines. Even if all described routines are
conversion routines, that alone is not sufficient to inject such a limitation into the claims. Id. at
1323 (“we have expressly rejected the contention that if a patent describes only a single
embodiment, the claims of the patent must be construed as being limited to that embodiment”);
Thorner v. Sony Comput. Entm’t Am. LLC, 669 F.3d 1362, 1366 (Fed. Cir. 2012) (“It is likewise
not enough that the only embodiments, or all of the embodiments, contain a particular limitation.
We do not read limitations from the specification into claims; we do not redefine words. Only the
patentee can do that.”); SRI Int’l v. Matsushita Elec. Corp., 775 F.2d 1107, 1121 (Fed. Cir. 1985)
(en banc) (“The law does not require the impossible. Hence, it does not require that an applicant
describe in his specification every conceivable and possible future embodiment of his invention.”).
Finally, Claim 6 recites: “wherein the sequence of routines includes a routine that is executable
to process the packets without converting a format of the packets.” ’683 Patent col.14 ll.53–55
(emphasis added). Simply, “routine” is broader than “conversion routine.”
Defendants’ argument also seems to exclude processing disclosed in the patents.
Specifically, Defendants state that compression is not a conversion routine. Dkt. No. 103 at 20.
Yet the patents contemplate that compression (and encryption) routines may be used in the process
for transmitting and receiving data in computer-to-computer messaging. ’683 Patent col.1 ll.24–
44. That is, the patents disclose that processes other than converting from one transport-layer
format to another may be part of the packet processing.
Accordingly, the Court construes “processing packets” and “process … packets” as
follows:


“processing packets” means “applying one or more routines to packets”;



“process … packets” means “apply one or more routines to packets.”

22

A-3.

“create”

Disputed Term
“create”


Plaintiff’s Proposed
Construction
plain and ordinary meaning

’683 Patent Claims 1, 10,
24

Defendants’ Proposed
Construction
dynamically generate after
the first packet of a message
is received

The Parties’ Positions
Plaintiff submits that the “create” of the Demultiplexing Patents may occur at any time—
it is not limited either to dynamic generation or creation that occurs only after receipt of the first
packet of a message. Dkt. No. 101 at 14.
Defendants respond that the claims themselves require that the “create” happens after
receipt of a packet in a message. Dkt. No. 103 at 18–19. Defendants also contend that ’683 Patent
distinguishes the prior art on the ground that the invention creates a sequence of routines after
receiving the first packet of the message. Id. at 19 (citing ’683 Patent col.1 l.45 – col.2 l.11).
Finally, Defendants note that their proposed construction is consistent with the disclaimer of
preconfigured sequences. Id.
In addition to the claims themselves, Defendants cite the following intrinsic evidence to
support their position: ’683 Patent col.1 l.45 – col.2 l.11; ’163 Patent File Wrapper September 1,
2009 Amendment and Response to Office Action in Ex Parte Reexamination 90/010,356
(Defendants’ Ex. 1, Dkt. No. 103-1), February 8, 2010 Amendment and Response to Advisory
Action in Ex Parte Reexamination 90/010,356 (Defendants’ Ex. 2, Dkt. No. 103-2), October 23,
2009 Interview Summary in Ex Parte Reexamination 90/010,356 (Defendants’ Ex. 4, Dkt. No.
103-4).
Plaintiff replies that the plain and ordinary meaning of “create” does not require
“dynamically” creating or creating “after the first packet of a message is received.” Dkt. No. 106
23

at 8. Rather, Plaintiff contends, Claim 10 expressly recites “obtain information from a particular
packet,” not necessarily from the first packet. Id. (emphasis by Plaintiff).
Analysis
The issue here is the same as the issue addressed in the section on “sequence of routines”;
namely, whether the created path/data structure may comprise a preconfigured sequence of
routines. It may not.
As explained above, the invention of the ’683 Patent is directed to dynamic configuration
of conversion-processing sequences—and does not include preconfiguring the conversionprocessing sequence of routines. Thus, the path/data structure comprising the conversionprocessing sequence of routines is necessarily created after receipt of the first packet of the
message. That said, this limitation is found in the Court’s construction of “sequence of routines”
and “list of conversion routines” and does not need to be separately injected into “create.”
Accordingly, the Court determines that “create” has its plain and ordinary meaning without
the need for further construction.
A-4.

“the packet of the message”

Disputed Term
“the packet of the message”


Plaintiff’s Proposed
Construction
plain and ordinary meaning

Defendants’ Proposed
Construction
indefinite

’683 Patent Claim 9
The Parties’ Positions
Plaintiff submits that “the packet of the message” in Claim 9 of the ’683 Patent refers to “a

received packet of a message” in Claim 1, from which Claim 9 ultimately depends. Dkt. No. 101
at 15–16.

24

Defendants respond that this term lacks antecedent basis. Dkt. No. 103 at 20–22.
Specifically, Defendants argue that because Claim 1 recites both “a received packet of a message”
and “subsequent packets in the message,” it is unclear which packet of the message is “the packet
of the message” in Claim 9. Id. at 21–22.
Plaintiff replies that the antecedent basis of “the packet of the message” is Claim 1’s
“information in a received packet of a message” because: (1) Claim 8 recites “to identify an address
associated with the information,” which refers to the information in the received packet and (2)
Claim 9, which depends from Claim 8, recites using this “address” that is associated with “the
packet of the message.” Dkt. No. 106 at 9.
Analysis
The issue here is whether the antecedent basis for “the packet of the message” is reasonably
certain. In context, it is reasonably certain that antecedent basis is the “received packet of a
message” recited in Claim 1.

25

Claim 9’s “the packet of the message” refers to the “received packet of a message” in Claim
1. Claim 1, reproduced here and annotated by

1. A first apparatus for receiving data from a second
apparatus, the first apparatus comprising:
a processing unit; and
a memory storing instructions executable by the
processing unit to:
create, based on an identification of information
in a received packet of a message, a path that
includes one or more data structures that
indicate a sequence of routines for processing
packets in the message;
store the created path; and
process subsequent packets in the message using
the sequence of routines indicated in the stored
path, wherein the sequence includes a routine
that is used to execute a Transmission Control
Protocol (TCP) to convert one or more packets
having a TCP format into a different format.

the Court, creates and stores a path indicating a
sequence of routines “based on information in
a received packet of information.” As
explained above, this sequence of routines is
created dynamically on or after receipt of the
packet. Claim 1 further processes “subsequent
packets in the message” using the created and

8. The first apparatus of claim 1, wherein the memory
stores instructions executable by the processing unit to
identify an address associated with the information,
wherein the address indicates the routines in the
sequence of routines of the created path.

stored path. Claim 8, which depends from
Claim 1, further identifies “an address
associated with the information, wherein the

9. The first apparatus of claim 8, wherein the memory
stores instructions executable by the processing unit to
use the address to select the sequence of routines from
a plurality of sequences of routines that are stored by
the first apparatus prior to receiving the packet of the
message.

address indicates the routines in the sequence
of routines of the created path.” Thus, (1) the
address is associated with the information in

the received packet that triggers creation of the sequence of routines and (2) the address indicates
the routines in the created sequence. Claim 9, which depends from Claim 8, recites using this
“address to select the sequence of routines from a plurality of sequences of routines that are stored
by the first apparatus prior to receiving the packet of the message.” Here, “prior to receiving the
packet of the message” establishes a time based on receiving the packet. The only reference in the
dependency chain to receiving a packet is Claim 1’s “received packet of a message.” Thus, it is
reasonably certain that Claim 9’s “the packet of the message” refers to Claim 1’s “received packet
of a message.”

26

This does not mean, however, that Claim 1’s “create … a path” limitation encompasses
merely selecting a preconfigured sequence of routines. As stated above, the patents explain that
the invention does not include using the prior-art approach of “pre-configured paths, which are
defined at ‘build-time’ before the first packet of a message is received.” ’163 Patent File Wrapper
September 1, 2009 Amendment and Response to Office Action in Ex Parte Reexamination
90/010,356 at 18 (Dkt. No. 103-1 at 18). The Court thus understands that Claim 9 is directed to
selecting pre-existing sequences to create the sequence of routines that constitutes the path. See
Phillips v. AWH Corp., 415 F.3d 1303, 1316 (Fed. Cir. 2005) (en banc) (“‘The construction that
stays true to the claim language and most naturally aligns with the patent's description of the
invention will be, in the end, the correct construction.’” (quoting Renishaw PLC v. Marposs
Societa' per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998))). The Court’s understanding comports
with the F5 Network II explanation that “the invention may rely in some part on ‘predefined
configuration information’” so long as “it does not identify the complete sequence of … routines
needed to process the packet until after a first packet of the message is received.” 2015 U.S. Dist.
LEXIS 60197, at *40–41.
Accordingly, the Court determines that Defendants have not established that “the packet
of the message” renders any claim indefinite.


“the packet of the message” means “the received packet of the message that was
used to create the path.”

27

A-5.

“list of conversion routines”

Disputed Term
“list of conversion routines”


’683 Patent Claim 10

Plaintiff’s Proposed
Construction
An ordered arrangement of
software routines for
changing data

Defendants’ Proposed
Construction
an ordered arrangement of
software routines for
converting data from one
format to another that was not
identified (i.e., configured)
prior to receiving a first
packet of the message

The Parties’ Positions
Plaintiff submits that for the same reasons “sequence of routines” should not be limited as
Defendants propose, “list of conversion routines” should not be limited as Defendants propose.
Dkt. No. 101 at 16.
Defendants respond that the disclaimer of preconfigured routines applies to “list of
conversion routines.” Dkt. No. 103 at 17. Defendants further respond that a “conversion routine”
of the ’683 Patent is not simply a routine for changing data, but rather is a routine for converting
data from on format to another format. Id. at 17–18.
In addition to the claims themselves, Defendants cite the following intrinsic evidence to
support their position: ’683 Patent col.2 ll.42–49, col.2 ll.61–65, col.4 ll.46–48; ’163 Patent File
Wrapper September 1, 2009 Amendment and Response to Office Action in Ex Parte
Reexamination 90/010,356 (Defendants’ Ex. 1, Dkt. No. 103-1), February 8, 2010 Amendment
and Response to Advisory Action in Ex Parte Reexamination 90/010,356 (Defendants’ Ex. 2, Dkt.
No. 103-2), October 23, 2009 Interview Summary in Ex Parte Reexamination 90/010,356
(Defendants’ Ex. 4, Dkt. No. 103-4).
Plaintiff replies that there is no disclaimer of preconfigured routines. Dkt. No. 106 at 9.
Plaintiff further replies that the ’683 Patent describes “converting” as changing the format and that
28

Defendants’ proposed construction is unhelpful as it simply rewrites “conversion” as “converting.”
Id.
Plaintiff cites further intrinsic evidence to support its position: ’683 Patent col.1 ll.31–44.
Analysis
There are two issues in dispute. First, whether the list of routines is necessarily identified
only after receipt of the first packet of the message. Second, whether the conversion routines
necessarily convert the format of the data. With respect to the first issue, the Court determines the
list of routines is dynamically generated as explained in the section on “sequence of routines”
above. With respect to the second issue, the Court determines that a conversion routine changes
the form or format of data, not merely the substance of the data.
As explained above, the invention of the ’683 Patent is directed to dynamic configuration
of conversion-processing sequences—and does not include preconfiguring the conversionprocessing sequence of routines. This applies equally to the conversion-processing “list of
conversion routines.”
A “conversion routine” is one that changes the form of data. As explained in the
“Background” section of the patents, data exchange among computers may require the data to take
on different forms at different points in the transport route. ’683 Patent col.1 l.24 – col.2 l.3. For
example, data to be transmitted may first be converted to a compressed-and-encrypted form. Id. at
col.1 ll.32–35. Then, the compressed-and-encrypted form of the data may be converted into a TCP
format and then from a TCP format to an IP format and then to an Ethernet format. Id. at col.1
ll.35–39. On receipt, the data may be converted back to the uncompressed-and-unencrypted form
and ultimately to the format appropriate for output on the computer. Id. at col.1 ll.39–44. While it
seems the parties agree the format of the data is changed by a conversion routine, it is unclear

29

whether Defendants intend “converting data from one format to another” to include changing the
form of the data through such as compression or encryption. Dkt. No. 103 at 20 (arguing that
compression is not application of a conversion routine). To make it clear that conversion routines
are not limited to converting among transport-layer formats and include form-changing processes
such as conversion, the Court adopts “changing the form of data.”
Accordingly, the Court construes “list of conversion routines” as follows:


“list of conversion routines” means “an ordered arrangement of software routines
for changing the form of data and that was not identified (i.e., configured) prior to
receiving a first packet of the message.”

B.

The Applet Patents
B-1.

“form of the application”

Disputed Term
“form of the application”


Plaintiff’s Proposed
Construction
plain and ordinary meaning

’685 Patent Claims 1, 3,
15, 18, 34, 49

Defendants’ Proposed
Construction
source, intermediate or binary
format of the application

The Parties’ Positions
Plaintiff submits that “form” is not synonymous with “format” and that the Applet Patents
allow that an application may come in a variety of forms. Dkt. No. 101 at 17. Plaintiff argues that
the patents allow for forms other than the formats enumerated in Defendants’ proposal. Id. For
example, Plaintiff contends that Claim 5 refers to “Java byte code” form, Claim 92 refers to
“compiled forms,” and Claim 95 refers to “Java source” form. Id. at 17–18.
In addition to the claims themselves, Plaintiff cites the following intrinsic evidence to
support its position: ’685 Patent col.3 ll.44–56.

30

Defendants respond that the Applet Patents and related prosecution-history statements
describe that the form of the application is one of source, intermediate, or binary format. Dkt. No.
103 at 22–24. Defendants argue that the patentee disclaimed any other interpretation of “form of
the application” in prosecuting U.S. Patent No. 7,774,740,4 which issued from an application in
the series of continuation applications connecting the Applet Patents. Id. at 22–23. According to
Defendants, “Java byte code” is in the intermediate format and the intermediate and binary formats
are both compiled forms, thus their proposed construction encompasses the forms recited in the
claims. Id. at 24.
In addition to the claims themselves, Defendants cite the following intrinsic evidence to
support their position: ’685 Patent fig.2A, col.3 ll.12–13, col.3 ll.16–26, col.3 ll.48–51, col.4 l.15,
col.4 l.36, col.4 l.60, col.5 ll.40–42, col.6 ll.29–33; U.S. Patent No. 7,774,740 File Wrapper
October 14, 2009 Office Action (Defendants’ Ex. 7, Dkt. No. 103-7), December 14, 2009
Response (Defendants’ Ex. 8, Dkt. No. 103-8).
Plaintiff replies that the Applet Patents distinguish “form” from “format” as well as
“compiled” from “intermediate” code and disclose that the application may be “any form of
program instructions,” so it would be improper to limit the “form of the application” to the three
exemplary formats. Dkt. No. 106 at 10–12. Plaintiff further replies that the prosecution-history
statements for U.S. Patent No. 7,774,740, when considered in context, are not a disclaimer of any
form other than the three exemplary formats and instead disclose a web page as a form of
application. Id. at 11.

U.S. Patent No. 7,774,740 is related to the ’685 Patent through a series of continuation
applications and the specifications of the two patents are therefore substantially identical except
for the claim sets. See ’779 Patent, at [63] Related U.S. Application Data.
4

31

Plaintiff cites further intrinsic evidence to support its position: ’685 Patent col.2 ll.39–45,
col.3 ll.10–13; U.S. Patent No. 7,774,740 File Wrapper December 14, 2009 Response
(Defendants’ Ex. 8, Dkt. No. 103-8).
Analysis
The issue with respect to this term is whether the “application” of the claims of the ’685
Patent can take on forms other than source, intermediate, or binary format. As the patent describes,
an application is necessarily either uncompiled, partially compiled, or compiled to run on the client
computer. These are, respectively, the source, intermediate, and binary formats of the patent. While
the application is necessarily in such format, it may take on multiple forms within those formats.
The “form” of an application is not coextensive with the application’s “format.” As
explained in the ’685 Patent, an applet, and by extension an application,5 is “any form of program
instructions.” ’685 Patent col.3 ll.10–15 (emphasis added). These instructions are limited to three
formats: (1) binary format, compiled for a specific processor, (2) intermediate format, compiled,
but not for a specific processor, and (3) source format, uncompiled. Id. at col.2 ll.25–44, col.3 ll.9–
27, col.3 ll.48–50, col.4 l.66 – col.5 l.14. While limited to three formats, the patent explains that
“[t]he form may be selected from a large matrix of many possible forms that can be recognized by
the system.” Id. at col.46–48. The Court does not understand that three formats constitute a “large
matrix.” The form includes format, but also includes factors such as whether it is verified,
optimized, or compressed. Id. at col.3 ll.44–56. The patents also explain that a request for an applet
“is made up of a series of tags which specify the requested applet, the platform on which it is to be
run and the type of code (source/intermediate/binary), a verification level and an optimization

The Court understands that under the parties’ agreed constructions of “application” and “applet,”
teachings in the Applet Patents regarding “applets” also apply to “applications.”
5

32

level.” Id. at col.6 ll.53–56. The Court understands “the platform on which it is to be run” is another
exemplary factor of the form of the application. This suggests that the “form” of an
applet/application depends on much more than the format (or “type of code” of the applet). Given
the number of exemplary form factors, the potential forms of an application may indeed constitute
a “large matrix.” Thus, while all application forms are necessarily restricted to three formats
(source/intermediate/binary), “form” and “format” are not coextensive.
Further, the patent describes changing the form of an applet without changing the format
of the applet. Specifically, the patent describes “transformers” that perform “transformation
operations.” Id. at col.3 l.64 – col.4 l.1. These transformers “are programs that take in intermediate
code and put out intermediate code.” Id. at col.5 ll.15–25. The transformers transform (change the
form) of the application without changing the format of the application (intermediate code). Id.
Again, this suggests that form is not defined exclusively by format.
The patentee’s statements in prosecution of a related application do not redefine “form” to
be coextensive with “format.” True, the patentee stated: “the Examiner has confused the ‘form’ of
the application in the present invention, i.e., whether it is source code, binary code or intermediate
code, with the FORM element of HTML discussed in Ferris.” U.S. Patent No. 7,774,740 File
Wrapper December 14, 2009 Response at 13 (Dkt. No. 103-8 at 13). In the context of other of the
patentee’s prosecution-statements and the shared disclosure of the Applet Patents, equating “form”
and “format” would be improper. For example, as discussed above, the ’685 Patent (and U.S.
Patent 7,774,740) teach transforming an application without changing its format. See, e.g., ’685
Patent col.5 ll.15–25. The patentee discussed this transformation when prosecuting U.S. Patent
No. 7,774,740. See, e.g., December 14, 2009 Response at 15 (Dkt. No. 103-8 at 15). Thus, in the
very prosecution response Defendants contend evinces that “form” and “format” are coextensive,

33

the patentee suggested that “form” and “format” are distinct. To the extent that the prosecutionhistory sentence Defendants cite equates “form” and “format,” that statement is clearly incorrect
and should be disregarded. See Biotec Biologische Naturverpackungen GmbH v. Biocorp, Inc.,
249 F.3d 1341, 1348 (Fed. Cir. 2001) (“A person of reasonable intelligence would not be misled
into relying on the erroneous statement [in the prosecution history], for it is contrary not only to
the plain language of the claims and the specification, but also to other statements in the same
prosecution document.”).
Accordingly, the Court determines that the “form of the application” is distinct from the
format of the application and “form of the application” has its plain and ordinary meaning without
the need for further construction.
B-2.

“resource”

Disputed Term
“resource”


Plaintiff’s Proposed
Construction
plain and ordinary meaning

Defendants’ Proposed
Construction
an application or applet

’740 Patent Claims 1, 19
The Parties’ Positions
Plaintiff submits that a “resource” is not limited to “an application or applet.” Dkt. No. 101

at 14. Plaintiff notes that Claim 10 of the ’740 Patent recites that “the resource is a web page” and
Claim 11 recites that “the resource is an application.” Id. at 19. Plaintiff contends that a “web page”
is neither an applet nor an application, so it would be improper to limit “resource” as Defendants
propose. Plaintiff also contends that Claim 11 would be rendered superfluous by Defendants’
construction. Id.
In addition to the claims themselves, Plaintiff cites the following extrinsic evidence to
support its position: W3C, HTML & CSS, https://www.w3.org/standards/webdesign/htmlcss.

34

Defendants respond that the described invention of the ’740 Patent (and all the Applet
Patents) is “an applet server computer that fills requests for ‘applets’ and ‘applications’” and
“resource” must be construed consistent with what the patents describe as the invention. Dkt. No.
103 at 24–27. Defendants argue that although Claim 10 states that the resource is a web page and
a web page is neither an application nor an applet, Claim 10 is not supported by the written
description. Id. at 16.
In addition to the claims themselves, Defendants cite the following intrinsic evidence to
support their position: ’685 Patent, at [57] Abstract, col.2 ll.10–14, col.2 l.66 – col.3 l.6, col.3
ll.29–34, col.6 ll.53–56.
Plaintiff replies that the plain meaning of “resource” is well understood, and is not limited
to applications and applets. Dkt. No. 106 at 12. Rather, in the context of the Applet Patents, a
“resource” is “any data object that may be referred to by a URL.” Id.
Plaintiff cites further intrinsic and extrinsic evidence to support its position: Intrinsic
evidence: ’740 Patent figs.2A, 2B, col.6 ll.63–66. Extrinsic evidence: Network Working Group,
Request for Comments 2068, Hypertext Transfer Protocol – HTTP/1.1 (Jan. 1997), available at
http://www.ietf.org/rfc/rfc2068.txt (Plaintiff’s Reply Ex. 2, Dkt. No. 106-2); Network Working
Group, Request for Comments 1738, Uniform Resource Locators (URL) (Dec. 1994), available at
https://www.ietf.org/rfc/rfc1738.txt (Plaintiff’s Reply Ex. 3, Dkt. No. 106-3).
Analysis
The issue in dispute is whether “resource” is limited to an application or applet. The Court
understands that while a resource necessarily includes an applet or application or code that can be
used to build an applet or application, it is not coextensive with an applet or application.

35

The “resources” described in the Applet Patents “are comprised of program modules 32
(applets in source form, not the requested form) and compilers 30.” ’685 Patent col.4 ll.34–35;
’740 Patent col.4 ll.54–56; see also, ’740 Patent at [57] Abstract (“local resources (program code
modules and compilers)”). These resources are used to construct applets. ’685 Patent col.3 l.64 –
col.4 l.16 (“the applet server manager 22 will attempt to build the requested applet from local
resources 26”), col.4 ll.40–41 (“Program modules 32 are program code used to build
applets.”);’740 Patent at col.4 ll.17–36, col.4 ll.60–61. The resources may be on the applet server
or they may be available on an external network. ’685 Patent at col.4 ll.10–17; ’740 Patent at col.4
ll.29–36. The resources contain the program-module code that can be used to build an applet. ’685
Patent at col.4 ll.41–43(“Program modules 32 may be stored in local resources 26 in source, binary,
or intermediate formats.”); ’740 Patent at col.4 ll.61–62.
The claims of the ’740 Patent are directed to providing applet source-code resources from
an external network, not just “any data object that may be referred to by a URL.” The ’740 Patent,
like all the Applet Patents, is directed to provision of applets/applications. See, e.g., ’740 Patent
col.2 ll.21–25 (“There is a need for a scalable distributed system architecture that provides a
mechanism for client computers to request and execute applets in a safe manner without requiring
the client machines to have local resources to compile or verify the code.”); see also, id. at [57]
Abstract (“An applet server accepts requests for applets from client computers.”). The term
“resources” must be understood in this context. Phillips v. AWH Corp., 415 F.3d 1303, 1316 (Fed.
Cir. 2005) (en banc) (“The claims are directed to the invention that is described in the specification;
they do not have meaning removed from the context from which they arose.” (quoting Netword,
LLC v. Centraal Corp., 242 F.3d 1347, 1352 (Fed. Cir. 2001))). Each claim of the ’740 Patent
recites “a resource, wherein the resource includes source code.” ’740 Patent col.7 ll.27–28 (Claim

36

1), col.8 ll.60–61 (Claim 19), col.9 ll.7–8 (Claim 20). Each claim further recites “conveying … a
request for the resource to an external network.” Id. at col.7 ll.31–32 (Claim 1), col.8 ll.64–65
(Claim 19), col.9 ll.11–12 (Claim 20). This claim language closely parallels the described
embodiments in which the server collects “local resources” from an external server to use those
resources to provide the application that client requests. Thus, while the resources may take on
various forms, such as a web page (Claim 10) or an application (Claim 11), the resources all
contain source code that comprises an application or applet or can be used to build an application
or applet.
Accordingly, the Court construes “resource” as follows:


“resource” means “data object containing code that: (1) is an application, (2) is an
applet, or (3) can be used to build an application or applet.”
B-3.

“generating the identified form of the application from another form
of the application” and “generated the identified form of the
application from another form of the application”

Disputed Term

Plaintiff’s Proposed
Construction

“generating the identified
form of the application from
another form of the
application”


’685 Patent Claims 1, 3,
15, 18

plain and ordinary meaning

“generated the identified form
of the application from
another form of the
application”


Defendants’ Proposed
Construction

building or producing the
form of the application from
local resources on the server
through the compilation of
one or more program code
modules using one or more
compilers, and optionally
applying one or more
transformation operations

’685 Patent Claims 34, 49
Because the parties’ arguments and proposed constructions with respect to these terms are

related, the Court addresses the terms together.
37

The Parties’ Positions
Plaintiff submits that the claims separately recite the “how and why” of “generating the
identified form” and such details should not be read into the construction of “generating the
identified form of the application from another form of the application” and “generated the
identified form of the application from another form of the application.” Dkt. No. 101 at 20.
Defendants respond that its proposed construction is the same construction that Plaintiff
proposed in a previous litigation and is as described in the Applet Patents. Dkt. No. 103 at 27–28
(citing Joint Claim Construction and Prehearing Statement, Implicit Networks, Inc. v. Sybase, Inc.
and Microsoft Corporation, No. 3:09-cv-1478-SI (N.D. Cal. Jan. 11, 2010), Dkt. No. 46 (Dkt. No.
103-9)). Specifically, Defendants contend that the patents describe generating the form
“necessarily involves the compilation of one or more program code modules using one or more
compilers.” Id. at 28.
In addition to the claims themselves, Defendants cite the following intrinsic evidence to
support their position: ’685 Patent col.3 ll.16–20, col.3 ll.24–27, col.3 l.57 – col.4 l.9, col.4 ll.56–
65.
Plaintiff replies that Defendants’ reliance on the Joint Claim Construction and Prehearing
Statement in the Microsoft litigation is misplaced because: (1) judicial estoppel does not apply
because Plaintiff’s positions were not adopted, and (2) the claims at issue here are distinct from
those at issue in Microsoft in that Claim 3 requires “requesting the application in the other form
from a computer other than the server computer” which contradicts the notion that the application
must be generated on the server. Dkt. No. 106 at 12–13.

38

Analysis
The issue in dispute here is whether generating the identified form of the application from
another form of the application necessarily entails building the form of the application from
resources on the server through compilation of program modules. It does not.
The ’685 Patent discloses multiple ways in which the server can provide the requested
application in the form requested. As explained in the Applet Patents, “[t]he request [for an applet]
is made up of a series of tags which specify the requested applet, the platform on which it is to be
run and the type of code (source/intermediate/binary), a verification level and an optimization
level.” ’685 Patent col.6 ll.53–56. The patent also provides compression as another exemplary
form factor. Id. at col.3 ll.50–53. The combination of such form factors specifies the “form” of the
applet (or application). On request for an applet/application, the server can identify an existing
application in its cache. Id. at col.3 l.57 – col.4 l.16. If no suitable applet/application exists, the
server can build one from local resources and transformers on the server. Id. It may also request
the applet/application, or the required resources and transformers, from an external network. Id.
Transformers are used to change the form of the applet/application but are distinct from
compilers—transformers change the form without changing the format as would the compiler. Id.
at col.4 l.66 – col.5 l.25 (explaining compilers and transformers); see also, id. at col.5 l.26–53
(verifier transformer), col.5 l.66 – col.6 l.6 (optimizer transformer). Thus, the patent contemplates
generating the requested form of an application, e.g., a verified application, by acquiring the
application from an external network and running it through a transformer, e.g., a verifier
transformer. Defendants’ proposed construction does not encompass this generation of the
requested form of the application.

39

Accordingly, the Court rejects Defendants’ proposed construction and determines that
“generating the identified form of the application from another form of the application” and
“generated the identified form of the application from another form of the application” each has
its plain and ordinary meaning without the need for further construction.
B-4.

“source code that is in a form based on the specified one or more
client parameters for the first client computer”

Disputed Term
“source code that is in a form
based on the specified one or
more client parameters for the
first client computer”


Plaintiff’s Proposed
Construction
plain and ordinary meaning

’779 Patent Claim 1, 18

Defendants’ Proposed
Construction
source code that has been
optimized, verified and/or
compressed based on the one
or more client parameters
specified in the received
applet request

The Parties’ Positions
Plaintiff submits there is no support for limiting the form of the source code to one “that
has been optimized, verified and/or compressed.” Dkt. No. 101 at 20–21.
Defendants respond that the only relevant client parameters described in the Applet Patents
refer to the transformation operations, and the only transformation operations disclosed are
optimization, verification, and compression. Dkt. No. 103 at 31–32.
In addition to the claims themselves, Defendants cite the following intrinsic evidence to
support their position: ’685 Patent col.6 ll.7–12.
Plaintiff replies that claims do not recite variants of “optimize,” “verify,” or “compressed”
and it would be improper to limit the claims to require such. Dkt. No. 106 at 13.
Analysis
The issue here is whether the form of source code based on client parameters is limited to
optimized, verified, or compressed. It is not.
40

While the Applet Patents describe that the client may specify optimization, verification, or
compression, the patents do not limit client parameters to those three. As explained in the patents,
“[t]he request [for and applet] is made up of a series of tags which specify the requested applet,
the platform on which it is to be run and the type of code (source/intermediate/binary), a
verification level and an optimization level.” ’685 Patent col.6 ll.53–56; ’779 Patent col.7 ll.18–
21. The patents also provide compression as another exemplary form factor. ’685 Patent col.3
ll.50–53; ’779 Patent col.4 ll.19–23. Notably absent from Defendants list of limitations is the
exemplary “platform on which it is to be run.” This is important to understand Claim 3 of the ’779
Patent, which recites “wherein the form of the source code is suitable for running on the first client
computer.” ’779 Patent col.7 ll.56–57. Further, the patents provide that “[v]erification,
optimization and compression are examples of types of transformation operations.” ’685 Patent
col.3 ll.52–53; ’779 Patent col.4 ll.21–23. Even without mention of the “platform on which it is to
be run,” it would be improper to limit the claims to transformation operations, and their associated
client parameters, to a items expressly labeled as “examples.” See Thorner v. Sony Computer
Entm't Am., LLC, 669 F.3d 1362, 1367 (Fed. Cir. 2012) (“The patentee is free to choose a broad
term and expect to obtain the full scope of its plain and ordinary meaning unless the patentee
explicitly redefines the term or disavows its full scope.”). Simply, the Applet Patents do not limit
the list of client parameters as Defendants contend.
Accordingly, the Court rejects Defendants’ proposed construction and determines that the
term has its plain and ordinary meaning without the need for further construction.

41

B-5.

“a specific form of the particular applet that includes source code,
based on the specified one or more parameters in the applet request,
wherein the specific form complies with the specified one or more
parameters”

Disputed Term
“a specific form of the
particular applet that includes
source code, based on the
specified one or more
parameters in the applet
request, wherein the specific
form complies with the
specified one or more
parameters”


Plaintiff’s Proposed
Construction
plain and ordinary meaning

Defendants’ Proposed
Construction
applet that includes source
code that has been optimized,
verified and/or compressed
based on the one or more
client parameters specified in
the received applet request

’779 Patent Claim 12
The Parties’ Positions
Plaintiff submits there is no support for limiting the form of the applet’s source code to one

“that has been optimized, verified and/or compressed.” Dkt. No. 101 at 22.
Defendants respond that the only relevant client parameters described in the Applet Patents
refer to the transformation operations, and the only transformation operations disclosed are
optimization, verification, and compression. Dkt. No. 103 at 32–33.
Plaintiff replies that claims do not recite variants of “optimize,” “verify,” or “compressed”
and it would be improper to limit the claims to require such. Dkt. No. 106 at 13–14.
Analysis
The issue in dispute here is the same as addressed in the section on “source code that is in
a form based on the specified one or more client parameters for the first client computer.” For the
same reasons given in that section, the Court rejects Defendants’ proposed construction and
determines that the term has its plain and ordinary meaning without the need for further
construction.
42

B-6.

“transformation operation”

Disputed Term
“transformation operation”



’779 Patent Claim 16
’740 Patent Claims 1, 19

Plaintiff’s Proposed
Construction
an operation that analyzes
and/or modifies code,
including for example
through verification,
optimization, or compression

Defendants’ Proposed
Construction
an operation that verifies,
optimizes or compresses code
within an application or
applet

The Parties’ Positions
Plaintiff submits the “transformation operation” of the Applet Patents encompasses more
than verification, optimization, or compression. Dkt. No. 101 at 23. Plaintiff argues that the patents
expressly state that these three transformations are exemplary: “[v]erification, optimization, and
compression are examples of types of transformation operations.” Id. (quoting ’779 Patent col.4
ll.19–25).
In addition to the claims themselves, Plaintiff cites the following intrinsic evidence to
support its position: ’779 Patent col.4 ll.19–25, col.5 ll.51–61.
Defendants respond that all transformation operations described in the Applet Patents
operate on code. Dkt. No. 103 at 29–30. Defendants contend that the described transformations
are limited to verification, optimization, and compression that involves code-level evaluation. Id.
at 30–31.
In addition to the claims themselves, Defendants cite the following intrinsic evidence to
support their position: ’685 Patent col.5 ll.15–20; ’779 Patent col.4 ll.19–25, col.5 ll.51–61.
Plaintiff replies that the “transformation operation” of Claims 1 and 19 of the ’740 Patent
applies to a “resource” rather than “an application or applet” so it would be improper to limit the
transformation operation to applications or applets. Dkt. No. 106 at 14.

43

Analysis
There are two issues in dispute. First, whether a “transformation operation” is necessarily
limited to verification, optimization, or compression. Second, whether the “transformation
operation” is necessarily limited to applets and applications. With respect to the first issue,
transformation operations are not so limited. With respect to the second issue, transformation
operations may operate on any code, whether the code is stand-alone, associated with a larger
application, or otherwise.
As explained above in the section on “source code that is in a form based on the specified
one or more client parameters for the first client computer,” verification, optimization, and
compression are provided as exemplary transformation operations, not as an exhaustive list of
operations. ’685 Patent col.3 ll.52–53 (“Verification, optimization and compression are examples
of types of transformation operations.”) The Court will not limit transformation operations to this
list of “examples.”
The Applet Patents teach that transformation operations may be applied to applets and
applications as well as to program modules that are used to build applets. ’685 Patent col.3 l.44 –
col.4 l.16. The program modules are code fragments that may be combined to create an applet.
See, e.g., id. at col.4 ll.3–6 (“The requested applet is built by selecting one or more program code
modules 32 and compiling them with one or more compilers 30.”), col.4 ll.40–41 (“Program
modules 32 are program code used to build applets.”). These modules may be “transformed” to
put in a suitable form. See, e.g., id. at col.4 ll.56–65. Thus, transformation operations may be
performed on code that can be used to build applets or applications, and not merely on applets or
applications themselves.

44

Transformation operations require modification of code. The Applet Patents describe a
verifier transformer “that is able to analyze input code and determine areas that might not be safe.”
Id. at col.5 ll.26–27. While the transformer may be capable of performing an “analyze” operation
without transforming code, that capability does not define the verifier’s transformation operation.
Rather, the transformation operation performed by the verifier occurs once it “determines the
portion of the unsafe applet code.” Id. at col.5 ll.31–40. For example, the verifier may modify the
code such that the “offending portion of the code can be encased with new code that specifically
prevents this unsafe code from being executed.” Id. at col.5 ll.32–35. Or the code may be modified
such that “unsafe code [is] flagged in such a way that a user can be warned about the possible risks
of executing the code fragment.” Id. at col.5 ll.35–38. Ultimately, “[v]erifiers 48 are responsible
for identifying non-secure portions of code in the intermediate code and modifying this code to
make it secure.” Id. at col.5 ll.48–50. That is, the transformation operation of the verifier, like all
transformation operations, transforms code by modifying the code.
Accordingly, the Court is not persuaded that the term should be limited as Defendants
contend and construes “transformation operation” as follows:

V.

“transformation operation” means “operation that modifies code.”

CONCLUSION
The Court adopts the constructions set forth above, as summarized in the following table.

The parties are ORDERED that they may not refer, directly or indirectly, to each other’s claim
construction positions in the presence of the jury. Likewise, the parties are ORDERED to refrain
from mentioning any portion of this opinion, other than the actual definitions adopted by the Court,
in the presence of the jury. Any reference to claim construction proceedings is limited to informing
the jury of the definitions adopted by the Court.

45

So Ordered this
Mar 29, 2017

46