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: (757) 623-3000 Facsimile: (757) 623-5735 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: (202) 420-2200 Facsimile: (202) 420-2201 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: (757) 623-3000 Facsimile: (757) 623-5735 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: (202) 420-2200 Facsimile: (202) 420-2201 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 senoona@kaufcan.com David Bilsker David Perlson Quinn Emanuel Urquhart & Sullivan LLP 50 California Street, 22nd Floor San Francisco, CA 94111 davidbilsker@quinnemanuel.com davidperlson@quinnemanuel.com Robert L. Burns Finnegan, Henderson, Farabow, Garrett & Dunner, LLP Two Freedom Square 11955 Freedom Drive Reston, VA 20190 robert.burns@finnegan.com Cortney S. Alexander Finnegan, Henderson, Farabow, Garrett & Dunner, LLP 3500 SunTrust Plaza 303 Peachtree Street, NE Atlanta, GA 94111 cortney.alexander@finnegan.com /s/ Jeffrey K. Sherwood 25