Riverbed Technology Inc. v. Silver Peak Systems Inc.

Filing 134

MEMORANDUM OPINION providing construction for the terms in dispute. The parties should jointly submit a claim construction order, including the agreed-upon term, suitable for submission to the jury within 5 days of this opinion. Signed by Judge Richard G. Andrews on 5/3/2013. (nms)

IN THE UNITED STATES DISTRICT COURT
FOR THE DISTRICT OF DELAWARE

RNERBED TECHNOLOGY, INC.,
Plaintiff,
C.A. No. 11-484-RGA

V.

SILVER PEAK SYSTEMS, INC.,
Defendant.

MEMORANDUM OPINION

Thomas C. Grimm, Esq., Wilmington, Delaware; Matthew B. Lehr, Esq. (argued), Menlo
Park, California; Attorneys for Plaintiff Riverbed Technology, Inc.
Richard L. Horowitz, Esq., Wilmington, Delaware; Michael J. Sacksteder, Esq. (argued),
San Francisco, California; Attorneys for Defendant Silver Peak Systems, Inc.

Ma~,2013
Wilmington, Delaware

ANDREWS,

UNIT~~TATES

DISTRICT JUDGE:

This is a claim construction opinion for U.S. Patent No. 8,069,225 ("'225 Patent"). 1 Plaintiff
Riverbed Technology, Inc., asserts the '225 Patent against Defendant Silver Peak Systems, Inc.
The '225 Patent claims a transaction predictor aimed at speeding up the transmission of
transactions over a network. A transaction involves a request for information from a client and a
server's ensuing response. The transaction predictor decreases latency (or network lag-time) by
predicting transactions the client will need in the future. After a client makes a request, the
transaction predictor makes predictions of what events are to take place next. It makes these
predictions based on an understanding of past transactions. The transaction predictor then tells
the server to respond with both the transaction actually requested and the predicted transactions.
The client then receives the requested and predicted transactions. The client typically now has
available both the data he needs and the data he will shortly need. The client will thus require
fewer responses from the server, reducing the amount of back-and-forth communication over the
network.
The disputed claim terms follow.
1. "a transaction predictor," "synthesize, based on past transactions," and "based [at
least in part] on past transactions"

The claim chart for the first three disputed terms follows:

Claim term
"a transaction
predictor"

Riverbed's Construction
Hardware, firmware, and/or
software logic configured to
predict, based on past
transactions, which transactions

1

Silver Peak's Construction
A mechanism that compares an
intercepted transaction to a
database of past transaction
behaviors to predict transactions.

The parties also briefed and argued claim construction for U.S. Patent Nos. 7,428,573 and 7,849,134, but those
patents are currently under reexamination by the United States Patent and Trademark Organization. The Court will
postpone consideration of those patents.

1

'225 Patent: Claims 1,
16
"synthesize, based on
past transactions"

are likely to occur in the future
between a client and a server
generate based on past
transactions

'225 Patent, Claim 1
"based [at least in
part] on past
transactions"
'225 patent: Claims 1,
16

Plain and ordinary meaning

use a combination of logic and
stored records of past
transactions from prior sessions
to generate a predicted
transaction
based on stored records of past
transactions from prior sessions

The construction of the three terms, "transaction predictor," "synthesize, based on past
transactions," and "based [at least in part] on past transactions," depends essentially on the same
issue: whether a database of stored records from prior sessions is a necessary component of the
prediction system. The terms shall thus be construed together. They are used as follows in claim
1 ofthe '225 Patent:
a transaction predictor that is configured to synthesize, based on past transactions, one or
more predicted transactions, wherein transactions comprise sets of steps that result in data
moving from one place to another;
Silver Peak argues that the "transaction predictor" must employ a database of stored records
from prior sessions to accomplish its function, which is to "synthesize, based on past
transactions, one or more predicted transactions[.]" Riverbed disagrees, arguing that the
"transaction predictor" may use pre-coded firmware to predict transactions based on past
transactions. This would make a database not necessary.
In support of its construction, Riverbed argues that a "transaction predictor" is explicitly
defined without mention of any database: " ... a transaction involves ... a transaction predictor
configured to predict, based on past transactions, which transactions are likely to occur in the
future between the client and server." '225 Patent 10:15-17. It is well-established that the
2

patentee can act as his own lexicographer, so long as he clearly states any special definitions of
the claim terms in the patent specification or file history. GlaxoSmithKline LLC v. Anchen
Pharmaceuticals, Inc., 2012 WL 5594540, *2 (D. Del. Nov. 15, 2012). The Court does not

agree that this is an explicit definition. There are none of the tell-tale signs of an explicitly
defined term, as the term is not set off by quotation marks and there is no hint of definitional
language. It is merely a recitation of function and does not indicate a comprehensive definition.
This is actually suggested by Riverbed's own proposed construction, which adds additional
elements not present in the supposed explicit definition. 2 This undermines Riverbed's position,
as true explicit definitions should not require supplementation.
In any event, this does not mean that Riverbed's construction is wrong- only that it is not
sourced in an explicit definition. There is support for the "[h]ardware, firmware, and/or
software" element of Riverbed's proposed construction:
In some implementations, the engine is implemented entirely in software, while in other
implementations the engine might be implemented in hardware, firmware or some
combination ofhardware, firmware and/or software.
!d. at 12:44-48. The disclosure of firmware supports Riverbed's position that pre-coded
information may accomplish the functions of a "transaction predictor," and undermines Silver
Peak's position that a database of stored records from prior sessions is strictly required. Silver
Peak, for its part, points to descriptions in the specification disclosing a database:
As transactions are executed between the client and server, intervening engines intercept
a transaction, use a transaction predictor that compares the intercepted transaction to a
database of past transaction behaviors to make decisions about the probability of future
events.

2

These are the "[h]ardware, firmware, and/or software logic ... " proposed elements.

3

!d. at 19:54-58. If this were the only description of the prediction system, or if the rest of the
specification consistently required a database, the Court might be inclined to agree with Silver
Peak. The claims, however, must be construed in light of the entire specification, not just a
single passage. Other portions of the specification contain examples of"transaction predictors"
that do not require a database. One is specifically referred to as a "static prediction" mechanism:
One approach to transaction prediction is to encode static logic into the
transaction predictor that recognizes common transaction patterns and performs
prediction accordingly. This approach can be thought of as programming the
transaction predictor with a set of"recipes." Each recipe represents a pattern or
set of patterns that are to be recognized along with a set of predicted actions that
can be taken on behalf of the recognized pattern.

!d. at 22:60-67; see also id. at 22:26-27 (predictions can be made based on "inherent
knowledge"). This description states that common transaction patterns used to form "recipes."
The predictor then recognizes incoming data patterns and performs predictions according to
those recipes. For certain transaction patterns to be determined to be common and then hardcoded into the engine as recipes, there must be some baseline source of past transactions from
which the patterns are grounded. 3 For instance, a programmer may accumulate knowledge of
common transaction patterns by studying the use of a particular application. The programmer
could then create a recipe based on that knowledge and hard-code it into a firm-ware based
transaction predictor. This would satisfy the "based on past transactions" claim language. A
database would not be needed.
Silver Peak argues that the patentee distinguished "static prediction" from predictions
based on "past transactions" in the following passage:
Dynamic Prediction: A Markovian Learning Module
3

There is no language in the '225 Patent restricting "past transactions" to those actually transmitted on the network
where the prediction system is being used.

4

While static prediction can be very effective at anticipating client protocol
behaviors, [an] even more powerful approach is to rely on dynamic prediction
logic, which employs a learning algorithm to leverage past client behaviors to
predict present and future transactions.

!d. at 23: 21-26. It is true that the patentee praises the use of a "learning algorithm to leverage
past client behaviors to predict present and future transactions" as "even more powerful" than
"static prediction." This, however, does not mean that "static prediction" is outside the claim, as
"[ m]ere criticism of a particular embodiment encompassed in the plain meaning of a claim term
is not sufficient to rise to the level of clear disavowal." Thorner v. Sony Computer Entm 'tAm.

LLC, 669 F.3d 1362, 1366 (Fed. Cir. 2012). Further, the patentee only contrasts "static
prediction" with predictions based on "past client behavior," not "past transactions" generally.
Making predictions based strictly on past client behavior is a narrower concept than making
predictions based on past transactions generally, because the former requires the predictions to
be based on the history of the actual client using the transaction prediction system, whereas the
latter allows for the possibility of making predictions based on a broader array of past transaction
sources. For these reasons, the Court will not construe the terms to require a database of stored
records from prior sessions

The Court thus construes the three terms as follows:

Claim term
"a transaction
predictor"
'225 Patent: Claims 1,
16
"synthesize, based on
past transactions"

Court's construction
Hardware, firmware, and/or software logic configured to predict, based
on past transactions, which transactions are likely to occur in the future
between a client and a server

generate based on past
transactions

'225 Patent, Claim 1
5

"based [at least in
part] on past
transactions"
'225 patent: Claims 1,
16

Plain and ordinary meaning

The parties should jointly submit a claim construction order, including the agreed-upon
term, suitable for submission to the jury within five days of this opinion.

6