I/P Engine, Inc. v. AOL, Inc. et al

Filing 160

Claim Construction Brief IP Engine's Reply Claim Construction Brief to 122 Claim Construction Brief filed by I/P Engine, Inc.. (Attachments: # 1 Exhibit 1)(Sherwood, Jeffrey)

UNITED STATES DISTRICT COURT
EASTERN DISTRICT OF VIRGINIA
NORFOLK DIVISION
__________________________________________
)
)
)
Plaintiff,
)
v.
)
)
AOL, INC. et al.,
)
)
Defendants.
)
__________________________________________)
I/P ENGINE, INC.,

Civ. Action No. 2:11-cv-512

I/P ENGINE’S REPLY CLAIM CONSTRUCTION BRIEF

Dated: May 3, 2012

Donald C. Schultz (Virginia Bar No. 30531)
W. Ryan Snow (Virginia Bar No. 47423)
CRENSHAW, WARE & MARTIN PLC
150 West Main Street
Norfolk, VA 23510
Telephone: [phone]
Facsimile: [phone]
Jeffrey K. Sherwood (Virginia Bar No. 19222)
Frank C. Cimino, Jr.
Kenneth W. Brothers
Leslie Jacobs
Charles J. Monterio, Jr.
Jonathan L. Falkler
DICKSTEIN SHAPIRO LLP
1825 Eye Street, NW
Washington, DC 20006
Telephone: [phone]
Facsimile: [phone]
Counsel for Plaintiff I/P Engine, Inc.

DSMDB-3056623

TABLE OF CONTENTS
Page
I.

INTRODUCTION ..................................................................................................................1

II.

DISPUTED CLAIM TERMS.................................................................................................1
A.
B.

“[feedback system for] receiving information found to be relevant to the query
by other users”...............................................................................................................3

C.

“scanning a network” ....................................................................................................5

D.

“scanning system” .........................................................................................................7

E.

“combining” ..................................................................................................................9

F.

Different Systems........................................................................................................13

G.

“demand search” .........................................................................................................15

H.

“individual user”/“first user”.......................................................................................16

I.

“relevance to at least one of the query and the first user”...........................................17

J.

“[informons/information] relevant to a query” ...........................................................18

K.

Order of Method Limitations ......................................................................................20

L.
III.

“collaborative feedback data” .......................................................................................1

Antecedent Basis .........................................................................................................22

CONCLUSION ....................................................................................................................24

i

TABLE OF AUTHORITIES
Page(s)
Cases
Am. Piledriving Equip., Inc. v. Geoquip, Inc.,
637 F.3d 1324 (Fed. Cir. 2011)..................................................................................................4
Bristol Co. Ltd. P’ship v. Bosch Rexroth Inc.,
684 F. Supp. 2d 1245 (D. Colo. 2010).....................................................................................14
C.R. Bard, Inc. v. U.S. Surgical Corp.,
388 F.3d 858 (Fed. Cir. 2004)....................................................................................................4
Gemstar-TV Guide Intern., Inc. v. Int’l Trade Com’n,
383 F.3d 1352 (Fed. Cir. 2004)................................................................................................10
Honeywell Int’l, Inc. v. ITT Indus., Inc.,
452 F.3d 1312 (Fed. Cir. 2006)..................................................................................................4
Liebel-Flarsheim Co. v. Medrad, Inc.,
358 F.3d 898 (Fed. Cir. 2004)................................................................................................6, 8
Linex Tech, Inc. v. Belkin Int’l., Inc., et al.,
2009 WL 361697 (E.D. Tex. Feb. 12, 2009) ...........................................................................10
Markman v. Westview Instruments, Inc.,
52 F.3d 967 (Fed. Cir. 1995)(en banc).....................................................................................19
O2 Micro Int’l Ltd. v. Beyond Innovation Tech. Co.,
521 F.3d 1351 (Fed. Cir. 2008)................................................................................................23
Omax Corp. v. Flow Int’l. Corp.,
2006 WL 3249190 (W.D. Wash. Nov. 7, 2006) ......................................................................10
Personalized User Model LLP v. Google Inc.,
2012 WL 295048 (D. Del. Jan. 25, 2012)................................................................................22
Phillips v. AWH Corp.,
415 F.3d 1303 (Fed. Cir. 2005)..............................................................................................8, 9
Power Integrations, Inc. v. Fairchild Semiconductor Int’l., Inc., et al.,
422 F. Supp. 2d 446 (D. Del. 2006).........................................................................................10
Sunbeam Products, Inc. v. Hamilton Beach Brands, Inc.,
2010 WL 3291830 (E.D. Va. August 19, 2010) ......................................................................23

ii

The Fox Group, Inc. v. Cree, Inc.,
819 F. Supp. 2d 490 (E.D. Va. 2011) ......................................................................................23
Vitronics Corp. v. Conceptronic, Inc.,
90 F.3d 1576 (Fed. Cir. 1996)..................................................................................................15

iii

I.

INTRODUCTION
Defendants’ Opening Claim Construction Brief (“Opening Brief”) does not approach

claim construction consistently for the transparent reason that Defendants are busy constructing
defensive arguments rather than parsing the meaning of the claim terms. Their analytical
methodology therefore changes from urging plain and ordinary meaning, when clearly their
proposed offering is not, to insisting on importing limitations from the specification that defy a
term’s plain and ordinary meaning.
The purpose of claim construction is to define the meaning of the words already in the
claims—not to incorporate additional concepts and limitations from the specification into the
claims, and certainly not to facilitate Defendants’ defense strategies.
II.

DISPUTED CLAIM TERMS
A.

“collaborative feedback data” (‘420 Patent, claims 10, 25)

I/P Engine’s Proposed Construction
information concerning what informons other
users with similar interests or needs found to
be relevant

Defendants’ Proposed Construction
data from users with similar interest or needs
regarding what informons such users found to
be relevant

In its Opening Brief, I/P Engine describes why “collaborative feedback data” should be
construed as “information concerning what informons other users with similar interest or needs
found to be relevant.” D.I. 129 at 22-23. I/P Engine’s construction comes directly from a
quotation in the specification that describes the feedback data used by collaborative filtering
systems, and is entirely consistent with the intrinsic evidence. D.I. 129, Ex. 1 at col. 4, ll. 26-29.
Defendants’ proposed construction (“data from users with similar interest or needs
regarding what informons such users found to be relevant” (emphasis added)) is incorrect
because it adds a second limitation regarding the source of the collaborative feedback data.
Claims 10 and 25 of the ‘420 patent already explicitly define the source of the data—it is “from

system users.” Plainly then, the patentees thought about the source of this data and chose not to
define the source of the data any more narrowly than “system users.” A construction that adds a
second source limitation is inconsistent with the clear intent of the patentee and the clear
language of the claim, which described only one source limitation—“from system users.”
Defendants’ construction also is not supported by the specification. The “from” language
does not appear in the portion of the specification that both parties use to construe the feedback
as being related to what others “with similar interest or needs found to be relevant.” Defendants
also include three other specification citations that they argue support a “from” requirement.1
Each of these citations, however, is a general statement about systems that use collaborative
input—the first citation merely states that collaborative filtering uses data from other users (i.e.,
the data originates with other users but is not necessarily received from those users), the second
citation refers merely to problems in the prior art, and the third citation (from the Abstract)
merely describes that the system integrates collaborative feedback data with content data. None
of these citations support a claim requirement that the data must actually be received “from” the
users.
In contrast, I/P Engine’s proposed construction confines itself to a description of the data
and flows directly from the intrinsic evidence, including language in the specification that
actually refers to the feedback data received by collaborative filtering systems. See D.I. 129 at

1

Defendants’ cite the following language: “the present invention is directed to an information
processing system . . . with collaborative feedback data and content based data . . .” (D.I. 126,
Ex. 1 at col. 2, ll. 28-33); “The present invention combines collaborative filtering with content
based filtering in measuring informons for relevancy, and further preferably applies adaptive
updating of the content-based filtering operation.” (D.I. 126, Ex. 1 at col. 2, ll. 28-33); “[a] user
feedback system provides collaborative feedback data for integration with content profile data in
the operation of the collaborative/content-based filter.” (D.I. 126, Ex. 1 at Abstract).

2

22-23. Accordingly, I/P Engine’s proposed construction is the only one that faithfully reflects
the specification’s definition.
B.

“[feedback system for] receiving information found to be relevant to the
query by other users” (‘664 Patent, claims 1, 26)

I/P Engine’s Proposed Construction
No construction necessary
- or [feedback system for] receiving information
concerning what other users found to be
relevant to the query

Defendants’ Proposed Construction
[system using a process of filtering information
by] determining what information other users
with similar interests or needs found to be
relevant

I/P Engine proposes that no construction is necessary, or alternatively, proposes a plain
language construction that states that the information received by the system is that which “other
users found to be relevant to the query.” I/P Engine’s Opening Brief explains that the words of
this term are ordinary words and their meaning is clear and consistent with the specification.
D.I. 129 at 23-24.
Defendants propose that this term be construed to mean “determining what information
other users with similar interests or needs found to be relevant.” Defendants’ construction is
wrong for two reasons: (1) it turns a “receiving” limitation into a “determining” limitation with
no intrinsic support whatsoever (nor any explanation in their Brief); and (2) it improperly
conflates this term with the “collaborative feedback data” term to import a source limitation
when the claim was plainly constructed with the purpose of not including any such limitation.
First, Defendants provide no support or explanation why they replace the “receiving
information” requirement with the phrase “determining what information.” There is no
dictionary definition that equates the words “determining” and “receiving”—without question
they have different meanings. Defendants’ own Brief asserts that “the ‘feedback system for
receiving information found to be relevant to the query by other users’ in ‘664 claim 1 must be
construed as a feedback system for receiving collaborative information.” D.I. 122 at 9 (emphasis
3

modified from original). This self-inflicted wound underscores the fundamental difference in
meaning between “determining” and “receiving.”
Second, Defendants incorrectly equate this phrase with the term “collaborative feedback
data.” Defendants’ sole reason for importing aspects of the “collaborative feedback data”
definition is the assertion that the intrinsic evidence requires a “collaborative element.” D.I. 122
at 7-8. But, in plain words, a “collaborative element” is exactly what is already claimed—the
claim recites that the system receives “information found to be relevant to the query by other
users.” Just because the patentee used different words to describe the concept does not mean
that the “collaborative element” is missing; the plain meaning of the patentee’s words removes
any doubt about its presence. The cases cited by Defendants involve situations where an
allegedly required feature was not already reflected in the claim language.2 Here, Defendants’
“collaborative element” is already reflected in the plain language of the claims.
Accordingly, the “similar interests or needs” language proposed by Defendants and
imported from the “collaborative feedback data” term is an improper addition to the existing
claim phrase. All elements are present and no further construction is necessary—the language
within the claim itself is clear.

2

See, e.g., C.R. Bard, Inc. v. U.S. Surgical Corp., 388 F.3d 858, 864 (Fed. Cir. 2004) (requiring
essential “pleats” that were not already described in the claim due to descriptions in the
specification and numerous clear statements in the prosecution history); Am. Piledriving Equip.,
Inc. v. Geoquip, Inc., 637 F.3d 1324, 1334 (Fed. Cir. 2011) (requiring certain essential structural
features not already described in the claim); Honeywell Int’l, Inc. v. ITT Indus., Inc., 452 F.3d
1312, 1318-19 (Fed. Cir. 2006) (requiring a “fuel filter” not already described in the claim).

4

C.

“scanning a network”(‘420 Patent, claims 10, 25)

I/P Engine’s Proposed Construction
looking for items on two or more connected
computers

Defendants’ Proposed Construction
spider[ing] or crawl[ing] a network

I/P Engine’s Opening Brief demonstrates that “scanning a network” should be construed
as “looking for items on two or more connected computers.” This construction is supported by
the plain meaning of the two familiar and understandable English words, “scanning” and
“network,” and is further supported by how each of the words “scan” and “network” are used in
the specification. D.I. 129 at 11-14. Defendants’ definition ignores the plain meaning of these
words, and instead reads features of the specification into the claims by proposing that “scanning
a network” should mean “spidering or crawling a network.”
First, Defendants propose that “scanning” must mean “spidering or crawling” in
accordance with what Defendants refer to as “the specification’s definition of this term.” D.I.
122 at 10. This is incorrect. The specification does not provide a special definition for the term
“scanning.” The patentees knew how to invoke the lexicographer exception—they did so with
regard to the terms “informon” and “relevance.” Here, they purposefully did not do so for
“scanning,” demonstrating an intent not to redefine the word. Even though “spiders” were
commonly known at the time of invention, and the patentees could have drafted claims to
“spidering,” they did not. Instead, they drafted claims to the broader concept of “scanning” and
described a spider system as an example of a system that scans: “[a] spider system 46C scans a
network 44C to find informons for a current demand search, and to find informons with
continued network scanning for existing wires.” D.I. 129, Ex. 1 at col. 25, ll. 39-41; see also col.
26, ll. 14-15 (“A spider system 68C continuously scans a network 70C for informons . . . .”).
The specification never once equates “scanning” with “spidering.” So there is no clear
indication that the patentee intended the claims to be limited as proposed by Defendants.
5

Second, Defendants contend that “[b]ecause every instance of ‘scanning’ in the
specification is tied to the operation of a spider, the term ‘scanning’ is properly construed as
requiring such a spider.” Id. at 11. This, however, is not a rationale for reading the collateral
functions of “spidering” or “crawling” into the claim term. The Federal Circuit has explained
that “[e]ven when the specification describes only a single embodiment, the claims of the patent
will not be read restrictively unless the patentee has demonstrated a clear intention to limit the
claim scope using ‘words or expressions of manifest exclusion or restriction.’” Liebel-Flarsheim
Co. v. Medrad, Inc., 358 F.3d 898, 906 (Fed. Cir. 2004) (“[T]his court has 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.”)(citations omitted). Here, there are no such
“words or expressions of manifest exclusion or restriction” anywhere in the intrinsic record.
Third, Defendants contend that their proposed meaning “is consistent with the relevant
extrinsic evidence.” D.I. 122 at 11. Defendants’ extrinsic evidence solely relates to defining the
word “spider”—which is not the term being construed. See id. at 11-12. Consequently,
Defendants’ alleged “relevant extrinsic evidence” is not relevant at all.
“Scanning” is a common, understandable term and should be afforded its plain and
ordinary meaning. Providing the term a special meaning is improper. To “scan” is merely to
“look for” something (in this case to look for informons/information that will be filtered in a
demand search).3

3

I/P Engine provides numerous dictionary definitions that further evidence of the plan and
ordinary meaning of “scan.” Defendants, on the other hand, cannot provide a dictionary
definition that supports their construction of “scan”—they sprinkle in dictionary definitions for
“spider” and “searching” but could not find a single dictionary defining the word “scan” in a way
that supports their definition. This is because they are redefining the word by importing
limitations from the specification.

6

Defendants do not raise any dispute with the “network” portion of the term “scanning a
network.” Accordingly, it should be interpreted in accordance with its plain and ordinary
meaning of “two or more connected computers.” Putting the ordinary meaning of these two
commonly understood words together, the meaning of the phrase “scanning a network” means
“looking for items on two or more connected computers.”
D.

“scanning system” (‘664 Patent, claim 1)

I/P Engine’s Proposed Construction
a system used to search for information

Defendants’ Proposed Construction
a system used to scan a network

I/P Engine proposes construing “scanning system” as “a system used to search for
information.” I/P Engine’s Opening Brief explains that this construction is consistent with both
the plain meaning of the words in the term, and the specification’s description of the scanning
system. D.I. 129 at 14-16.
Defendants propose that the term be construed as “a system used to scan a network.”
Defendants’ proposed construction is improper because it (1) conflicts with the well established
doctrine of claim differentiation, and (2) improperly imports the “spidering” feature from the
specification into the claim (when considered together with Defendants’ definition of “scanning
a network”).
By referencing independent claim 26 and dependent claim 38 of the ‘664 patent (neither
of which have the “scanning system” limitation), Defendants argue that “scanning” should be
narrower than “searching.” D.I. 122 at 13. In making this claim differentiation argument,
Defendants do not consider the full claim language. The words “searching” and “scanning” can
not be considered in isolation—independent claim 26 recites “searching for information” and
dependent claim 38 recites that the “searching for information” phrase includes “scanning a

7

network.” “Searching for information” in the independent claims is broader, and may or may not
include searching for information on “a network,” as is required by the dependent claim.
Just like claims 26 and 38, independent claim 1 recites that the scanning system “searches
for information” and dependent claim 24 recites that the scanning system further includes
“scanning a network.” In both sets of claims, the independent claim requires “searching for
information,” and the dependent claim further requires “scanning a network” to conduct that
search. “The presence of a dependent claim that adds a particular limitation gives rise to a
presumption that the limitation in question is not present in the independent claim.” Phillips v.
AWH Corp., 415 F.3d 1303, 1314-15 (Fed. Cir. 2005) (citations omitted). Therefore, claim 1 of
the ‘664 patent does not require “scanning a network”—the very phrase that Defendants are
trying to read into this definition. Defendants’ inclusion of “scanning a network” violates the
principle of claim differentiation because it reads the “scanning a network” limitation from claim
26 into claim 1.
Defendants also appear to suggest that the “scanning system” must be a “spider scanning
system” because they use the phrase “‘scan a network,” which they define as a “spider or crawl
of a network.” D.I. 122 at 12. This too should be rejected. A “scanning system” need not be a
“spider scanning system.” As described above, while spiders or web crawlers are an exemplary
embodiment, absent a clear indication in the intrinsic record that the patentee intended the claims
to be so limited it is improper to read limitations from an embodiment described in the
specification into the claims. Liebel-Flarsheim, 358 F.3d at 913.
I/P Engine’s proposed construction should be adopted because it is consistent with the
claim language, and the ordinary meaning of the terms. A “scanning system” is “a system used
to search for information.”

8

E.

“combining”(‘420 Patent, claims 10, 25; ‘664 Patent, claims 1, 26)

I/P Engine’s Proposed Construction
uniting into a single number or expression

Defendants’ Proposed Construction
plain meaning; alternatively,
bringing together

I/P Engine proposes that “combining” be construed as “uniting into a single number or
expression.” I/P Engine’s construction flows directly from the plain and ordinary meaning of the
word “combining,” as mandated by Phillips, and is confirmed by the specification’s description
of “combining” collaborative and content data. See generally D.I. 129 at 17-21. That analysis
ends the debate on the proper construction of “combining.”
Defendants’ proposal (“bringing together”) is wrong for at least two reasons. First, it is
an incomplete definition of the ordinary meaning of the word “combining.” Even Defendants’
own dictionary evidence (when viewed as a whole, without strategic omissions) demonstrates
that “combining,” in its ordinary use of the word, means more than “bringing together;” it means
bringing together and uniting. Second, Defendants’ construction is not at all informed by the
way in which the specification “combines” collaborative data and content data, which is by
uniting that data into a single expression for final filtering.
The overwhelming weight of evidence—if not all of the evidence—on the plain and
ordinary meaning of “combining” demonstrates that I/P Engine’s proposal (which includes
“uniting”) is correct and that Defendants’ proposal (which does not include “uniting”) is wrong.
For example, one of I/P Engine’s dictionaries provides several definitions of
“combining”:
1: a: to bring into such close relationship as to obscure individual characters: MERGE
b: to cause to unite into a chemical compound
c: to unite into a single number or expression . . .
2: INTERMIX, BLEND
3: to possess in combination . . .
1: a: to become one
b: to unite to form a chemical compound
9

2: to act together . . . .
Merriam-Webster’s Collegiate Dictionary, 10th ed., 1998 (D.I. 126, Ex. 4) (emphasis added).
The consistent theme throughout each definition is the concept of uniting/merging. Defendants’
own dictionary defines “combining” similarly as:
1. to bring into or join in a close union or whole; unite: to combine the ingredients for a
cake .
2. to possess or exhibit in union . . . .
3. to harvest (grain) with a combine.
4. to unite; coalesce: The clay and the water combined into a thick paste.
5. to unite for a common purpose; join forces . . . .
6. to enter into chemical union.
7. to use a combine in harvesting.
Random House Webster’s College Dictionary, 2nd ed., 1999 (Ex. 1)(emphasis added)(noun
usage definitions omitted).4 Accordingly, when the entire definition is viewed, Defendants’
evidence fails to support its proposal because it fails to include the concept of “uniting.”5
Defendants incorrectly argue that the claims are somehow unclear about how combining
occurs. D.I. 122 at 14. The claims require the combination of content data/information and
4

The full quotation for definition 1 is “bringing into or join in a close union or whole; unite: to
combine the ingredients for a cake” (emphasis added to portion omitted from Defendants’ Brief).
Notably, the part Defendants omitted confirms I/P Engine’s “uniting” definition, and contradicts
Defendants’ definition. Defendants not only omitted this portion of the dictionary definition in
their Brief, but failed to even provide this Court or I/P Engine with the evidence (i.e., the
dictionary page) as an exhibit. I/P Engine obtained it on its own, and attaches it as Exhibit 1.
5

Other courts have also construed the term “combining,” similar to these definitions, to require
a “union” of two things. See, e.g., Linex Tech, Inc. v. Belkin Int’l., Inc., et al., 2009 WL 361697,
at *17-18 (E.D. Tex. Feb. 12, 2009) (construing “combining” as “forming a single aggregated
version of the received signal . . .”); Power Integrations, Inc. v. Fairchild Semiconductor Int’l.,
Inc., et al., 422 F. Supp. 2d 446, 457 (D. Del. 2006) (construing “combining” as “adding
together”); Omax Corp. v. Flow Int’l. Corp., 2006 WL 3249190, at *5 (W.D. Wash. Nov. 7,
2006) (construing “combining the associated value and the additional parameter” as “a
computerized, mathematical combination of the associated value and the additional
parameter”)(emphasis added); see also Gemstar-TV Guide Intern., Inc. v. Int’l Trade Com’n, 383
F.3d 1352, 1375 (Fed. Cir. 2004)(“The ordinary meaning of ‘combining,’ which is a present
participle of ‘combine,’ is ‘to cause (as two or more things or ideas) to mix together: MINGLE:
BLEND.’”)(citing Webster’s Third New International Dictionary (1993)).

10

collaborative data/information in filtering in the final limitation of each of claim 10 of the ‘420
patent and claim 1 of the ‘664 patent.6 Accordingly, I/P Engine’s proposal corresponds perfectly
with the claim language—the two pieces of data/information are united into a single number or
expression, so that the final number or expression can be employed in filtering.7
The specification describes the combination of content and collaborative data in exactly
the same way. Twice the specification explicitly uses the words “combining” or “integrating” of
content and collaborative data/information when referring to the rating structure that filters
informons. First, it states that “an informon rating system which is like that of FIG. 6 . . .
combines content-based filtering data with collaborative feedback rating data.” D.I. 129, Ex. 1
at col. 25, ll. 56-59 (emphasis added). Second, it states that FIG. 6 is employed for the purpose
of “integration” of the content-based and collaborative-based data. Id. at col. 26, ll. 26-29
(emphasis added). The rating system does the “combining,” and this rating system is fully
explained in the specification and is given its own, dedicated illustration in the patent—FIG. 6.
In FIG. 6, ratings for both content and collaborative data are used in combination functions to
arrive at a complete rating predictor—this is an example of the claimed “combination.” Id. at
col. 14, ll. 40-67. The data is not just “brought together”—it is actually united and integrated so
that, at the next step of the process, the new united and integrated expression of content and
collaborative data can be filtered according to a new overall rating.
6

Claim 10 of the ‘420 patent recites “combining pertaining feedback data from the feedback
system with the content profile data in filtering each informon for relevance to the query.”
Claim 1 of the ‘664 patent recites “combining the information from the feedback system with the
information from the scanning system and . . . filtering the combined information.”
7

Defendants’ claim 5 argument (D.I. 122 at 16) conflates the filtered information entities with
the information (e.g., data) about those entities that are combined for filtering. For claim 5, the
content and collaborative information about advertisements are being combined and the
advertisements are being filtered based on that combined information. The advertisements
themselves are not being combined. That is non-sensical and finds no support or suggestion in
the specification that it is desired or even possible to do so.

11

Next, Defendants incorrectly argue that the embodiment using the “search return
processor” is the alleged preferred embodiment and that it is improperly excluded under I/P
Engine’s claim construction proposal. D.I. 122 at 16. Defendants assert that the “search return
processor” only performs collaborative filtering. Id. But, in the non-quoted second half of the
sentence Defendants rely on, the specification explains that the search return processor “includes
an informon rating system which is like that of FIG. 6.” D.I. 129, Ex. 1 at col. 25, ll. 55-57. The
next sentence continues: “[t]he informon rating system combines content-based filtering data
with collaborative feedback rating data.” Id. at col. 25, ll. 57-59 (emphasis added). Accordingly,
the search return processor embodiment, which Defendants assert is only involved in a
collaborative filtering step of a sequential filter, actually combines, in a single step, the contentbased filtering data with the collaborative data using FIG. 6’s rating structure. As described
above and in I/P Engine’s Opening Brief, the rating system of FIG. 6 produces a final number or
expression (the result of the combination of content and collaborative data) that is used for
filtering. Accordingly, I/P Engine’s proposal excludes no embodiments from coverage under I/P
Engine’s proposal—all combine content and collaborative data in a way that unites or merges
that data into a single number or expression.8

8

The specification contains embodiments that employ additional content-based filters as
prefilters above the combined content and collaborative filter. For example, certain
embodiments (including the embodiment cited by Defendants) employ sequential content-based
prefilters. See, e.g., D.I. 129, Ex. 1 at col. 26, ll. 15-20 (“preprocessing profiles at the top level
of the preferred multi-level filter structure, at least one of which reflects the content profile of a
current wire query”).

12

This Court should adopt I/P Engine’s proposed construction—uniting into a single
number or expression—because it comes directly from the plain and ordinary meaning of
“combined” and is supported by the specification’s consistent usage of the word.9
F.

Different Systems (‘420 Patent, claim 10; ‘664 Patent, claim 1)

I/P Engine’s Proposed Construction
The claim language does not require the
scanning system, content-based filter system,
and feedback system of claim 1 of the ‘664
patent or the claimed system for scanning,
content-based filter system, and feedback
system of claim 10 of the ‘420 patent to be the
same or different “systems.”

Defendants’ Proposed Construction
The claimed “system for scanning a network,”
“content-based filter system,” and “feedback
system” of ‘420 Claim 10 must be different
systems and the claimed “scanning system,”
“feedback system,” and “content-based filter
system” of ‘664 Claim 1 must be different
systems

I/P Engine’s Opening Brief explains that these systems should not be construed as either
the same or different because (1) the claim language is silent as to whether they are different
systems, and (2) the specification explicitly states that the systems can be together on one
machine or separate. Defendants contend that each of these systems must be different—in their
words, “separate and distinct”—but their construction directly contradicts the specification’s
explicit disclosure to the contrary.
Defendants do not point to any language in the claims or the specification that indicates
the recited systems must be completely “separate.” The fact that one system in the claim is
tasked with “combining” information “from” other systems does not mean that the systems need
to be wholly separate and distinct. The specification expressly describes systems that may be
embodied on a single processor or multiple processors, on one or more computers. D.I. 129, Ex.
1 at col. 10, ll. 3-23. This is typical in computer systems when dealing with software.

9

Defendants appear to be posturing for their invalidity arguments by trying to broaden out and
render meaningless this limitation. By making combining so broad, Defendants likely hope to
overlap with prior art that does not actually “combine” the two types of data.

13

Defendants wrongly assert that I/P Engine is taking an inconsistent position with respect
to the prior art. In its Brief, Defendants quote I/P Engine’s validity contentions, but substitute
bracketed text in the hopes of showing that I/P Engine views the claims as requiring different
systems:
“Lashkari does not ‘combine’ the features that Defendants allege meet each of the
two components [scanning system and feedback system] because the cited
features are parts of different systems”
D.I. 122 at 19 (emphasis omitted). But, Defendants’ insert—“[scanning system and feedback
system]”—is misleading and incorrect. The sentence immediately preceding the quote referred
to “two components of information,” not two systems. D.I. 123, Ex. D at 11. With the proper
context of “two components of information,” I/P Engine’s explanation that the Lashkari
reference does not disclose combining two types of information is clear. It has nothing to do
with the claims requiring the same or different systems.
I/P Engine’s claims are not like those in Bristol Co. Ltd. P’ship v. Bosch Rexroth Inc.,
684 F. Supp. 2d 1245 (D. Colo. 2010), which is cited by Defendants in support of their
separateness arguments. D.I. 122 at 18.10 In Bristol, both sides agreed that the claim required
two separate signals as described in the specification. 684 F. Supp. 2d. at 1294. The Bristol
court merely agreed with the “conceded notion” that the two were separate signals. Id.
Defendants provide no support at all for their proposition that the systems must be
separate, and therefore their construction must be rejected. I/P Engine’s proposal should be
adopted.

10

Notably, Defendants cite no binding Federal Circuit authority in support of their position.

14

G.

“demand search” (‘420 Patent, claims 10, 25)

I/P Engine’s Proposed Construction
one-time search performed upon a user request

Defendants’ Proposed Construction
search engine query

I/P Engine proposes that “demand search” be construed as a “one-time search performed
upon a user request.” I/P Engine’s construction is based on the language of the specification that
characterizes the “demand search.”
Defendants’ proposal (“search engine query”) is improper because (1) the phrase “search
engine query” is not found anywhere in the disclosure of these patents or any other intrinsic
evidence, and (2) the proposal itself requires construction to be understandable.
First, Defendants’ proposed construction ignores the intrinsic evidence, which explains
what is meant by “demand search.” The specification equates demand searches with a “oneshot” or “one-time” search (contrasted with a continuous wire search11) that is performed “upon
a user request,” i.e., on demand. D.I. 129, Ex. 1 at Abstract; col. 23, ll. 44-51. Defendants’
definition captures none of this, and provides no clarity to the term whatsoever. Defendants
declare that “[t]he Patents make clear that a ‘demand search’ is just a regular search engine
query.” D.I. 122 at 19. The patents, however, do not once use the phrase “search engine
query.”12

11

Defendants assert that “[b]ecause none of the wire claims are at issue in this litigation, there is
no need to distinguish demand searches from continuing wire searches by using the adjective
‘one-shot’ or ‘one-time’ to describe the demand searches.” D.I. 122 at 22. However, differences
among claims—asserted or unasserted—must be considered in understanding the meaning of
particular claim terms. Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir.
1996) (courts must look to the words of the claims themselves, both asserted and nonasserted, to
define the scope of the patented invention.)

12

In fact, I/P Engine’s construction fits nicely with the Abstract's description of “one shot or
demand searches for information entities which provide at least threshold matches to user
queries.” I/P Engine’s construction captures the idea of a one time search, in response to a user
request or query for information. Defendants counter that I/P Engine’s construction does not
capture the idea of a threshold match. Defendants’ construction also fails to do so, but most
15

Second, the phrase “search engine query” would itself require construction. The parties
have already agreed on the construction of “query” but it is not clear whether Defendants would
apply the same “query” definition here—they indicate this query should be a “regular” search
engine query. Since the phrase “search engine query” is not anywhere in the intrinsic record, nor
is it supported by even any extrinsic evidence, it is unclear what is meant by this term. The
phrase therefore will not provide clarity as to the meaning of the terms.
I/P Engine’s proposal is based on the specification’s description of a “demand search”
and is easily understood. Defendants’ construction should be rejected as unsupported by the
intrinsic evidence.
H.

“individual user”/“first user”

I/P Engine’s Proposed Construction
(for both terms)
no construction necessary

Defendants’ Proposed Construction
(for both terms)
“particular user”

This “dispute” is a waste of judicial resources. There is no need for a construction of
these terms, as proposed by Defendants. Because the parties agree on the meaning of “user,”
there is no reason separately to construe “individual user” or “first user.”
Defendants’ proposal of substituting the words “individual” and “first” for “particular” is
unjustified. Defendants argue that “[b]y distinguishing the ‘individual user’ from all the other
users, the specification suggests that this particular user is different from the others users. . .” and
that Defendants’ proposed construction “acknowledges this ‘particularity’ requirement.” D.I.
122 at 22 (emphasis in original). But, the fact that the specification sometimes mentions a
“particular” user does not provide any reason for substituting words of a claim, e.g., from
“individual user” (in one claim) and “first user” (in another) to a “particular” user. If the
importantly, Defendants misinterpret the Abstract. The search engine provides the threshold
match in response to the demand search; the search itself cannot provide the match.

16

patentees wanted to claim a “particular” user, the specification demonstrates they knew the word
and could easily have done so. Defendants should not be permitted to re-write the claim under
the guise of claim construction. Defendants fail to articulate any reason why “particular” imparts
any additional clarity whatsoever beyond that which the claim already provides with “individual”
and “first.” This Court should decline to construe these extra terms.
I.

“relevance to at least one of the query and the first user”
(‘664 Patent, claims 1, 26)

I/P Engine’s Proposed Construction
Defendants’ Proposed Construction
No further construction necessary beyond other how well information satisfies the information
terms
need of at least one of the query and the first
user
I/P Engine proposes that no construction of the term is necessary, as the parties have
already agreed on the meaning of “relevance,” “query” and “user.” Defendants nonetheless
insist that construction is proper. They state:
“While it is true that the parties have agreed to a construction for ‘relevance to a
query,’ which has some overlap with the longer phrase ‘relevance to at least one
of the query and the first user,’ construing the shorter phrase does not eliminate
the need to construe the latter. To the contrary: because the agreed construction
of ‘relevance to a query’ includes the words ‘query’ and ‘user,’ the jury might be
confused about what additional meaning the additional phrase ‘relevance to at
least one of the query and the first user’ has, absent a construction for this
phrase.”
D.I. 122 at 25 (emphasis in original).
Defendants contend that a jury may be confused as to what “at least one of” means.
First, this cannot be the case: “at least one of” is a completely ordinary phrase. Second,
Defendants’ own construction does not clarify the very phrase that they assert the “jury may be
confused about.” Yet again, Defendants propose an unnecessary construction.

17

J.

“[informons/information] relevant to a query” (‘420 Patent, claims 10, 25)

I/P Engine’s Proposed Construction
[informons/information] having relevance to a
query

Defendants’ Proposed Construction
[informons/information] that satisfy the
individual user’s information need expressed in
the query

The parties agree on the construction of the term “relevance”—it means “how well an
informon satisfies a user’s information need.” D.I. 122 at 23-24. The dispute centers on the
meaning of “relevant.”
I/P Engine has proposed that “relevant” be construed as “having relevance” because the
term “relevance” is clearly defined in the specification and is agreed upon by the parties. I/P
Engine has explained that this approach is also consistent with the plain meaning of the term
“relevant” and its known relationship to the word “relevance.” D.I. 129 at 16-17.
Defendants propose that “relevant” be construed to mean “that satisfy the individual
user’s information need.” But, Defendants’ construction is not consistent with the plain and
ordinary meaning of the phrase “relevant to a query.” An item does not need to satisfy an
information need for it to be relevant to a query. For example, if someone is searching for
“football,” the NFL page of ESPN would be clearly “relevant” to their query; but would not
actually “satisfy” their information need if they were really searching for Canadian football
information. Further, even if they were searching for NFL information, this page would be
“relevant” to the query, but would not “satisfy” the information need if they were actually
seeking a schedule for a particular team. These examples illustrate that Defendants’ construction
requiring items to “satisfy an information need” goes above and beyond requiring items to be
“relevant to a query.”
Another problem with Defendants’ construction is that it establishes a requirement of
“satisfying” the “user’s information need” that is not reflected in the intrinsic record—nothing in

18

the specification describes such a determination. The specification never describes any part of
the system that would (or could) determine whether a user’s need has actually, in fact, been
“satisfied.” Instead, an informon is relevant if it has some degree of relevance (i.e., “having
relevance”). This is consistent with the specification, which describes searching for items
“providing a threshold-level match” to the query. D.I. 129, Ex. 1 at col. 26, ll. 10-20; see also id.
at Abstract (“The search engine system employs a regular search engine to make one-shot or
demand searches for information entities which provide at least threshold matches to user
queries”). This concept of a threshold match embodies the concept that an item can have a
degree of relevance and therefore be relevant.
Defendants’ argument that I/P Engine’s construction is “grammatically nonsensical” is
without merit. The purpose of claim construction is to “determin[e] the meaning and scope” of
the claims. Markman v. Westview Instruments, Inc., 52 F.3d 967, 976 (Fed. Cir. 1995)(en banc).
Constructions do not need to “drop into” the claims with grammatical precision. In this case, the
relationship between relevant and relevance is clearer if one term is defined with respect to the
other. Fundamentally, an item is relevant if it possesses the attribute of relevance. “Relevance”
and “relevant” are different grammatical vehicles for conveying the same concept.
The term “relevant” hardly needs construction at all, especially in view of the agreement
upon relevance, but if it is construed it should not be construed as including a requirement that a
user be “satisfied” by the result. Instead, “relevant” should mean “having relevance.”

19

K.

Order of Method Limitations (‘420 Patent, claim 25; ‘664 Patent, claim 26)

I/P Engine’s Proposed Construction
No “construction” is necessary; if there is any
order, it is reflected in the claim language;
otherwise, no order is required.

Defendants’ Proposed Construction
For ‘420 Claim 25, Step [a] must be performed
before Step [b]; Steps [b] and [c] must be
performed before Step [d]. For ‘664 Claim 26,
Step [c]; Step [c1] (“combining”) must be
performed before Step [c2] (“filtering the
combined information”)

I/P Engine proposes that no construction is necessary for this language. I/P Engine’s
Opening Brief explains that sequential ordering of every method step is not required by the claim
language, and determining if one part of the claim would practically require another to have
already been performed should properly be analyzed in the context of infringement. D.I. 129 at
24-26. This Court should simply decline to address the order of method steps during the claim
construction process.
Defendants’ proposal is problematic for two primary reasons. First, certain of their
proposals require an order that directly conflicts with other language in the claims. For example,
for claim 25, Defendants contend that “Steps [b] and [c] must be performed before Step [d].”
D.I. 122 at 26. The so-called “step [b]” recites receiving informons from the scanning system,
but also recites “filtering the informons on the basis of content profile data for relevance to the
query.” Step [d], however, which Defendants would have occur after step [b], refers back to the
“filtering the informons on the basis of content profile data for relevance to the query” portion of
step [b] by reciting “combining pertaining feedback data with the content profiled data in
filtering each informon for relevance to the query.” So, the “combining” is something that is
done “in filtering” the items for relevance to the query. The “combining,” then, cannot be
required to happen after the “filtering,” as it is integral to the “filtering.” Moreover, Defendants
do not assert that the specification supports “combining” after the “filtering,” and nothing in the
claims themselves require that it happen before the “filtering.”
20

In this instance, so-called step [b] may actually involve two acts: (1) receiving and (2)
filtering. While the receiving content data portion of step [b] and the receiving collaborative data
portion of step [c] must happen before the combining in [d], the “filtering” portion of step [b]
does not necessarily have to happen after (or during) the combining in step [d] because the
combining is done “in filtering each informon for relevance to the query.” Accordingly, not all
of step [b] occurs before step [d].
There is a similar problem with Defendants’ proposed construction of claim 26.
Defendants assert that the “combining” step in c1 must occur prior to the “filtering” step in c2.
D.I. 122 at 27. However, these steps could be a simultaneous process, as the combining is a part
of the filtering. See, e.g., the filtering structure of FIG. 6 which filters by combining. The claim
language does not require separating the two temporally and that would be inconsistent with the
specification. Accordingly, no ordering is required for steps [c1] and [c2].
Second, while some claim language does refer back to prior claim language, this is
typical of all method claims. Whether an infringing process performs its steps in the same order
as the claim is something that will be addressed with experts as they consider infringement.
This Court should decline to address each of Defendants several separate issues relating
to ordering of method steps.

21

L.

Antecedent Basis (‘420 Patent, claims 10, 25; ‘664 Patent, claims 1, 21, 26)

I/P Engine’s Proposed Construction
Where it is required under the law to apply the
same claim meaning to a claim term based on
antecedent basis, I/P Engine agrees that the law
requires the parties to do so.
Thus,
“informons” provides antecedent basis for “the
informons”;
“users” provides antecedent basis for “such
users”;
“a query” provides antecedent basis for “the
query”;
“a feedback system” provides antecedent basis
for “the feedback system”;
“a scanning system” provides antecedent basis
for “the scanning system”;
“a first user” provides antecedent basis for “the
first user” and
“a content-based filter system” provides
antecedent basis for “the content-based filter
system.”

Defendants’ Proposed Construction
For the seven term dyads for which antecedent
basis law applies, the second term in each dyad
must be the same as the first term in the dyad

This Court should reject Defendants’ wasteful request for constructions of several terms
based on antecedent basis. Another district court did so, where Defendants’ counsel made the
same argument it makes here on behalf of Google. See Personalized User Model LLP v. Google
Inc., 2012 WL 295048 (D. Del. Jan. 25, 2012). In that case the court rejected Google’s proposal
to add “refers to the same” limitations to claims when both parties agreed that the terms were
governed by antecedent basis. This Court should also decline to adopt the “are the same as”
language, or go any further than recognizing that antecedent basis applies to these claim terms.
There is no need to add language to every claim merely because the claims properly use
antecedent basis, and Defendants have not identified any material dispute that warrants
construction of these terms.

22

I/P Engine’s construction acknowledges that antecedent basis applies to these terms, but
I/P Engine does not believe that Defendants’ proposal of having this Court construe every
antecedent basis term in every claim with their “the same as” language is proper. Antecedent
basis is a claim drafting technical procedure that exists in the first instance to bring clarity to
claims. Through their argument, Defendants propose a new rule of patent law in which every
antecedent basis term is construed with their “are the same as” construction.
There is no legitimate dispute resolved by construing these terms. Even after the O2
Micro case13 (cited by Defendants numerous times to justify superfluous construction), courts in
this district have rightfully recognized that claim construction is only proper when there is an
“actual, legitimate dispute as to the proper scope of the claims.” Sunbeam Products, Inc. v.
Hamilton Beach Brands, Inc., 2010 WL 3291830, at *1 (E.D. Va. August 19, 2010); see also The
Fox Group, Inc. v. Cree, Inc., 819 F. Supp. 2d 490, 510 (E.D. Va. 2011) (declining to construe
terms were the meaning was “readily apparent from the claim language”). “A district court is
not obligated to construe terms with ordinary meanings, lest trial courts be inundated with
requests to parse the meaning of every word in the asserted claims.” Sunbeam Products, 2010
WL 3291830, at *1 (citing O2 Micro, 521 F.3d at 1360). There is no reason for including this
construction. Defendants’ proposal should be rejected.

13

O2 Micro Int’l Ltd. v. Beyond Innovation Tech. Co., 521 F.3d 1351 (Fed. Cir. 2008) (holding
that a district court erred in declining to construe terms that were the basis of a material dispute
over the scope of the claims).

23

III.

CONCLUSION
For the foregoing reasons, I/P Engine respectfully requests that this Court adopt its claim

constructions.
Dated: May 3, 2012

By: ___ /s/ Jeffrey K. Sherwood________
Donald C. Schultz (Virginia Bar No. 30531)
W. Ryan Snow (Virginia Bar No. 47423)
CRENSHAW, WARE & MARTIN PLC
150 West Main Street
Norfolk, VA 23510
Telephone: [phone]
Facsimile: [phone]
Jeffrey K. Sherwood (Virginia Bar No. 19222)
Frank C. Cimino, Jr.
Kenneth W. Brothers
Leslie Jacobs
Charles J. Monterio, Jr.
Jonathan L. Falkler
DICKSTEIN SHAPIRO LLP
1825 Eye Street, NW
Washington, DC 20006
Telephone: [phone]
Facsimile: [phone]
Counsel for Plaintiff I/P Engine, Inc.

24

CERTIFICATE OF SERVICE
I hereby certify that on this 3rd day of May, 2012, the foregoing I/P ENGINE’S REPLY
CLAIM CONSTRUCTION BRIEF, was served via the Court’s CM/ECF system, on the
following:

Stephen Edward Noona
Kaufman & Canoles, P.C.
150 W Main St
Suite 2100
Norfolk, VA 23510
[e-mail]
David Bilsker
David Perlson
Quinn Emanuel Urquhart & Sullivan LLP
50 California Street, 22nd Floor
San Francisco, CA 94111
[e-mail]
[e-mail]
Robert L. Burns
Finnegan, Henderson, Farabow, Garrett & Dunner, LLP
Two Freedom Square
11955 Freedom Drive
Reston, VA 20190
[e-mail]
Cortney S. Alexander
Finnegan, Henderson, Farabow, Garrett & Dunner, LLP
3500 SunTrust Plaza
303 Peachtree Street, NE
Atlanta, GA 94111
[e-mail]
/s/ Jeffrey K. Sherwood

25