Implicit, LLC v. NETSCOUT Systems, Inc.
Filing
111
CLAIM CONSTRUCTION MEMORANDUM AND ORDER. Signed by District Judge Rodney Gilstrap on 4/15/2019. (ch, )
THE UNITED STATES DISTRICT COURT
FOR THE EASTERN DISTRICT OF TEXAS
MARSHALL DIVISION
IMPLICIT, LLC,
v.
NETSCOUT SYSTEMS, INC., et al.
§
§
§
§
§
§
CASE NO. 2:18-CV-53-JRG
CLAIM CONSTRUCTION
MEMORANDUM AND ORDER
Before the Court is the Opening Claim Construction Brief (Dkt. No. 89) filed by Plaintiff
Implicit, LLC (“Plaintiff” or “Implicit”). Also before the Court are Defendants NetScout Systems,
Inc. and Sandvine Corp.’s (“Defendants’”) Responsive Claim Construction Brief (Dkt. No. 93)
and Plaintiff’s reply (Dkt. No. 96).
The Court held a claim construction hearing on April 11, 2019.
Table of Contents
I. BACKGROUND ....................................................................................................................... 2
II. LEGAL PRINCIPLES ........................................................................................................... 3
III. AGREED TERMS................................................................................................................. 7
IV. DISPUTED TERMS .............................................................................................................. 8
A. “sequence of [two or more] routines” ................................................................................... 8
B. “list of conversion routines”................................................................................................ 14
C. “state information” .............................................................................................................. 15
D. “process subsequent packets in the message using the sequence of routines indicated in
the stored path” and Related Terms .................................................................................... 19
E. “the packet of the message” ................................................................................................ 20
F. “convert one or more packets having a TCP format into a different format” and Related
Terms .................................................................................................................................. 23
G. “execute a Transmission Control Protocol (TCP)” and Related Terms ............................. 29
V. CONCLUSION...................................................................................................................... 36
-1-
I. BACKGROUND
Plaintiff has alleged infringement of United States Patents No. 8,694,683 (“the ’683
Patent”), 9,270,790 (“the ’790 Patent”), and 9,591,104 (“the ’104 Patent”) (collectively referred
to as “the patents-in-suit,” “the Balassanian Patents,” or “the Demulitplexing Patents”). (See Dkt.
No. 89, Exs. 1‒3.) Plaintiff submits that the patents-in-suit relate to computer networking. (See
Dkt. No. 89, at 1–2.)
The ’683 Patent, for example, titled “Method and System for Data Demultiplexing,” issued
on April 8, 2014, and bears an earliest priority date of December 29, 1999. The ’790 Patent is a
continuation of the ’683 Patent. The ’104 Patent, in turn, is a continuation of the ’790 Patent.
These patents therefore share a common specification. The Abstract of the ’683 Patent states:
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 Court previously construed terms in the ’683 Patent, the ’790 Patent, and the ’740
Patent in Implicit, LLC v. Trend Micro, Inc., No. 6:16-CV-80, Dkt. No. 115, 2017 WL 1190373
(E.D. Tex. Mar. 29, 2017) (Gilstrap, J.) (“Trend Micro”) and in Implicit, LLC v. Huawei
Technologies USA, Inc., et al., 6:17-CV-182, 2018 WL 1169137 (E.D. Tex. Mar. 6, 2018)
(Gilstrap, J.) (“Huawei,” sometimes referred to as “PAN,” which is an acronym for Palo Alto
Networks, Inc., the only remaining defendant in the Huawei case at the time of the claim
construction hearing).
-2-
The ’683 Patent has also been the subject of claim construction in the Northern District of
California in Implicit Networks, Inc. v. F5 Networks, Inc., No. 3:14-CV-2856, Dkt. No. 57, 2015
WL 2194627 (N.D. Cal. May 6, 2015) (Illston, J.) (“F5 Networks II”). Further, the Northern
District of California construed terms in an ancestor patent, United States Patent No. 6,629,163
(“the ’163 Patent”),1 in Implicit Networks, Inc. v. F5 Networks, Inc., No. 3:10-CV-3365, Dkt. No.
93, 2012 WL 669861 (N.D. Cal. Feb. 29, 2012) (Illston, J.) (“F5 Networks I”). Defendants also
submit that the ’163 Patent was the subject of ex parte Reexamination No. 90/010,356 (“’163
ex parte Reexam”) and inter partes Reexamination No. 95/000,659 (“’163 inter partes Reexam”).
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with
preliminary constructions with the aim of focusing the parties’ arguments and facilitating
discussion. Those preliminary constructions are noted below within the discussion for each term.
II. LEGAL PRINCIPLES
It is understood that “[a] claim in a patent provides the metes and bounds of the right which
the patent confers on the patentee to exclude others from making, using or selling the protected
invention.” Burke, Inc. v. Bruno Indep. Living Aids, Inc., 183 F.3d 1334, 1340 (Fed. Cir. 1999).
Claim construction is clearly an issue of law for the court to decide. Markman v. Westview
Instruments, Inc., 52 F.3d 967, 970–71 (Fed. Cir. 1995) (en banc), aff’d, 517 U.S. 370 (1996).
“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.” Teva Pharms.
USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 841 (2015) (citation omitted). “In cases where those
subsidiary facts are in dispute, courts will need to make subsidiary factual findings about that
1
The patents-in-suit all resulted from continuations of the ’163 Patent.
-3-
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.”
Id. (citing 517 U.S. 370).
To ascertain the meaning of claims, courts look to three primary sources: the claims, the
specification, and the prosecution history. Markman, 52 F.3d at 979. The specification must
contain a written description of the invention that enables one of ordinary skill in the art to make
and use the invention. Id. A patent’s claims must be read in view of the specification, of which
they are a part. Id. For claim construction purposes, the description may act as a sort of dictionary,
which explains the invention and may define terms used in the claims. Id. “One purpose for
examining the specification is to determine if the patentee has limited the scope of the claims.”
Watts v. XL Sys., Inc., 232 F.3d 877, 882 (Fed. Cir. 2000).
Nonetheless, it is the function of the claims, not the specification, to set forth the limits of
the patentee’s invention. Otherwise, there would be no need for claims. SRI Int’l v. Matsushita
Elec. Corp., 775 F.2d 1107, 1121 (Fed. Cir. 1985) (en banc). The patentee is free to be his own
lexicographer, but any special definition given to a word must be clearly set forth in the
specification. Intellicall, Inc. v. Phonometrics, Inc., 952 F.2d 1384, 1388 (Fed. Cir. 1992).
Although the specification may indicate that certain embodiments are preferred, particular
embodiments appearing in the specification will not be read into the claims when the claim
language is broader than the embodiments. Electro Med. Sys., S.A. v. Cooper Life Sciences, Inc.,
34 F.3d 1048, 1054 (Fed. Cir. 1994).
This Court’s claim construction analysis is substantially guided by the Federal Circuit’s
decision in Phillips v. AWH Corporation, 415 F.3d 1303 (Fed. Cir. 2005) (en banc). In Phillips,
the court set forth several guideposts that courts should follow when construing claims. In
-4-
particular, the court reiterated that “the claims of a patent define the invention to which the patentee
is entitled the right to exclude.” Id. at 1312 (quoting Innova/Pure Water, Inc. v. Safari Water
Filtration Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). To that end, the words used in a claim
are generally given their ordinary and customary meaning. Id. The ordinary and customary
meaning of a claim term “is the meaning that the term would have to a person of ordinary skill in
the art in question at the time of the invention, i.e., as of the effective filing date of the patent
application.” Id. at 1313. This principle of patent law flows naturally from the recognition that
inventors are usually persons who are skilled in the field of the invention and that patents are
addressed to, and intended to be read by, others skilled in the particular art. Id.
Despite the importance of claim terms, Phillips made clear that “the person of ordinary
skill in the art is deemed to read the claim term not only in the context of the particular claim in
which the disputed term appears, but in the context of the entire patent, including the
specification.” Id. Although the claims themselves may provide guidance as to the meaning of
particular terms, those terms are part of “a fully integrated written instrument.” Id. at 1315
(quoting Markman, 52 F.3d at 978). Thus, the Phillips court emphasized the specification as being
the primary basis for construing the claims. Id. at 1314–17. As the Supreme Court stated long
ago, “in case of doubt or ambiguity it is proper in all cases to refer back to the descriptive portions
of the specification to aid in solving the doubt or in ascertaining the true intent and meaning of the
language employed in the claims.” Bates v. Coe, 98 U.S. 31, 38 (1878). In addressing the role of
the specification, the Phillips court quoted with approval its earlier observations from Renishaw
PLC v. Marposs Societa’ per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998):
Ultimately, the interpretation to be given a term can only be determined and
confirmed with a full understanding of what the inventors actually invented and
intended to envelop with the claim. The construction that stays true to the claim
-5-
language and most naturally aligns with the patent’s description of the invention
will be, in the end, the correct construction.
Phillips, 415 F.3d at 1316. Consequently, Phillips emphasized the important role the specification
plays in the claim construction process.
The prosecution history also continues to play an important role in claim interpretation.
Like the specification, the prosecution history helps to demonstrate how the inventor and the
United States Patent and Trademark Office (“PTO”) understood the patent. Id. at 1317. Because
the file history, however, “represents an ongoing negotiation between the PTO and the applicant,”
it may lack the clarity of the specification and thus be less useful in claim construction proceedings.
Id. Nevertheless, the prosecution history is intrinsic evidence that is relevant to the determination
of how the inventor understood the invention and whether the inventor limited the invention during
prosecution by narrowing the scope of the claims. Id.; see Microsoft Corp. v. Multi-Tech Sys.,
Inc., 357 F.3d 1340, 1350 (Fed. Cir. 2004) (noting that “a patentee’s statements during
prosecution, whether relied on by the examiner or not, are relevant to claim interpretation”).
Phillips rejected any claim construction approach that sacrificed the intrinsic record in
favor of extrinsic evidence, such as dictionary definitions or expert testimony. The en banc court
condemned the suggestion made by Texas Digital Systems, Inc. v. Telegenix, Inc., 308 F.3d 1193
(Fed. Cir. 2002), that a court should discern the ordinary meaning of the claim terms (through
dictionaries or otherwise) before resorting to the specification for certain limited purposes.
Phillips, 415 F.3d at 1319–24. According to Phillips, reliance on dictionary definitions at the
expense of the specification had the effect of “focus[ing] the inquiry on the abstract meaning of
words rather than on the meaning of claim terms within the context of the patent.” Id. at 1321.
Phillips emphasized that the patent system is based on the proposition that the claims cover only
the invented subject matter. Id.
-6-
Phillips does not preclude all uses of dictionaries in claim construction proceedings.
Instead, the court assigned dictionaries a role subordinate to the intrinsic record. In doing so, the
court emphasized that claim construction issues are not resolved by any magic formula. The court
did not impose any particular sequence of steps for a court to follow when it considers disputed
claim language. Id. at 1323–25. Rather, Phillips held that a court must attach the appropriate
weight to the intrinsic sources offered in support of a proposed claim construction, bearing in mind
the general rule that the claims measure the scope of the patent grant.
In general, prior claim construction proceedings involving the same patents-in-suit are
“entitled to reasoned deference under the broad principals of stare decisis and the goals articulated
by the Supreme Court in Markman, even though stare decisis may not be applicable per se.”
Maurice Mitchell Innovations, LP v. Intel Corp., No. 2:04-CV-450, 2006 WL 1751779, at *4 (E.D.
Tex. June 21, 2006) (Davis, J.); see TQP Development, LLC v. Intuit Inc., No. 2:12-CV-180, 2014
WL 2810016, at *6 (E.D. Tex. June 20, 2014) (Bryson, J.) (“[P]revious claim constructions in
cases involving the same patent are entitled to substantial weight, and the Court has determined
that it will not depart from those constructions absent a strong reason for doing so.”); see also Teva
Pharm. USA, Inc. v. Sandoz, Inc., 135 S. Ct. 831, 839–40 (2015) (“prior cases will sometimes be
binding because of issue preclusion and sometimes will serve as persuasive authority”) (citation
omitted); Finisar Corp. v. DirecTV Grp., Inc., 523 F.3d 1323, 1329 (Fed. Cir. 2008) (noting “the
importance of uniformity in the treatment of a given patent”) (quoting Markman v. Westview
Instruments, Inc., 517 U.S. 370, 390 (1996)).
III. AGREED TERMS
The parties have submitted the following agreed-upon construction (Dkt. No. 85, at p. 2 of
5; Dkt. No. 89, at 4), which the Court adopts:
-7-
Term
“message”
Construction
“a collection of data that is related in some way, such as a
stream of video or audio data or an email message”
IV. DISPUTED TERMS
A. “sequence of [two or more] routines”
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
“an ordered arrangement of [two or more]
software routines that was not identified (i.e.,
configured) prior to receiving a first packet of
a message”2
“an ordered arrangement of two or more
software routines that was not selected (or
found or picked) from a finite set of possible
arrangements which were created before
receiving a first packet of the message”
(Dkt. No. 85, Ex. B, at p. 2 of 35; Dkt. No. 89, at 5; Dkt. No. 93, at 1; Dkt. No. 103, Ex. A, at 1.)
The parties submit that this term appears in Claims 1, 4, 5, 8, 9, and 24 of the ’683 Patent, Claims
1, 3, 4, 5, 8, 10, 12, 15, 17, and 18 of the ’790 Patent, and Claims 1, 3, 5, 10, 12, 13, and 16 of the
’104 Patent. (Dkt. No. 103, Ex. A, at 1–10.)
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with
the following preliminary construction: “an ordered arrangement of [two or more] software
routines that was not configured before receiving a first packet of a message.”
(1) The Parties’ Positions
Plaintiff submits that the proper construction for this term has been thoroughly addressed
in prior litigation and, moreover, “NetScout and Sandvine seek to limit the claims to an
impossibility.” (Dkt. No. 89, at 5.)
Plaintiff previously proposed: “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.” (Dkt. No. 85, Ex. A, at 1.)
2
-8-
Defendants respond that “[t]his term is limited in scope by a disclaimer in the prosecution
history.” (Dkt. No. 93, at 1.) Defendants argue that “Implicit’s interpretation of the F5 [Networks]
II construction seeks to recapture the same claim scope it clearly and unambiguously disclaimed
– i.e., selecting from pre-configured paths – and should not be adopted.” (Id., at 5.) Defendants
also submit that “Defendants are amenable to removing the word ‘possible’ from [their] proposal
to remove any redundancy.” (Id., at 10.)3
Plaintiff replies that “[f]our prior courts have limited the . . . disclaimer to only the single
embodiment that stored pre-configured sequences of routines.” (Dkt. No. 96, at 1.) Plaintiff also
submits that “Implicit perceives no meaningful distinction between Defendants’ use of the word
‘selected’ and the Court’s use of the phrase ‘identified (i.e., configured).’” (Id., at 2.) Plaintiff
argues that “Defendants have cobbled together a construction that lacks clarity, results in
impossible scenarios, and is internally inconsistent.” (Id., at 3.)
At the April 11, 2019 hearing, Defendants expressed concern that the word “configured”
in the Court’s preliminary construction might be misinterpreted as allowing for identifying preexisting paths. Plaintiff responded that the word “configured” is sufficiently clear, and Plaintiff
argued that Defendants’ concerns relate to questions of fact regarding infringement rather than any
legal question for claim construction.
(2) Analysis
The Background section of the specification provides context by stating: “A computer
system in certain situations . . . can be expected to receive data and to provide data in many
3
Defendants have also cited Rule 30(b)(6) testimony by one of the named inventors (see Dkt. No. 93, Ex. 11, June 5,
2018 Balassanian dep. at 71:13–23, 72:12–73:10 & 74:6–77:5; see also id. at 47:13–48:18, 72:8–25 & 94:15–18), but
this testimony does not significantly affect the Court’s analysis in these claim construction proceedings. Cf.
Howmedica Osteonics Corp. v. Wright Med. Tech., Inc., 540 F.3d 1337, 1346–47 (Fed. Cir. 2008) (noting that inventor
testimony is “limited by the fact that an inventor understands the invention but may not understand the claims, which
are typically drafted by the attorney prosecuting the patent application”).
-9-
different formats that may not be known until the data is received. The overhead of statically
providing each possible series of conversion routines is very high.” ’683 Patent at 1:54–59. Claim
1 of the ’683 Patent, for example, recites (emphasis added):
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.
In F5 Networks II, the Northern District of California construed “sequence of routines” to
mean a “sequence of software routines that was not identified (i.e., configured) prior to receiving
a first packet of the message.” F5 Networks II at 17–24.
In Trend Micro, the Court construed “sequence of routines” to mean “an ordered
arrangement of software routines that was not identified (i.e., configured) prior to receiving a first
packet of the message” and similarly construed “sequence of two or more routines” to mean “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.” Trend Micro at 13–20.
In Huawei, the parties there agreed that “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.” Huawei at 8.
- 10 -
Those prior constructions focused on the patentee’s statements regarding the “Mosberger”
reference during reexamination of the ’163 Patent.4 The parties here agree that the patentee’s
statements amount to a disclaimer, but the parties dispute how that disclaimer should be given
effect in the Court’s construction.
In particular, the parties dispute the meaning of the phrase “identified (i.e., configured)” in
the prior constructions. When distinguishing Mosberger, the patentee argued:
The following discussion of Mosberger will assist the Examiner in understanding
the patentable distinctions, including those distinctions that arise because the
Mosberger system configures paths (formed from a sequence of components)
before receiving the “first packet of the message.” As shown below, the quoted
claim language is directed to a much different system that configures paths at runtime (i.e., after the first packet is received).
***
Because Mosberger teaches to configure paths that define the sequence of software
modules used to process particular types of data prior to “build-time,” the only
decision made at runtime is the determination of which pre-configured path should
begin processing the incoming data. Once the path is chosen, it is instantiated (what
Mosberger refers to as “path creation”). The process of recognizing which
preconfigured paths to use is illustrated in Figure 3.6 of Mosberger, reproduced
below.
As seen in Figure 3.6 above (cited by the Examiner), there are a number of
pathways (p1-p5) for the data to travel, but the selection of modules for each path
is configured before receipt of the message packets. The beginning point for the
F5 Networks I and F5 Networks II identified the “Mosberger” reference as: “David Mosberger, ‘Scout: A Path-Based
Operating System,’ Doctoral Dissertation Submitted to the University of Arizona.” F5 Networks I at 3; F5 Networks
II at 3.
4
- 11 -
paths in this example is with the Ethernet module (“ETH”). The ETH module
“employs a classifier to decide whether a packet should be processed using path p1,
p2, or p3.” (Mosberger, page 87). The only variation in Mosberger is which path
through the predefined sequence will be taken. In this example, the ETH module
selects the initial pathway (i.e., pathway p1, p2, or p3) based on the protocol header
in the first packet of the message. (Mosberger, pages 88-89). If the protocol header
is completely intact and suggests that the packet is UDP, then the packet
classification process will result in the selection of pre-configured path 1. If,
however, the packet has been fragmented by IP and does not include higher level
headers, then the classification process will result in selection of pre-configured
path 2. (Mosberger, page 87). At that point, after the packet has been reassembled,
the IP module’s packet classifier will determine whether the packet is a UDP or
TCP packet and route the packet accordingly (i.e., down preconfigured path 4 or
pre-configured path 5). (Mosberger, page 87). Importantly, however, those
sequences of IP-UDP via pathway p4 and IP-TCP via pathway p5 have also been
identified prior to run-time. In other words, the p2/p4 path and the p2/p5 path are
pre-configured at build time. Again, the only question resolved at run time is which
preconfigured path – with predetermined sequences of modules – should be
selected.
***
As one skilled in the art will appreciate, the [Mosberger] pseudo-code shows that
the possible list of software modules is already predetermined for the example
module [i.e., software routine] and that the only choice for the example module is
to select from amongst several possible pre-defined paths. Thus, dynamic routing,
as described in the context of the ‘paths’ in Mosberger, is essentially a series of
‘If...Then...’ computer instructions coded into the modules at build time that control
the selection of the predefined paths through a series of predefined software
modules that a developer has arranged in a module graph in such a way as to ensure
their interface compatibility.
(Dkt. No. 93, Ex. 12, Sept. 1, 2009 Amendment and Response to Office Action Mailed July 7,
2009, at 11 & 14–15; see id. at 20 (“During operation (i.e., at ‘run time’), Mosberger simply
recognizes which of the predefined pathways will be used to process the data packets”) & 28 (“a
routing decision in Mosberger is merely a selection between multiple predefined pathways”).)
In a subsequent Interview Summary, the patentee stated:
By selecting the sequence of components that form the path at build-time (i.e.,
before receiving a packet), Mosberger does exactly the opposite of what is claimed,
namely, affirmatively selecting the sequence of components after receiving a
packet. This is the difference between a dynamic system (the ’163 invention) and
- 12 -
a static, inflexible system (Mosberger) that merely selects – at run-time – previously
created paths. In response to a question by Examiner Ferris, lmplict’s counsel
pointed out that Mosberger’s selection of pre-configured paths after receiving a
packet is not covered by the claims because, by definition, Mosberger has already
identified the sequence of components at that point, and therefore, does not perform
the claimed “identifying” after receiving the packet.
(Id., Ex. 14, Oct. 23, 2009 Interview Summary, at 3.)
The patentee later similarly stated:
Importantly, this set of paths is finite; Mosberger does not teach to create new paths
after initialization. Further, this set of paths is created before any message/packet
is received.
***
Thus, paths in Mosberger are not dynamically created based on the receipt of a
message. Rather, Mosberger teaches that when a message is received, a path is
selected (or “found”) from a set of possible paths, which were created and
predefined before the message was even received.
(Id., Ex. 15, Feb. 8, 2019 Amendment, at 16 (citations omitted).)
During prosecution of the ’683 Patent, the patentee likewise stated:
[T]his set of paths is finite; Mosberger does not teach creation of new paths after
initialization.
***
. . . Mosberger teaches that when a message is received, a path is selected (or
“found” or “picked”) from a set of possible paths, which were created before the
message was received.
(Id., Ex. 13, June 6, 2013 Preliminary Amendment, at 11 & 12.)
The parties essentially agree as to the substantive effect of the patentee’s statements
regarding Mosberger. The patentee did not disclaim the existence of software routines prior to
receiving a first packet of the message. The patentee explained that the claimed invention uses
software routine arrangements that were not created prior to receiving a first packet of the
message. The construction of “sequence of [two or more] routines” can be refined to avoid the
- 13 -
potential confusion that might arise from the phrase “identified (i.e., configured)” and to more
clearly reflect the patentee’s statements regarding Mosberger.
Although the specification
frequently uses the words “identify,” “identifies,” and “identified,”5 using the word “created” will
more clearly reflect the patentee’s statements regarding Mosberger and will be more readily
understandable in the context of the claims.
The Court therefore hereby construes “sequence of [two or more] routines” to mean “an
ordered arrangement of [two or more] software routines that was not selected from a set of
arrangements created before receiving a first packet of the message.”
B. “list of conversion routines”
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
“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 a message”6
“an ordered arrangement of two or more
software conversion routines that was not
selected (or found or picked) from a finite set
of possible arrangements which were created
before receiving a first packet of the message”
(Dkt. No. 85, Ex. B, at p. 2 of 35; Dkt. No. 89, at 8; Dkt. No. 103, Ex. A, at 10.) The parties submit
that this term appears in Claim 10 of the ’683 Patent. (Id.)
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with
the following preliminary construction: “an ordered arrangement of software routines that is for
changing the form of data and that was not configured before receiving a first packet of the
message.”
See, e.g., ’683 Patent at 4:15–17 (“The demux routine may in tu[rn] invoke the label map get routine 104 to identify
a sequence of conversion routines for processing the packet.”) (emphasis added); id. at 8:38–44 (“The routine loops
identifying the next binding (edge and protocol) that is to process the message and ‘nailing’ the binding to a session
for the message, if not already nailed.”); id. at 10:42–51 (“If there is no next binding, then the routine invokes the
routine label map get to identify the list of edges (‘trails’) that will map the output label to the target label.”).
5
Plaintiff previously proposed: “an ordered arrangement of software routines for changing the form of data that was
not identified (i.e., configured) prior to receiving a first packet of the message.” (Dkt. No. 85, Ex. A, at 1.)
6
- 14 -
(1) The Parties’ Positions
Plaintiff states that it “is willing to agree to the NetScout/Sandvine language ‘software
conversion routines.’” (Dkt. No. 89, at 8.) Plaintiff submits that the other disputes regarding this
term will be resolved by construction of the “sequence of [two or more] routines” term addressed
above. (Id.)
Defendants respond as to this term together with the term “sequence of [two or more]
routines” (addressed above). (See Dkt. No. 93, at 1–11.)
(2) Analysis
The parties have presented substantially the same dispute for the term “list of conversion
routines” as for the term “sequence of [two or more] routines,” which is addressed above.
The Court therefore hereby construes “list of conversion routines” to mean “an ordered
arrangement of software conversion routines that was not selected from a set of
arrangements created before receiving a first packet of the message.”
C. “state information”
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
“information specific to a software routine for “information specific to a software routine for
a specific message that is not information a specific message that is maintained for all
related to an overall path”7
packets of the message and that is not
information related to an overall path”
(Dkt. No. 85, Ex. A, at 3; id., Ex. B, at p. 33 of 35; Dkt. No. 93, at 23 (emphasis Defendants’);
Dkt. No. 103, Ex. A, at 11.) The parties submit that this term appears in Claim 5 of the ’683 Patent
and Claims 1, 10, and 16 of the ’104 Patent. (Id., at 11–14.)
7
Plaintiff previously proposed: “Plain and ordinary meaning. No construction necessary.” (Dkt. No. 85, Ex. A, at 3.)
- 15 -
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with
the following preliminary construction: “information specific to a software routine for a specific
message that is not information related to an overall path.”
(1) The Parties’ Positions
Plaintiff argues that “[n]othing in the language of the claims themselves requires that state
information be maintained for all packets of the message,” and “the specification does not contain
a definitional statement or clear intent to limit ‘state information’ to information maintained for all
packets of the message.” (Dkt. No. 89, at 9.) Further, Plaintiff argues that “[t]he prosecution
history and extrinsic evidence identified by Defendants for their construction likewise fail to
provide the clear and unmistakable support necessary to limit the claims as they suggest.” (Id., at
10.)
Defendants respond that “the Court was not presented with Implicit’s clear and
unequivocal disclaimers from the ’163 inter partes Reexam in [the Huawei] case.” (Dkt. No. 93,
at 23.)
Plaintiff replies that “none of the citations Defendants proffer as evidence of a ‘clear and
unequivocal’ disclaimer expressly address whether state information must be maintained for all
packets of the message.” (Dkt. No. 96, at 4.)
(2) Analysis
Plaintiff proposes the construction that the Court reached in Huawei, which is the same as
the construction reached in F5 Networks I. See Huawei at 16–23; see also F5 Networks I at 13–
14.
Claim 1 of the ’104 Patent, for example, recites (emphasis added):
1. An apparatus, comprising:
a processing unit; and
- 16 -
a memory storing instructions executable by the processing unit to:
receive one or more packets of a message;
determine a key value using information in the one or
more packets;
identify, using the key value, a sequence of two or more
routines, wherein the sequence includes a routine that
is used to execute a Transmission Control Protocol
(TCP) to process packets having a TCP format;
create a path that includes one or more data structures
that indicate the identified sequence of two or more
routines, wherein the path is usable to store state
information associated with the message; and
process subsequent packets in the message using the
sequence of two or more routines indicated in the
path.
The specification discloses:
[S]ince the conversion routines may need to retain state information between the
receipt of one packet of a message and the next packet of that message, the
conversion system maintains state information as an instance or session of the
conversion routine. The conversion system routes all packets for a message
through the same session of each conversion routine so that the same state or
instance information can be used by all packets of the message.
’683 Patent at 3:1–9 (emphasis added).
Likewise, during reexamination of the ’163 Patent, the patentee cited similar disclosure in
the ’163 Patent and stated that “the specification is abundantly clear that all packets are required
to form a message.” (Dkt. No. 93, Ex. 20, Comments to ACP, at 18.) Further, again citing this
disclosure, the patentee submitted that “state information is essential for a message-centric system
that depends on state information being available for the processing of each packet in the message.”
(Id., at 13–14.) The patentee also explained that “[a] message-based technology fundamentally
differs from a packet-based technology in that it is concerned with not just the processing of
individual packets, but with the processing of a message as a whole, i.e., processing all the packets
of the message.” (Id., at 2 (emphasis modified); see id., at 10–11 (“using state information across
- 17 -
the packets of a message”) (emphasis omitted); see also id., at 11, 13–14 (contrasting “hard state”
with “soft state”), 26–28 & 38–39.)
Defendants have not shown that handling all packets of a particular message necessarily
requires maintaining state information “for” all packets of the message, which is what Defendants’
proposed construction might be interpreted as requiring. That is, the above-cited evidence can be
fairly read as relating to state information for a message but not necessarily state information
specific to every packet of the message. (See, e.g., id., at 27 (“use message-specific state
information for every packet of a message”); id., at 28 (“the ’163 claims require per-message state
that is persistent across the lifetime of an entire message—in other words, state that is collected
and maintained for all packets of a message”) & 38 (“collect, retain and apply state information
from packet-to-packet for the entire message”).) To whatever extent the specification can be read
as disclosing such a feature, this disclosure relates to “one embodiment” and should not be
imported into the claims. See ’683 Patent at 3:7–9; see also id. at 2:45 (“in one embodiment”).8
At the April 11, 2019 hearing, Defendants urged that state information must be maintained
in the sense that it cannot be “flushed” until all packets of a message have been processed. In
addition to the above-cited evidence, Defendants emphasized the patentee’s statements, during
reexamination of the ’163 Patent, regarding “hard state” and “soft state.” Defendants argued that
the patentee disclaimed “soft state” and explained that the claimed invention is limited to “hard
state”:
The message-specific claim limitations also highlight the type of state that the ’163
Patent technology uses: hard state. Hard state is required for correct function and
cannot be flushed randomly without regard to the processing of the entire message.
Defendants have also cited Plaintiff’s claim construction arguments in F5 Networks I. (See, e.g., Dkt. No. 93, Ex.
25, at 10 (“In flow-based processing, a ‘session’ is created to ensure that all packets of a flow are treated similarly.”).)
Even assuming that these statements are probative, Defendants have not shown that these statements are binding on
Plaintiff in the present case. Defendants’ reliance on these statements is unpersuasive.
8
- 18 -
In other words, it is inextricably intertwined with the message and must be
maintained for the duration of the entire message. If it is discarded before the entire
message is processed, all mid-message processing would fall apart, and the system
would be useless. In contrast, IP routers do not use this kind of hard state, since
hard state is tied to the processing of entire messages and routers are not guaranteed
to see all packets of entire messages. In short, because routers do not process entire
messages, they also cannot use the hard state that is used to process entire messages.
Instead, routers use soft state-state that can be discarded, regenerated or replaced as
needed, as further explained below.
(Dkt. No. 93, Ex. 20, Comments to ACP, at 11.)
The patentee thus distinguished routers, which can “discard[], regenerate[] or replace[]”
the state because routers do not necessarily operate on entire messages. The patentee’s statements
in this regard are consistent with disclosure in the specification of the patents-in-suit that “the same
state or instance information can be used by all packets of the message.” ’683 Patent at 3:1–9
(emphasis added).
The Court therefore hereby construes “state information” to mean “information that is
specific to a software routine for a specific message, that can be used for all packets of the
message, and that is not information related to an overall path.”
D. “process subsequent packets in the message using the sequence of routines indicated in
the stored path” and Related Terms
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
“apply[ing] one or more routines to a packet, These claim phrases do not include a system
where at least one such routine is a conversion that avoids applying the same processing steps
routine”
to subsequent packets of a message.
(Dkt. No. 85, Ex. A, at 4; id., Ex. B, at pp. 31–32 of 35; Dkt. No. 93, at 26; Dkt. No. 103, Ex. A,
at 15–16.) The parties submit that these terms appear in Claims 1, 10, and 24 of the ’683 Patent,
Claims 1, 8, and 15 of the ’790 Patent, and Claims 1, 10, and 16 of the ’104 Patent. (Id., at 15–
23.)
- 19 -
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with
the following preliminary construction: “process/processing . . . packets” means “apply/applying
one or more routines to a packet, where at least one such routine is a conversion routine.”
At the April 11, 2019 hearing, the parties reached agreement that these terms should be
given their plain meaning.
The Court therefore hereby construes “process subsequent packets in the message using
the sequence of routines indicated in the stored path” (’683 Patent, Claim 1), “process subsequent
packets of the message using sessions specified in the created path” (’683 Patent, Claim 10),
“process subsequent packets of the message using the sequence of routines referenced by the one
or more data structures” (’683 Patent, Claim 24), “process the one or more received packets using
the sequence of routines indicated in the identified path” (’790 Patent, Claims 1, 15), “process the
one or more received packets using the identified sequence of routines” (’790 Patent, Claim 8),
“process subsequent packets in the message using the sequence of two or more routines indicated
in the path” (’104 Patent, Claim 1), “process subsequent packets in the message using the identified
sequence of two or more routines” (’104 Patent, Claim 10), and “processing . . . subsequent packets
in the message using the particular sequence” (’104 Patent, Claim 16) to have their plain meaning.
E. “the packet of the message”
Defendants’ Proposed Construction
Plaintiff’s Proposed Construction
Plain and ordinary meaning. No construction “the received packet of the message that was
necessary.
used to create the path”
Alternatively, should the Court decide that this
term should be construed:
“the one or more received packets of the
message used to create a path”
- 20 -
(Dkt. No. 85, Ex. A, at 5; id., Ex. B, at p. 33 of 35; Dkt. No. 89, at 15; Dkt. No. 93, at 24–25; Dkt.
No. 103, Ex. A, at 14.) The parties submit that this term appears in Claim 9 of the ’683 Patent.
(Id.)
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with
the following preliminary construction: “the one or more received message packets used to create
a path.”
(1) The Parties’ Positions
Plaintiff “respectfully requests that the Court apply black letter to [sic] law to Claims 1 and
9 and hold that ‘a received packet of a message’ in Claim 1 and the ‘the packet of the message’ in
Claim 9 (whose antecedent basis is Claim 1) includes ‘one or more’ packets of a message by virtue
of Claim 1’s use of the article ‘a.’” (Dkt. No. 89, at 16.)
Defendants respond that “[f]or there to be a discernable point where ‘subsequent packets’
begins, there must be a singular packet of the message that was used to create the path.” (Dkt. No.
93, at 26.)
Plaintiff replies that “[t]here is no need to limit the packet that creates the path to a single
packet to know where in the transmission the ‘subsequent packets’ begin.” (Dkt. No. 96, at 6.)
(2) Analysis
Claims 1, 8, and 9 of the ’683 Patent recite (emphasis added):
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
- 21 -
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.
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.
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.
In Trend Micro, the Court construed “the packet of the message” to mean “the received
packet of the message that was used to create the path.” See Trend Micro at 24–27.
In the present case, the parties do not dispute the antecedent basis but rather dispute whether
“the packet of the message” must be singular, that is, must be one single packet.
“[A]n indefinite article ‘a’ or ‘an’ in patent parlance carries the meaning of ‘one or more’
in open-ended claims containing the transitional phrase ‘comprising.’” Convolve, Inc. v. Compaq
Computer Corp., 812 F.3d 1313, 1321 (Fed. Cir. 2016) (citation and internal quotation marks
omitted).
That “a” or “an” can mean “one or more” is best described as a rule, rather than
merely as a presumption or even a convention. The exceptions to this rule are
extremely limited: a patentee must evince[ ] a clear intent to limit “a” or “an” to
“one.” The subsequent use of definite articles “the” or “said” in a claim to refer
back to the same claim term does not change the general plural rule, but simply
reinvokes that non-singular meaning. An exception to the general rule that “a” or
“an” means more than one only arises where the language of the claims themselves,
the specification, or the prosecution history necessitate a departure from the rule.
Baldwin Graphic Sys., Inc. v. Siebert, Inc., 512 F.3d 1338, 1342–43 (Fed. Cir. 2008) (citations and
internal quotation marks omitted).
- 22 -
On balance, Defendants have failed to demonstrate that the claim language “necessitate[s]
a departure from the rule.” Id. at 1343. For example, Defendants have not persuasively supported
their assertion that “[t]he structure of the claims require a singular packet that allows the system
to create the ‘path’ such that ‘subsequent packets’ are processed using the created ‘sequence of
routines.’” (Dkt. No. 93, at 26.) Defendants’ reliance on the analysis in Trend Micro, which did
not address this issue, is unavailing. See Trend Micro at 26. The Court thus rejects Defendants’
argument that “the packet” is limited to a single packet.
The Court therefore hereby construes “the packet of the message” to mean “the one or
more received message packets used to create a path.”
F. “convert one or more packets having a TCP format into a different format” and Related
Terms
“convert one or more packets having a TCP format into a different format”
(’683 Patent, Claim 1; ’790 Patent, Claims 1, 15)
“convert one of the packets of the message into a different format”
(’790 Patent, Claim 8)
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
Plain and ordinary meaning. No construction “convert the packet(s) outermost header
necessary.
structure from TCP to another type of header
structure”
“convert one or more packets in a transport layer format into a different format”
(’683 Patent, Claim 10)
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
Plain and ordinary meaning. No construction “convert the packet(s) outermost header
necessary.
structure from a transport layer protocol header
to another type of header structure”
- 23 -
“convert packets of the different format into another format”
(’683 Patent, Claim 2; ’790 Patent, Claim 3)
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
Plain and ordinary meaning. No construction “convert each packet’s outermost header
necessary.
structure from the different protocol header
into another type of header structure”
(Dkt. No. 85, Ex. A, at 8–9; id., Ex. B, at p. 20 of 35; Dkt. No. 89, at 16 & n.4; Dkt. No. 93, at 9
& n.11; Dkt. No. 103, Ex. A, at 31–36.)
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with
the following preliminary constructions: “convert the outermost header structure of the packet(s)
from TCP to another type of header structure”; “convert the outermost header structure of the
packet(s) from a transport layer protocol header to another type of header structure”; and “convert
each packet’s outermost header structure from the different protocol header into another type of
header structure.”
(1) The Parties’ Positions
Plaintiff argues that “[t]here is no requirement that the header of interest for a particular
packet must be the ‘outermost’ header of the packet.” (Dkt. No. 89, at 17.)
Defendants respond that “the ‘format’ of a packet is its outermost header structure.” (Dkt.
No. 93, at 11.) Defendants have cited disclosures in the specification as well as statements by the
patentee during reexamination of the ancestor ’163 Patent. (Id., at 11–12.)9
9
Defendants have also cited Rule 30(b)(6) testimony by one of the named inventors (see Dkt. No. 93, Ex. 11, June 5,
2018 Balassanian dep. at 58:3–14; see also id., Ex. 22, May 31, 2012 Balassanian dep. at 298:19–22), but this
testimony does not significantly affect the Court’s analysis in these claim construction proceedings. Cf. Howmedica,
540 F.3d at 1346–47 (noting that inventor testimony is “limited by the fact that an inventor understands the invention
but may not understand the claims, which are typically drafted by the attorney prosecuting the patent application”).
- 24 -
Plaintiff replies that “the claims use the terms ‘outermost header’ and ‘format’ separately,
and if the patentee wanted to limit converting a ‘format’ to converting the ‘outermost header,’ he
knew how to do so, as in claim 20 [of the ’683 Patent].” (Dkt. No. 96, at 8.)
(2) Analysis
Claim 1 of the ’683 Patent, for example, recites (emphasis added):
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.
Plaintiff has noted that dependent Claim 20 of the ’683 Patent recites “wherein the
particular routine is executable to convert packets by removing an outermost header of the
packets,” but Claim 20 does not depend from any of the claims here at issue. Further, as
Defendants have argued, Claim 20 is limited to removing an outermost header, as opposed to
perhaps merely modifying an outermost header. Plaintiff’s argument as to Claim 24 of the ’683
Patent similarly fails. Plaintiff has not shown how Claim 20 or Claim 24 purportedly demonstrates
that “format” is necessarily broader than the outermost header.
During inter partes reexamination of the ’163 Patent, the patentee explained that the format
of a packet is defined by its header structure: “Whether a packet is an IP format is determined by
the structure of its header.” (Dkt. No. 93, Ex. 20, Comments to ACP, at 12.) The patentee
- 25 -
reinforced this principle by asserting that “[t]he format of the IP packet is not changed unless the
actual structure of the header itself is changed from that shown in Figure 2 to a different type of
header (e.g., a TCP header).” (Id., at 24; see id., at 12 (Fig. 2).) The patents-in-suit resulted from
continuations of the ’163 Patent, and these statements as to the meaning of “format,” which is a
term used extensively in the specification that is common to all of these patents, are probative as
to the patents-in-suit. See, e.g., Alloc, Inc. v. Int’l Trade Comm’n, 342 F.3d 1361, 1372 (Fed. Cir.
2003).
During inter partes reexamination of related United States Patent No. 7,711,857, the
patentee submitted an expert declaration opining that “only the structure of the outermost header
determines whether the packet is an IPv4 packet or whether it employs some other protocol.” (Id.,
Ex. 21, Ng Decl., at ¶ 6.) The ’857 Patent, like the patents-in-suit, resulted from continuations of
the ’163 Patent, and this statement as to the meaning of “format” is probative as to the patents-insuit. See Microsoft Corp. v. Multi-Tech Sys., Inc., 357 F.3d 1340, 1349–50 (Fed. Cir. 2004)
(considering statements by patentee during prosecution of related patent); see also SightSound
Techs., LLC v. Apple Inc., 809 F.3d 1307, 1316 (Fed. Cir. 2015).
Also, although Defendants have not shown or asserted that Plaintiff’s positions in prior
litigation are binding here, it is nonetheless noteworthy that Plaintiff stated in F5 Networks II that
“[e]ach message packet can include different layers in different data formats” and, for example,
“software routines associated with an Ethernet protocol will process the packet first, as the
outermost layer of the packet is in an Ethernet format.” (Dkt. No. 93, Ex. 18, F5 Networks II, Dkt.
No. 43, Implicit’s Patent Local Rule 4-5 Opening Claim Construction Brief, at 4–5.) Plaintiff thus
evidently understood that the relevant “format” of a packet is determined by its outermost header.
- 26 -
Plaintiff has cited disclosure in the specification regarding advancing a reference past a
header:
Although the conversion system has been described in terms of various
embodiments, the invention is not limited to these embodiments. Modification
within the spirit of the invention will be apparent to those skilled in the art. For
example, a conversion routine may be used for routing a message and may perform
no conversion of the message. Also, a reference to a single copy of the message
can be passed to each conversion routine or demuxkey routine. These routines can
advance the reference past the header information for the protocol so that the
reference is positioned at the next header. After the demux process, the reference
can be reset to point to the first header for processing by the conversion routines in
sequence.
’683 Patent at 14:4–16. This disclosure of “advanc[ing] the reference past the header information
for the protocol so that the reference is positioned at the next header” suggests that a packet could
be handled in a manner that is at least somewhat independent of its outermost header.
Yet, this disclosure relates to an operation that “may perform no conversion of the
message.” Id. Plaintiff has failed to demonstrate that anything in this disclosure is inconsistent
with the patentee’s understanding, as apparent in the above-discussed evidence, that the format of
a packet is determined by its outermost header. To whatever extent Plaintiff contends that the
terms “convert one or more packets having a TCP format into a different format,” “convert one or
more packets in a transport layer format into a different format,” and “convert packets of the
different format into another format” encompass merely moving a reference, the Court hereby
expressly rejects any such interpretation as lacking support in the record.
For example, at least some of the prosecution history of the ’683 Patent, cited by
Defendants, implies that “converting” requires modifying headers:
Assuming arguendo that Decasper’s plugins or flows correspond to the “sequence
of routines” of claim 26 (which Applicant does not concede), Decasper does not
teach or suggest that any of the plugins operates on “packets having a TCP format”
let alone “convert[ing]” such packets “into a different format,” as recited in that
- 27 -
claim. Rather, as discussed at length above, Decasper’s packet classification
scheme relies on IP headers remaining with packets throughout the IP core.
(See Dkt. No. 93, Ex. 13, June 6, 2013 Preliminary Amendment, at 19 (emphasis added).)
Likewise, to whatever extent Plaintiff continues to rely on dependent Claim 20 of the ’683
Patent (reciting “wherein the particular routine is executable to convert packets by removing an
outermost header of the packets”), Plaintiff has not demonstrated the applicability of claim
differentiation or any other relevant doctrine. See Wenger Mfg., Inc. v. Coating Mach. Sys., Inc.,
239 F.3d 1225, 1233 (Fed. Cir. 2001) (“Claim differentiation, while often argued to be controlling
when it does not apply, is clearly applicable when there is a dispute over whether a limitation found
in a dependent claim should be read into an independent claim, and that limitation is the only
meaningful difference between the two claims.”) (emphasis added). Plaintiff has not demonstrated
any inconsistency between Defendants’ proposed constructions and the recitals of “format” in
Claim 16 and “outermost header” in Claim 20.10
Finally, Defendants have submitted an extrinsic technical treatise that is consistent with
their proposed constructions:
Layer 3 decides which of the outgoing lines to use and passes the packets to layer 2.
Layer 2 adds not only a header to each piece, but also a trailer, and gives the
resulting unit to layer 1 for physical transmission. At the receiving machine the
message moves upward, from layer to layer, with headers being stripped off as it
progresses. None of the headers for layers below n are passed up to layer n.
(Dkt. No. 93, Ex. 23, Andrew S. Tanenbaum, Computer Networks 20 (3d ed. 1996).)
The Court therefore hereby construes the disputed terms as set forth in the following chart:
Plaintiff argues that the Court in Huawei necessarily found that Claim 16 of the ’683 Patent encompasses moving a
reference. (Dkt. No. 96, at 8.) This argument fails. Huawei found that the limitation of “convert packets by removing
an outermost header of the packets” in Claim 20 “involves modifying the packets rather than merely moving a
reference” because Claim 16, from which Claim 20 depends, recites “convert packets from an input format to an
output format.” Huawei at 26. In other words, the Huawei analysis did not rely on claim differentiation, as Plaintiff
has suggested here. (Dkt. No. 96, at 8.) Rather, Huawei read Claim 20 in light of the limitations recited in Claim 16
because Claim 20, as a dependent claim, includes all of the limitations of Claim 16. See Huawei at 26.
10
- 28 -
Term
Construction
“convert one or more packets having a TCP “convert the outermost header structure of
format into a different format”
the packet(s) from TCP to another type of
(’683 Patent, Cl. 1; ’790 Patent, Cls. 1, 15)
header structure”
“convert one of the packets of the message
into a different format”
(’790 Patent, Cl. 8)
“convert one or more packets in a transport “convert the outermost header structure of
layer format into a different format”
the packet(s) from a transport layer
(’683 Patent, Cl. 10)
protocol header to another type of header
structure”
“convert packets of the different format “convert each packet’s outermost header
into another format”
structure from the different protocol header
(’683 Patent, Cl. 2; ’790 Patent, Cl. 3)
into another type of header structure”
G. “execute a Transmission Control Protocol (TCP)” and Related Terms
“execute a Transmission Control Protocol (TCP)”
(’683 Patent, Claim 1; ’790 Patent, Claim 1, 15)
“executable to perform a Transmission Control Protocol (TCP)”
(’790 Patent, Claim 8)
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
Plain and ordinary meaning. No construction “operate on one or more packets whose
necessary.
outermost header is a TCP header at the
endpoint of a connection”
- 29 -
“execute a second, different protocol”
(’683 Patent, Claim 2; ‘790 Patent, Claim 3)
“execute a third, different protocol”
(’683 Patent, Claim 2)
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
Plain and ordinary meaning. No construction “operate on packets whose outermost header is
necessary.
a [second/third], different protocol header”
“execute a Transmission Control Protocol (TCP) to process packets having a TCP
format”
(’104 Patent, Claims 1, 16)
“execute TCP to process at least one of the subsequent packets having a TCP format”
(’104 Patent, Claim 10)
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
Plain and ordinary meaning. No construction “operate on one or more packets whose
necessary.
outermost header is a TCP header at the
endpoint of a connection”11
“execute a second protocol to process packets having a format other than the TCP
format, wherein the second protocol is an application-level protocol”
(’104 Patent, Claim 3)
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
Plain and ordinary meaning. No construction “operate on packets whose outermost header is
necessary.
an application-level protocol”12
Defendants previously proposed: “‘operate on [packets/at least one of the subsequent packets] whose outermost
header is a TCP header at the endpoint of a connection to implement at least the minimum requirements of TCP as
specified in RFC 793 at pp.44-50 (including the Open (causes a connection to be established), Send (causes data in a
specified buffer to be sent on an indicated connection), Receive (allocates a receiving buffer associated with a specified
connection), Close (causes a connection specified to be closed), and Abort (causes all pending send and received
commands to be aborted) commands received from a user program)’ / Alternatively, Indefinite.” (Dkt. No. 85, Ex. B,
at p. 26 of 35.)
11
Defendants previously proposed: “‘operate on packets whose outermost header is an application-level protocol to
perform the minimum requirements of the application-level protocol as specified in the RFC defining the applicationlevel protocol’ / Alternatively, Indefinite.” (Dkt. No. 85, Ex. B, at pp. 26–27 of 35.)
12
- 30 -
“another session associated with a different protocol that is executed, wherein the
different protocol corresponds to the different format”
(’683 Patent, Claim 10)
Plaintiff’s Proposed Construction
Defendants’ Proposed Construction
Plain and ordinary meaning. No construction “operate on packets whose outermost header is
necessary.
a protocol different from the transport layer
protocol”13
(Dkt. No. 85, Ex. A, at 6–7 & 10–12; id., Ex. B, at pp. 14–19 & 26–27 of 35; Dkt. No. 89, at 16 &
n.4; Dkt. No. 93, at 15 & 22; Dkt. No. 103, Ex. A, at 23–31.)
Shortly before the start of the April 11, 2019 hearing, the Court provided the parties with
preliminary constructions as set forth in the following chart:
Term
Preliminary Construction
G.(1a) “execute a Transmission Control
Protocol (TCP)”
(’683 Pat., Cl. 1; ’790 Pat., Cl. 1, 15)
“operate on one or more packets whose
outermost header is a TCP header”
G.(1b) “executable to perform a
Transmission Control Protocol (TCP)”
(’790 Pat., Cl. 8)
“operable on one or more packets whose
outermost header is a TCP header”
G.(2) “execute a second, different protocol”
(’683 Pat., Cl. 2; ‘790 Pat., Cl. 3)
“operate on packets whose outermost header
is a [second/third], different protocol header”
“execute a third, different protocol”
(’683 Pat., Cl. 2)
Defendants previously proposed: “‘operate on packets whose outermost header is a protocol different from the
transport layer protocol to perform the minimum requirements of the different protocol as specified in the RFC
defining the different protocol’ / Alternatively, Indefinite.” (Dkt. No. 85, Ex. B, at p. 27 of 35.)
13
- 31 -
G.(3) “execute a Transmission Control
Protocol (TCP) to process packets having a
TCP format”
(’104 Pat., Cls. 1, 16)
“operate on one or more packets whose
outermost header is a TCP header”
“execute TCP to process at least one of the
subsequent packets having a TCP format”
(’104 Pat., Cl. 10)
G.(4) “execute a second protocol to process
packets having a format other than the TCP
format, wherein the second protocol is an
application-level protocol”
(’104 Pat., Cl. 3)
“execute a second protocol to operate on
packets whose outermost header is other than
a TCP header, wherein the second protocol is
an application-level protocol”
G.(5) “another session associated with a
different protocol that is executed, wherein
the different protocol corresponds to the
different format”
(’683 Pat., Cl. 10)
Plain meaning
(1) The Parties’ Positions
Plaintiff argues that “a protocol typically refers to a set of rules or procedures for
transmitting data between electronic devices, and that protocol may or may not be standardized in
an RFC,” and Plaintiff argues that the Court properly rejected arguments regarding “endpoint of a
connection” in Huawei. (Dkt. No. 89, at 19 & 23.)
Defendants respond that “the overwhelming weight of the intrinsic and extrinsic evidence
points to the same conclusion that these two concepts—outermost header being a TCP header and
operation occurring at the endpoint of a connection—are precisely what it means to ‘execute a
TCP.’” (Dkt. No. 93, at 16.)14
14
Defendants have also cited Rule 30(b)(6) testimony by one of the named inventors (see Dkt. No. 93, Ex. 11, June
5, 2018 Balassanian dep. at 162:11–164:1), but this testimony does not significantly affect the Court’s analysis in
these claim construction proceedings. Cf. Howmedica, 540 F.3d at 1346–47 (noting that inventor testimony is “limited
by the fact that an inventor understands the invention but may not understand the claims, which are typically drafted
by the attorney prosecuting the patent application”).
- 32 -
Plaintiff replies that “[i]t is undisputed that the term ‘endpoint’ does not appear in the
Patents,” and “while a TCP connection may be between endpoints, the functionality of executing
TCP to convert packets having a TCP format into a different format can happen at any device
through which packets of the connection flow—not only the endpoints.” (Dkt. No. 96, at 10.)
(2) Analysis
Claim 1 of the ’683 Patent, for example, recites (emphasis added):
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.
First, the dispute as to Defendants’ proposals that the “outermost header is a TCP header”
presents substantially the same dispute that the parties have presented as to the terms “convert one
or more packets having a TCP format into a different format,” “convert one or more packets in a
transport layer format into a different format,” and “convert packets of the different format into
another format,” which are addressed above. As further support for the present disputed terms,
Defendants also note the patentee’s statements during prosecution of the ’683 Patent. (See Dkt.
- 33 -
No. 93, Ex. 13, June 6, 2013 Preliminary Amendment, at 19 n.4 (“executes the TCP protocol (i.e.,
operates on a packet whose outermost header is a TCP header)”).)15
Second, Defendants have failed to persuasively support their proposal of referring to an
“endpoint of a connection.” The parties agree that “Transmission Control Protocol” (“TCP”) is a
standard protocol for network communications. See Vizio, Inc. v. Int’l Trade Comm’n, 605 F.3d
1330, 1336–37 (Fed. Cir. 2010) (construing claims in light of the MPEG-2 digital television
standard).
Also, Defendants have submitted that the Background section of the specification
frames the claimed invention in the context of “when data is generated on one computer system
and is transmitted to another computer system to be displayed . . . .” ’683 Patent at 1:27–29.
Yet, no “endpoint” limitation is recited or implied in the claim language, no disclosure in
this regard appears in the specification, and Defendants have not demonstrated that Transmission
Control Protocol (TCP) is relevant only at endpoints of a connection. Even the portions of the
TCP standard cited by Defendants do not persuasively support Defendants’ proposal of limiting
the disputed terms to endpoints. (See Dkt. No. 93, Ex. 24, RFC 793, Transmission Control
Protocol at § 1 (“The Transmission Control Protocol (TCP) is intended for use as a highly reliable
host-to-host protocol between hosts16 in packet-switched computer communication networks, and
in interconnected systems of such networks.”) (emphasis added); see also id., Ex. 23, Andrew S.
Tanenbaum, Computer Networks 521 (3d ed. 1996) (“TCP (Transmission Control Protocol) was
15
Defendants have not shown, however, how their arguments in this regard are applicable to the final disputed term,
namely “another session associated with a different protocol that is executed, wherein the different protocol
corresponds to the different format” (’683 Patent, Claim 10). At the April 11, 2019 hearing, Defendants withdrew
their proposed construction for this term. As set forth below, the Court construes this term to have its plain meaning.
(See id., at p. 80 (defining “host” as: “A computer. In particular a source or destination of messages from the point
of view of the communication network.”).)
16
- 34 -
specifically designed to provide a reliable end-to-end byte stream over an unreliable
internetwork.”) (emphasis added).)
Defendants have emphasized a statement by the patentee during prosecution of the ’683
Patent that “it is well known that the Transmission Control Protocol (TCP) is implemented at the
endpoints of a connection.” (Dkt. No. 93, Ex. 13, June 6, 2013 Preliminary Amendment, at 19
n.4; see id., at 19; see also id., at 14 n.3 (“Decasper’s EISR [(Extended Integrated Services Router)]
architecture is not focused on communication ‘end-systems’ that implement protocols such as
TCP.”).) Also, during inter partes reexamination of the ancestor ’163 Patent, the patentee stated
that “the ’163 Patent technology functions at the end-point level.” (Id., Ex. 20, Comments to ACP,
at 12.) These statements that TCP is implemented at endpoints, however, do not preclude TCP
from functioning elsewhere. On balance, no relevant disclaimer is apparent as to the disputed
terms, and to whatever extent an endpoint of a connection is necessitated by a particular limitation
in a particular claim by virtue of using TCP, Defendants’ proposal of “endpoint of a connection”
is unnecessary.
The Court therefore hereby construes the disputed terms as set forth in the following chart:
Term
Construction
“execute a Transmission Control Protocol “operate on one or more packets whose
(TCP)”
outermost header is a TCP header”
(’683 Patent, Cl. 1; ’790 Patent, Cl. 1, 15)
“executable to perform a Transmission “operable on one or more packets whose
Control Protocol (TCP)”
outermost header is a TCP header”
(’790 Patent, Cl. 8)
“execute a second, different protocol”
(’683 Patent, Cl. 2; ’790 Patent, Cl. 3)
“operate on packets whose outermost
header is a [second/third], different protocol
header”
“execute a third, different protocol”
(’683 Patent, Cl. 2)
- 35 -
“execute a Transmission Control Protocol “operate on one or more packets whose
(TCP) to process packets having a TCP outermost header is a TCP header”
format”
(’104 Patent, Cls. 1, 16)
“execute TCP to process at least one of the
subsequent packets having a TCP format”
(’104 Patent, Cl. 10)
“execute a second protocol to process
packets having a format other than the TCP
format, wherein the second protocol is an
application-level protocol”
(’104 Patent, Cl. 3)
“execute a second protocol to operate on
packets whose outermost header is other
than a TCP header, wherein the second
protocol is an application-level protocol”
“another session associated with a different Plain meaning
protocol that is executed, wherein the
different protocol corresponds to the
different format”
(’683 Patent, Cl. 10)
V. CONCLUSION
The Court adopts the constructions set forth in this opinion for the disputed terms of the
.
patents-in-suit, and in reaching conclusions the Court has considered extrinsic evidence. The
Court’s constructions thus include subsidiary findings of fact based upon the extrinsic evidence
presented by the parties in these claim construction proceedings. See Teva, 135 S. Ct. at 841.
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.
SIGNED this 3rd day of January, 2012.
SIGNED this 15th day of April, 2019.
____________________________________
- 36 - ROY S. PAYNE
UNITED STATES MAGISTRATE JUDGE
Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.
Why Is My Information Online?