Opinion
No. C-04-5054 VRW, Consolidated with C-05-2431 VRW.
August 28, 2006
ORDER
Defendant/counterclaimant HyperRoll Israel Ltd ("HyperRoll") owns United States Patent Nos 6,385,604 ("the '604 patent") and 6,434,544 (" the '544 patent"). Plaintiff/counterdefendant Hyperion Solutions Corp ("Hyperion") seeks a declaration that these patents are invalid or alternatively that Hyperion has not infringed any valid claims in these patents. Doc #50 (SAC) ¶¶ 16-22. HyperRoll denies these invalidity and non-infringement contentions and, inter alia, counterclaims that Hyperion has infringed these patents. Doc #162-1 ¶¶ 16-22, 82-89.
On April 19, 2006, the court held a claim construction hearing pursuant to Markman v. Westview Instruments, Inc, 517 US 370 (1996), for the disputed terms in these patents. Based on the parties' submissions to the court and their arguments at the hearing, the court issues the following claim construction order. As the court writes principally for the parties, it will not discuss the details of the inventions or define terms well-known to those skilled in the art, except as is necessary to construe the patent claims.
I
The construction of patent claims is a question of law to be determined by the court. Id at 384. The goal of claim construction is "to interpret what the patentee meant by a particular term or phrase in a claim." Renishaw PLC v. Marposs SpA, 158 F3d 1243, 1249 (Fed Cir 1998). In doing so, the court looks first to the claim itself:
The claims of the patent provide the concise formal definition of the invention. They are the numbered paragraphs which "particularly [point] out and distinctly [claim] the subject matter which the applicant regards as his invention." 35 USC § 112. It is to these wordings that one must look to determine whether there has been infringement. Courts can neither broaden nor narrow the claims to give the patentee something different than what he has set forth. No matter how great the temptations of fairness or policy making, courts do not rework claims. They only interpret them.EI Du Pont de Nemours Co v. Phillips Petroleum Co, 849 F2d 1430, 1433 (Fed Cir 1988).
"The claims define the scope of the right to exclude; the claim construction inquiry, therefore, begins and ends in all cases with the actual words of the claim." Renishaw, 158 F3d at 1248. "The words used in the claim are viewed through the viewing glass of a person skilled in the art." Brookhill-Wilk 1, LLC v. Intuitive Surgical, Inc, 326 F3d 1215, 1220 (Fed Cir 2003) (citing Tegal Corp v. Tokyo Electron Am, Inc, 257 F3d 1331, 1342 (Fed Cir 2001)). "Absent a special and particular definition created by the patent applicant, terms in a claim are to be given their ordinary and accustomed meaning." York Prods, Inc v. Central Tractor Farm Family Ctr, 99 F3d 1568, 1572 (Fed Cir 1996). The court may, if necessary, consult a variety of sources to determine the ordinary and customary meaning of a claim term, including "the words of the claims themselves, the remainder of the specification, the prosecution history, and extrinsic evidence concerning relevant scientific principles, the meaning of technical terms, and the state of the art." Innova/Pure Water, Inc v. Safari Water, 381 F3d 1111, 1116 (Fed Cir 2004).
The court begins its construction of claim terms by consulting intrinsic evidence of the meaning of disputed claim terms, which includes the claims, the specification and the prosecution history (if in evidence). Lacks Industries, Inc v. McKechnie Vehicle Components USA, Inc, 322 F3d 1335, 1341 (Fed Cir 2003) (citation omitted). "If upon examination of this intrinsic evidence the meaning of the claim language is sufficiently clear, resort to `extrinsic' evidence * * * should not be necessary."Digital Biometrics, Inc, v. Identix, Inc, 149 F3d 1335, 1344 (Fed Cir 1998). "[I]f after consideration of the intrinsic evidence, there remains doubt as to the exact meaning of the claim terms, consideration of extrinsic evidence may be necessary to determine the proper construction." Id. Although extrinsic evidence such as expert and inventor testimonies, dictionaries and learned treatises can shed useful light on the relevant art, extrinsic evidence is "less significant than the intrinsic record in determining the legally operative meaning of claim language."Phillips v. AWH Corp, 415 F3d 1303, 1317 (Fed Cir 2005) (quotingC R Bard, Inc v. United States Surgical Corp, 388 F3d 858, 862 (Fed Cir 2004)) (internal quotation marks omitted).
"[A] court may constrict the ordinary meaning of a claim term in at least one of four ways[:]" (1) "if the patentee acted as his own lexicographer and clearly set forth a definition of the disputed claim in either the specification or prosecution history;" (2) "if the intrinsic evidence shows that the patentee distinguished [the] term from prior art on the basis of a particular embodiment, expressly disclaimed subject matter, or described a particular embodiment as important to the invention;" (3) "if the term chosen by the patentee so deprives the claim of clarity as to require resort to the other intrinsic evidence for a definite meaning;" or (4) "if the patentee phrased the claim in step- or means-plus-function format," then "a claim term will cover nothing more than the corresponding structure or step disclosed in the specification, as well as equivalents thereto * * *." CCS Fitness, Inc v. Brunswick Corp, 288 F3d 1359, 1366-67 (Fed Cir 2002) (internal citations and quotation marks omitted).
Limitations from the specification, such as from a preferred embodiment, cannot be read into the claims unless expressly intended by the patentee. Teleflex, Inc v. Ficosa North Am Corp, 299 F3d 1313, 1326 (Fed Cir 2002) ("The claims must be read in view of the specification, but limitations from the specification are not to be read into the claims."). And "a construction that excludes a preferred embodiment `is rarely, if ever, correct.'"C R Bard, 388 F3d at 865 (citing Vitronics Corp v. Conceptronic, Inc, 90 F3d 1576, 1583 (Fed Cir 1996)).
With these legal principles in mind, the court now construes the disputed claim language in the patents.
II The '604 patent
A. "Relational database management system (RDBMS)"Relational database management system," or RDBMS, appears in the preambles of independent claims 1 and 15 and dependent claims 2-14. The term also appears in the body of dependent claim 20, which indirectly stems from independent claim 1, and dependent claims 21-22, which stem from independent method claim 15. HyperRoll contends that construing the term is unnecessary because "[t]he body of independent claim 1 defines a complete invention * * *." Doc #194-1 (HyperRoll Br) at 4. If construed, HyperRoll proposes, "[A] database that is organized and accessed according to relationships between data items." Doc #198, Ex A (Joint Cl Const) at 3.
Hyperion counters that RDBMS should be construed because, based on the title of the invention, specification and prosecution history, "it is clear that the claims only have meaning in light of the context of an RDBMS and that integration within an RDBMS is a fundamental characteristic of the claim invention that is properly construed as a limitation of the claim itself." Doc #193 (Hyperion Br) at 8. Hyperion proposes a lengthy construction: "a software program in which (1) the data is perceived by the user as stored exclusively in tables; and (2) the operators (i.e., queries) available to the users generate new tables." Joint Cl Const at 3.
The Federal Circuit has noted that determining whether a preamble limits claim scope requires a "review of the entire * * * patent to gain an understanding of what the inventors actually invented and intended to encompass by the claim."Catalina Marketing Intl v. Coolsavings.com, Inc, 289 F3d 801, 808 (Fed Cir 2002) (quoting Corning Glass Works v. Sumitomo Electric USA, Inc, 868 F2d 1251, 1257 (Fed Cir 1989). In general:
[A] preamble limits the invention if it recites essential structure or steps, or if it is necessary to give life, meaning, and vitality to the claim. Conversely, a preamble is not limiting where a patentee defines a structurally complete invention in the claim body and uses the preamble only to state a purpose or intended use for the invention.
Id (internal quotations and citations omitted). Although "[n]o litmus test defines when a preamble limits claim scope," id at 808-09, the Federal Circuit has identified certain "guideposts" to help determine the preamble's effect on claim scope. For example, the preamble may limit claim scope if: (1) A claim depends on a preamble phrase for antecedent basis, id at 808; (2) "[T]he preamble is essential to understand limitations or terms in the claim body," id; (3) The preamble "recit[es] additional structure or steps underscored as important by the specification," id or (4) The patentee "clear[ly] reli[ed] on the preamble during prosecution to distinguish the claimed invention from the prior art," id. On the other hand, a preamble does not limit claim scope merely because it "extol[s] benefits or features of the claimed invention" or "describ[es] the use of an invention." Id at 809.
Based on these considerations, the court concludes that RDBMS need not be construed. Hyperion argues that although RDBMS is in the preamble, the term further limits the scope of the claims because an RDBMS is central to the present invention, as demonstrated by the title, specification and prosecution history of the '604 patent. Hyperion Br at 8. But this argument misses the mark. The centrality of the RDBMS to the present invention is not the issue; rather, the question is whether the body of a claim recites sufficient structure to define an RDBMS. This requires comparing the claimed structure to the embodiments described in the specification; if the body of the claim covers an embodiment of an RDBMS described in the specification, the body has recited sufficient structure and no additional structure need be inferred from the preamble.
Claim 1, which appears to be the primary disputed claim on this point, states:
1. A relational database management system (RDBMS) comprising:
a relational data store storing fact data; an aggregation module, operatively coupled to the relational data store, for aggregating the fact data and storing the resultant aggregated data in a non-relational multi-dimensional data store;
a query servicing mechanism, operatively coupled to the aggregation module, for servicing query statements generated in response to user input, said query servicing mechanism comprising:
a reference generating mechanism for generating a user-defined reference to aggregated fact data generated by the aggregation module; and
a query processing mechanism for processing a given query statement, wherein, upon identifying that the given query statement is on said user-defined reference, communicates with said aggregation module over an interface therebetween to retrieve portions of aggregated fact data pointed to by said reference that are relevant to said given query statement.
'604 patent at claim 1. The components described in this claim generally mirror those depicted in FIG 6A, which shows a relational data store, a multi-dimensional data aggregation module and some type of query processing or support mechanism. Compare id at claim 1 with id at FIG 6A. Because the patent describes FIG 6A as "a schematic representation of a generalized embodiment of an RDBMS of the present invention," id at 8:46-47, the RDBMS in claim 1 appears structurally complete based on the body of the claim alone. This is not to say that claim 1 or any of the other claims are limited to the embodiment depicted in FIG 6A. Rather, the court simply notes that because the body of claim 1 roughly parallels the embodiment in FIG 6A, there is no need to read in additional limitations based on the preamble.
Still, the court observes that the bodies of dependent claims 20-22 add other limitations to the "RDBMS." See, e.g., id at claim 21 ("The method of claim 15, wherein said RDBMS is used as an enterprise wide data warehouse that interfaces to a plurality of information technology systems."). This usage of RDBMS in these dependent claim bodies suggests that the term might serve as an additional limitation in independent claims 1 and 15, even though those claims mention "RDBMS" only in their preambles. SeeCatalina Marketing Intl, 289 F3d at 808.
But even if RDBMS did limit independent claims 1 and 15, Hyperion's proposed construction would be problematic because of its heavy and unnecessary reliance on an extrinsic source, C J Date, An Introduction to Database Systems, Addison-Wesley, Seventh Edition, 2000 ("C J Date"). The Federal Circuit has suggested that the specification includes sources that are incorporated by reference. See AquaTex Industries, Inc v. Techniche Solutions, 419 F3d 1374, 1378, 1381 (Fed Cir 2005). Although the patent cites to different portion of C J Date and incorporates these sections by reference, Hyperion's construction relies on an uncited portion of that book. Hyperion Br at 9-10. Hyperion counters that the patent actually incorporated theentire book by reference and therefore this uncited portion constitutes intrinsic evidence. But this argument makes little sense given that the patent cites to different portions of C J Date on three separate occasions and each time states that the source is "incorporated by reference in its entirety." See '604 patent at 4:6-11; 12:47-52; 12:60-64. If the patent had actually incorporated the entire book, then it would not have done so three times. Rather, the multiple incorporations indicate that the patent only incorporated the particular sections of the book that were relied upon. Hyperion's construction therefore primarily rests on extrinsic evidence and is disfavored.
In sum, the court rejects Hyperion's proposed construction and declines to construe RDBMS.
B. "Query statement"
This term appears in claims 1-3, 5, 11, 15, 16, 18 and 24. Hyperion contends that "[t]he '604 Patent distinguishes between a `query' and a `query statement.'" Hyperion Br at 10. In particular, Hyperion posits that "[a] query is received by the query interface (either directly from the user, or from a client machine operated by the user)" but "[a] query statement * * * is generated by the query interface in response to the query, and used in examining the user-defined reference to aggregated fact data." Id at 11 (emphasis omitted). Hyperion further asserts that "since the DBMS is relational, the query statement is a relational database language request." Id. HyperRoll counters that construction of this term would be inappropriate because Hyperion "did not assert that the term `query statement' needed construction in its original Pat L R 4-1 contentions served on October 7, 2005." Joint Cl Const at 20. If the term is construed, HyperRoll proposes the definition, "a search question that tells the program what kind of data should be retrieved from the database." Id at 20-21.
Putting aside Hyperion's purported procedural default, a rigid distinction between "query" and "query statement" is not supported by the specification. "Query statement" appears only twice in the specification and on each occasion, the patent uses the term interchangeably with "query." Id at 10:66-11:2 ("The query interface and query handler service user-submitted queries (in the preferred embodiment, SQL query statements) forwarded, for example, from a client machine over a network as shown." (emphasis added)); id at 11:40-43 ("The SQL handler of the MDD Aggregation module services user-submitted queries (in the preferred embodiment, SQL query statements) forwarded from the query handler of the RDBMS." (emphasis added)). Hence, this usage indicates that contrary to Hyperion's construction, "query" and "query statement" can be synonymous with one another.
Moreover, although dependent claims 11 and 24 distinguish between "query statements" and a "natural language query," this indicates that, at best, a "query" and a "query statement" can be different. Nowhere do the specification or claims demand the unbending distinction that Hyperion proposes.
Additionally, Hyperion's proposed definition unnecessarily limits query statements to those made in a "relational database language." This definition impermissibly incorporates limitations from a preferred embodiment depicted in FIGS 6A-6B of the specification. See Teleflex, 299 F3d at 1326. Because the court agrees with HyperRoll that "[t]he patent uses `query' and `query statement' according to common meanings," HyperRoll Br at 15, the court declines to construe either of these terms.
C. "User-defined reference to aggregated fact data"
This term appears in claim 1. Hyperion proposes that the term means a "link from a relational database language request to data in a multidimensional data store." Hyperion Br at 11. HyperRoll instead contends that the term means a "user-defined pointer to aggregated fact data." HyperRoll Br at 16.
Hyperion's proposed construction is problematic for many reasons. First, Hyperion seeks to incorporate implicitly its proposed construction for "query statement" ("relational database language request"), which is a construction the court has already rejected. Second, Hyperion's proposed construction improperly reads out the requirements that the reference be "user-defined" and that the fact data be "aggregated."
Morever, Hyperion improperly limits the definition of this term based on a disclosed embodiment in the specification. Hyperion relies on the steps shown in the flow chart in FIGS 6C1 and 6C2 to contend that "[t]he '604 Patent itself describes the `user-defined reference to aggregated fact data' as providing a link from a relational database language request to data in a multidimensional data store." Hyperion Br at 11. But even if this were true, it would be improper to limit the claim based solely on this disclosed embodiment, as the court has already explained.
Additionally, Hyperion's construction improperly limits the term "reference" to a "link." In describing an exemplary embodiment of a "reference," the patent notes:
This reference is preferably defined using the Create View SQL statement, which allows the user to: i) define a table name (TN) associated with the MDD database stored in the MDD Aggregation Module, and ii) define a link used to route SQL statements on the table TN to the MDD Aggregation Module.
Id at 12:39-44 (emphasis added). This description indicates that at least in some embodiments, a reference may be more than just a link and may also include a "table name" associated with the MDD database.
Hyperion correctly notes that during reexamination, HyperRoll distinguished this patent over a prior art reference by noting that the user-defined reference "allows a user of the RDBMS to query aggregated fact data stored in a multidimensional data store that is separate from the relational data store." Hyperion Br, Ex G at 27-28. But contrary to Hyperion's suggestion, it would be redundant to import any of these limitations into the definition of "user-defined reference to aggregated fact data" because claim 1 already includes these limitations. '604 patent at claim 1 (A "user-defined reference" is used "to retrieve portions of aggregated fact data" stored "in a non-relational multi-dimensional data store" that is part of an "aggregation module" separate from a "relational data store.").
The court agrees with HyperRoll that the term "user-defined" and "aggregated fact data" do not need additional construction, as their plain meaning corresponds with their usage in claim 1. The court, however, declines to follow HyperRoll's proposed construction of a "reference" as a "pointer." A "pointer" is a specific and well-known term of art in computer science. See, e. g., Microsoft Computer Dictionary 348 (4th ed 1999) ("pointer * * * "[i]n programming and information processing, a variable that contains the memory location (address) of some data rather than the data itself"). Although the court does not dispute that in some embodiments a "reference" might be a "pointer," the court does not read claim 1 as requiring a "reference" to be limited necessarily to just a pointer. Moreover, the meaning of "reference" is clear from its usage in claim 1 and no further construction is needed.
In sum, the court rejects both parties' proposed constructions and declines to construe this term.
D. "Interface therebetween"
For this seemingly simple term, Hyperion proposes a long and complicated construction: a "component that maps the data types of a relational database request (or a standard data type used to represent the relational database request) into the data types used in a multidimensional database aggregation module." Joint Cl Const at 27. HyperRoll counters that any construction of this term would be inappropriate because Hyperion "did not assert that the term `interface therebetween' needed construction in its original Pat L R 4-1 contentions." Joint Cl Const at 27. If the term is construed, HyperRoll proposes the definition, "an interface between the aggregation module and the query processing mechanism." Id at 27-28.
Hyperion contends that "the `interface' HyperRoll argued to the PTO was obviously different than the traditional `interface.'" Doc #197 (Hyperion Reply Br) at 6. In particular, Hyperion points to a specific embodiment of the interface described in the specification and contends that FIG 6A was "amended by HyperRoll to depict the SQL Interface in order to convince the PTO to allow the claims." Hyperion Br at 13.
First, Hyperion is incorrect in contending that HyperRoll amended the drawings to distinguish the invention from the prior art. The examiner had stated "that the applicants need to ensure that the interfaces are supported in the specification, claims, and Figures." Doc #193, Ex C at 2. In response, the applicants added the "SQL Interface" to FIGS 6A and 13 and added the "over an interface therebetween" language to claim 1. Id at 4, 7, 19. The prosecution history does not suggest that this claim limitation only encompassed the SQL Interface depicted in the exemplary embodiments shown in FIGS 6A and 13.
More importantly, Hyperion's proposed construction impermissibly limits this term to an exemplary embodiment and fails to recognize that the specification states that a variety of interface types can be used:
The SQL handler of the MDD Aggregation module may communicate with the query handler of the RDBMS over a standard interface (such as OLDB, OLE-DB, ODBC, SQL, API, JDBC, etc.). In this case, the support mechanisms of the RDBMS and SQL handler include components that provide communication of such data over these standard interfaces. Such interface components are well known in the art.
'604 patent at 11:43-50. Although the "standard interfaces" described here apparently are SQL interfaces, this broad language indicates that the "interface" need not be as limited as Hyperion suggests.
Moreover, Hyperion's proposed construction would render superfluous dependent claims 13 and 14, which specify respectively that the "interface" in claim 1 can be a "standard interface" and that the "standard interface is selected from the group consisting of OLDB, OLE-DB, ODBC, SQL, JDBC." By requiring the "interface" to handle relational database requests, Hyperion's proposed construction would violate "[t]he doctrine of claim differentiation[, which] `creates a presumption that each claim in a patent has a different scope.'" Free Motion Fitness, Inc v. Cybex Intl, 423 F3d 1343, 1351 (Fed Cir 2005) (quotingComark Communications, Inc v. Harris Corp, 156 F3d 1182, 1187 (Fed Cir 1998)).
On the contrary, HyperRoll's simpler construction mirrors the language in claim 1, as the "interface therebetween" is described as an interface between the query processing mechanism and the aggregation module. '604 patent at claim 1. Accordingly, the court adopts HyperRoll's proposed construction.
E. "Integrated aggregation module"
"Integrated aggregation module" appears in independent claim 15. Hyperion contends the term means a "module, performing aggregation, that is contained within an RDBMS program." Joint Cl Const at 33. HyperRoll instead contends that the term should be construed as a "software module that aggregates fact data and that works with an RDBMS." Id. Accordingly, the primary dispute here appears to be whether the module is contained within the RDBMS or instead whether it merely works with the RDBMS.
Hyperion contends that the prosecution history supports its construction because a patent examiner stated in a summary of an October 16, 2001, interview that "[t]he difference between the invention and the prior art is the approach that integrates the MDDB into an RDBMS in order to gain the benefits from each while overcoming the limitations of each." Doc #197, Ex B at 1. Hyperion's argument does not even get off the ground because "it is the applicant, not the examiner, who must give up or disclaim subject matter that would otherwise fall within the scope of the claims." Sorensen v. ITC, 427 F3d 1375, 1379 (Fed Cir 2005) (internal citations and quotations omitted). But even if the applicant had made the statement that Hyperion relies upon, the language is ambiguous enough to support either HyperRoll's or Hyperion's constructions. See id at 1378-79 ("Disclaimers based on disavowing actions or statements during prosecution * * * must be both clear and unmistakable.").
Moreover, Hyperion's claim construction is problematic because it introduces the term "contained within," whose meaning is unclear. Indeed, Hyperion itself provided varying definitions of "contained within" in its opening brief and its reply brief. In its opening brief, Hyperion explained: "[C]omputer code that makes up the `aggregation module' is contained within the computer code that makes up the RDBMS program. If they are separate pieces of software, they are not be [sic] integrated." Hyperion Br at 13-14. In its reply brief, however, Hyperion proposed a somewhat different definition: "If the module cannot operate independently of the RDBMS program, [the module] is `contained within' the RDBMS program and thus integrated within it. If [the module] can operate independently of the RDBMS program, then [the module] is not integrated within it." Hyperion Reply Br at 7. Hence, Hyperion has provided two different definitions of "contained within:" the first focuses on the location of the software module's code whereas the second focuses on the functionality of the module. Accordingly, Hyperion's proposed construction would not clarify the meaning of the term "integrated aggregation module."
Moreover, at no point does the specification require that software code for the "integrated aggregation module" be physically located in the same software code for the RDBMS. Rather, the specification appears to describe the relationship between the "integrated aggregation module" and the components in the RDBMS in functional terms. See '604 patent at FIG 6A and accompanying discussion. Common sense also suggests that the patentees did not intend to require the code for the "integrated aggregation module" to be located physically within the RDBMS, given that it would be trivial to design around such a claimed invention; for example, a software designer could link the "integrated aggregation module" to the RDBMS to avoid including the module's code within the RDBMS but to achieve the same result.
Nonetheless, HyperRoll's definition also is problematic because it unnecessarily imports functional limitations into the definition of "integrated aggregation module." The claim language already describes the functional relationship between the "integrated aggregation module" and the other components in the RDBMS. See '604 patent at claim 15 ("providing an integrated aggregation module, operatively coupled to the relational data store, for aggregating the fact data and storing the resultant aggregated data in a non-relational multi-dimensional data store"). Hence, it would be superfluous to interpret "integrated aggregation module" as containing these functional limitations.
Although the court presently declines to construe "integrated aggregation module," it flags two issues that might become relevant later. First, although not raised by either party, the court notes that the term "integrated aggregation module" appears to be used in claim 15 in almost the identical manner in which "aggregation module" is used in claim 1. Compare '604 patent at claim 1 ("an aggregation module, operatively coupled to the relational data store, for aggregating the fact data and storing the resultant aggregated data in a non-relational multi-dimensional data store") with id at claim 15 ("providing an integrated aggregation module, operatively coupled to the relational data store, for aggregating the fact data and storing the resultant aggregated data in a non-relational multi-dimensional data store"). This suggests either that the term "integrated" adds a separate limitation in claim 15 that does not exist in claim 1 or that the patentees are essentially using "aggregation module" and "integrated aggregation module" interchangeably. If necessary, this issue could be revisited at a later stage in these proceedings.
Additionally, it is conceivable, as Hyperion suggests, that the claim language sweeps too broadly and encompasses "clearly disparate programs [that should not] be considered `integrated' in an RDBMS." Hyperion Reply Br at 7. The proper time for Hyperion to raise this argument is at the summary judgment stage, at which time it may argue that the patent is invalid in light of the prior art.
At the present time, however, because the meaning of "integrated aggregation module" is sufficiently clear based on the claim language, the court declines to construes this term.
F. Terms for which the parties dispute whether 35 USC § 112(6) applies
For each of the following terms, the parties dispute whether they should be interpreted as means-plus-function terms under 35 USC § 112(6). Hyperion contends that all of these terms should be interpreted under that provision. Moreover, Hyperion asserts that the specification does not recite sufficient structure to perform the claimed function for any of these terms and therefore they are indefinite and the claims in which they appear are invalid. Hyperion Br at 14-18. HyperRoll, not surprisingly, disputes all of these contentions. HyperRoll Br at 20-24.
In essence, the disputes surrounding these terms appear to center on whether the term "mechanism" implicates 35 USC § 112(6). Compare Toro Co v. Deere Co, 355 F3d 1313, 1325 (Fed Cir 2004) (finding that the term "control mechanism" was a means-plus-function term). "A claim limitation that actually uses the word `means' invokes a rebuttable presumption that § 112(6) applies. By contrast, a claim term that does not use `means' will trigger the rebuttable presumption that § 112(6) does not apply."CCS Fitness, 288 F3d at 1369 (citation omitted). Because the word "means" does not appear in the term, a rebuttable presumption exists that § 112(6) does not apply. As the party seeking to invoke § 112(6), Hyperion can overcome this presumption by showing, by a preponderance of the evidence, that the claim limitation "fails to recite sufficiently definite structure or else recites a function without reciting sufficient structure for performing that function." Apex Inc v. Raritan Computer, Inc, 325 F3d 1364, 1372 (Fed Cir 2003) (quotations omitted).
The threshold issue "is whether the term itself connotes sufficient structure to one of ordinary skill in the art to perform the functions identified by each limitation." Id at 1373; see also Greenberg v. Ethicon Endo-Surgery, Inc, 91 F3d 1580, 1583 (Fed Cir 1996) ("What is important is not simply that [the term] is defined in terms of what it does, but that the term, as the name for structure, has a reasonably well understood meaning in the art."). It is appropriate to consult dictionaries in connection with this inquiry. Linear Technology Corp v. Impala Linear Corp, 379 F3d 1311, 1320 (Fed Cir 2004); see also Apex, 325 F3d at 1373.
Because Hyperion has not stated the level of ordinary skill in the art, the court adopts HyperRoll's proposed expertise level, which the court believes is reasonable. See HyperRoll Br at 4 ("A person of ordinary skill in the relevant art has an undergraduate degree in computer science, computer engineering, management information sciences, or the equivalent, and three to five years experience as a database programmer or analyst."). Nonetheless, the court notes that its analysis for each of these terms would not change appreciably if the court were to adopt a somewhat higher or lower expertise level for one skilled in the
art. 1. "Query servicing mechanism, operatively coupled to the aggregation module, for servicing query statements generated in response to user input"
The court concludes that the term "query servicing mechanism" as used in claims 1, 3 and 5 would connote sufficient structure to enable one skilled in the art to create that component. First, technical dictionary definitions contemporaneous with the filing of the patent application suggest that the term itself connotes some structure. See IBM Dictionary of Computing 549 (10th ed 1994) ("query: (1) a request for data from a database, based on specified conditions"). Cf Microsoft Computer Dictionary 404 (4th ed 1999) ("service: * * * (3) In networking, a specialized, software-based functionality provided by network servers — for example, directory services that provide the network equivalent of `phone books' needed for locating users and resources."). Moreover, the claim describes at least some structure, noting that the "query servicing mechanism" is "operatively coupled to the aggregation module" and that the mechanism services "query statements."
But perhaps most persuasive is that as a practical matter, the court believes that a person of ordinary skill in the art would be able to build a "query servicing mechanism" given that databases and querying are, after all, well-known and ubiquitous technologies. See, e.g., IBM Dictionary of Computing 549 (10th ed 1994) (citing as an example of querying "a request for availability of a seat on a flight reservation system"). And in any event, Hyperion has not shown that it is more likely than not that one of ordinary skill would be unable to build this component. Accordingly, the court rejects Hyperion's proposed means-plus-function construction and declines to construe this term.
2. "Query processing mechanism for processing a given query statement, wherein, upon identifying that the given query statement is on said user-defined reference, communicates with said aggregation module over an interface therebetween to retrieve portions of aggregated fact data pointed to by said reference that are relevant to said given query statement"
The analysis for the previous term also applies to the term "query processing mechanism," which appears in claims 1, 2 and 13. Technical dictionaries, the claim language and common sense indicate that one having ordinary skill would be able to design a software component that, in essence, identifies a particular kind of query and if appropriate, communicates with another module over an interface and retrieves certain data. See Microsoft Computer Dictionary 359 (4th ed 1999) ("processing * * * "The manipulation of data within a computer system. Processing is the vital step between receiving data (input) and producing results (output) — the task for which computers are designed."). Hence, the court rejects Hyperion's proposed means-plus-function construction and declines to construe this term.
3. "Reference generating mechanism for generating a user-defined reference to aggregated fact data generated by the aggregation module"
The court concludes that the term "reference generating mechanism" as used in claim 1 would connote sufficient structure to one skilled in the art to construct that component. As with the previous terms, technical dictionaries suggest that generating "references" is something that a person of ordinary skill in the art could do. Cf Microsoft Computer Dictionary 378 (4th ed 1999) ("[to] reference * * * "To access a variable, such as an element in an array or a field in a record"). And again, the claim language provides some structure to guide a would-be programmer. Moreover, as mentioned earlier, a "reference" may simply be a "pointer" in some embodiments; common sense indicates that at least in these situations, one skilled in the art would be capable of creating a program that generates something as basic as a pointer. Accordingly, the court reject Hyperion's proposed means-plus-function construction and declines to construe this term.
4. "Data loading mechanism for loading at least fact data from the relational data store"
For the same reasons as for the previous terms, the court concludes that the term "data loading mechanism" as used in claims 4, 5, 17 and 18 would connote sufficient structure to one skilled in the art to build that component. Accordingly, the court rejects Hyperion's proposed means-plus-function construction and declines to construe this term.
III The '544 patent
A. "Data aggregation server" and "stand-alone data aggregation server"The term "data aggregation server" appears with the modifier "stand-alone" only in the preamble of independent claim 1 and in the preambles of its dependent claims. As used in claim 1, it is apparent that "data aggregation server" and "stand-alone data aggregation server" refer to the same structure. See '544 patent at claim 1 ("A stand-alone data aggregation server" later referred to as "the data aggregation server comprising"). Hence, although these terms were briefed separately, the court construes them simultaneously.
Hyperion contends that "data aggregation server" means a "computer system programmed to perform data aggregation functions and not analysis or graphical user interface functions." Joint Cl Const at 48. Hyperion further contends that a "stand-alone data aggregation server" is a "data aggregation server that is external (self-contained) and operable independently from an OLAP server." Id at 51.
HyperRoll contends that both of these terms should not be construed because Hyperion did not assert they needed construction in Hyperion's original Pat L R 4-1 contentions. Id at 48. Hyperion also contends that these terms do not need to be construed because they appear in only the preamble of the claims. HyperRoll Br at 4, 7. To the extent the court does construe these terms, HyperRoll defines "data aggregation server" as a "system or computer program for performing data aggregation functions" and "stand-alone data aggregation server" as a "data aggregation server that works with an independently operable OLAP server." Joint Cl Const at 48, 51.
First, the preamble of independent claim 1 appears to limit claim scope because limitations in the bodies of various claims derive their antecedent basis from the preamble. Compare '544 patent at claim 1 preamble ("A stand-alone data aggregation server for use with any one of a plurality of different OLAP servers * * *." (emphasis added)) with id at claim 1 body ("the interface receiving requests communicated from any one of said plurality of differe[nt] OLAP servers") and id at claim 2 body ("wherein the plurality of different OLAP servers comprise a plurality of different OLAP servers distributed by different vendors"). See also Catalina Marketing Intl, 289 F3d at 808 ("[D]ependence on a particular disputed preamble phrase for antecedent basis may limit claim scope because it indicates a reliance on both the preamble and claim body to define the claimed invention. Likewise, when the preamble is essential to understand limitations or terms in the claim body, the preamble limits claim scope.").
Turning to construction of the term, the crux of the dispute between the parties appears to center on two issues: (1) whether the data aggregation server can perform "analysis or graphical user interface functions" or whether it is limited to performing "data aggregation functions" and (2) whether the data aggregation server is "external (self-contained) and operable independently from an OLAP server" or whether the server merely works with an independently operable OLAP server.
Regarding the first issue, the court finds that Hyperion's construction improperly limits the functions that a data aggregation server can perform. This is evident based on dependent claim 5, which states: "The stand-alone data aggregration [sic] server of claim 1, wherein computational tasks performed by the aggregation engine is [sic] restricted to data aggregation operations." Because Hyperion's proposed construction would render this claim superfluous, it conflicts with the doctrine of claim differentiation and is disfavored. See Free Motion Fitness, 423 F3d at 1351 (Fed Cir 2005) (quotingComark, 156 F3d at 1187). On the other hand, HyperRoll's proposed definition for "aggregation server" is consistent with the specification and claim language. See, e.g., '544 patent at 10:17-21 ("[T]he stand-alone Aggregation Server [in FIG 6A] performs aggregation functions (e.g. summation of numbers, as well as other mathematical operations, such as multiplication, subtraction, division etc) and multi-dimensional data storage functions"); id at claim 1 (the "data aggregation server" includes an "aggregation engine" that "perform[s] data aggregation operations").
Regarding the second issue, HyperRoll appears to interpret the modifier "stand-alone" as requiring the OLAP server to be "independently operable." But "stand-alone" does not modify "OLAP server;" "stand-alone" modifies "aggregation server," thereby suggesting that the aggregation server must be the claim element that is able to stand by itself.
But what does it mean to "stand alone?" The specification uses the term "external" interchangeably with "stand-alone." See '544 patent at 6:52-53 ("novel stand-alone (i.e., external) data aggregation server"). The specification also teaches that a stand-alone aggregation server could be physically external to an OLAP server. See, e.g., id at 13:19-27 ("[T]he Aggregation Server 603 can be plugged into (e.g. interfaced to) OLAP Servers (two shown as 605' and 605") of different users or vendors. * * * This dramatic move discontinues the restricting dependency of aggregation from the analytical functions of OLAP * * *."). But the specification further teaches that a "stand-alone" aggregation server need not be physically external to the OLAP server, as demonstrated by one embodiment in which the data aggregation server "shares the same hardware platform and operating system (OS) that [is] used to run the [OLAP server]." Id at 15:44-46. Hence, "standing alone" does not necessitate physical separation between the aggregation server and the OLAP server.
Rather, the specification consistently describes the "stand-alone" aggregation server as functionally separate from, but working with, an OLAP server. See, e.g., FIGS 6A, 6E, 7A, 7B. It would appear that, at a minimum, this would require the software module for the stand-alone aggregation server to be "separate" from the software module for the OLAP server; otherwise, the "stand-alone" limitation would be meaningless. This usage fits with Hyperion's proposed construction, which requires the "stand-alone aggregation server" to be "external [to] and operable independently from an OLAP server." Relevant technical dictionaries also support Hyperion's construction. SeeWebster's New World Computer Dictionary 354 (10th ed 2003) ("standalone * * * [s]elf-sufficient; not requiring any additional component or service"); IBM Dictionary of Computing 644 (10th ed 1994) ("stand-alone * * * [p]ertaining to operation that is independent of any other device, program, or system"); Microsoft Computer Dictionary 421 (4th ed 1999) ("stand-alone or standalone * * * [o]f, pertaining to, or being a device that does not require support from another device or system, for example, a computer that is not connected to a network"). Accordingly, it appears that for an "aggregation server" to "stand alone," the aggregation server must be able to operate, at least to some extent, independently of the OLAP server.
In sum, the court adopts HyperRoll's definition of an "aggregation server" as a "system or computer program for performing data aggregation functions." The court adopts a blend on the parties' constructions for a "stand-alone aggregation server," which is "an aggregation server that could operate independently from, but works with, an OLAP server."
B. "OLAP server" and "for use with any one of a plurality of different OLAP servers"
"OLAP server" appears in claims 1, 2, 6, 7, 12 and 13 of the '544 patent and "for use with any one of a plurality of different OLAP servers" appears in claim 1 of that patent. Although the parties briefed these terms separately, the court construes them at the same time. Hyperion contends the term "OLAP server," while known in the art, is indefinite because "HyperRoll * * * elected to use two separate and contradictory definitions of `OLAP Server' in the '544 Patent." Hyperion Br at 14. Hyperion further contends that "for use with any one of a plurality of different OLAP servers" means "capable of being used concurrently with more than one OLAP Server." Id at 13.
HyperRoll instead asserts that one of ordinary skill in the art would know that the "OLAP server" is the OLAP server of the prior art, i.e., a "system or program that accesses data stored in data stores to provide decision support." HyperRoll Br at 10. HyperRoll asserts that "for use with any one of a plurality of different OLAP servers" means "capable of being used with different OLAP servers." Joint Cl Const at 57.
The dispute between the parties on these terms boils down to two issues: (1) Is the term "OLAP server" indefinite? (2) Does "for use with any one of a plurality of different OLAP servers" require the stand-alone data aggregation server to be capable of being used concurrently with more than one OLAP server?
First, Hyperion asserts that the conventional, prior art use of an OLAP server is a server that performs aggregation functions. Hyperion Reply Br at 14. Hyperion contends that the patent uses this definition for OLAP server in the background section, but then the patent "describe[s] an embodiment where the aggregation functionality is moved from the OLAP server to a stand-alone data aggregation server. This removes what is considered to be the essential functionality of an OLAP server from the OLAP server. * * * [O]nce the aggregation functionality is removed from an OLAP server, it is no longer an OLAP server, it is something else." Hyperion Br at 23.
Hyperion is correct that the patent uses the term "OLAP server" both to refer to the prior art server that included aggregation functionality and the present invention in which the aggregation functionality is moved to a separate, stand-alone data aggregation server. But this does not render the term indefinite. Contrary to Hyperion's contention, the prior art OLAP server as described in the patent could perform some functions other than aggregation. See, e.g., FIG 1B (showing a prior art "multidimensional OLAP server" containing an "aggregation access and retrieval module," an "application logic module" and a "presentation module"). A person of ordinary skill in the art, having read the patent and the claims, would conclude that the "OLAP server" as described in claim 1 retains at least some of these other functions, even if the aggregation functionality had been "outsourced" to the data aggregation module. Accordingly, the term "OLAP server" as used in the claims and explained in the specification is not "insolubly ambiguous" and therefore is not indefinite. See Invitrogen Corp v. Biocrest Manufacturing, LP, 424 F3d 1374, 1383 (Fed Cir 2005).
Next, Hyperion argues the term "for use with any one of a plurality of different OLAP servers" means that the stand-alone data aggregation server must be "capable of being usedconcurrently with more than one OLAP server." But the intrinsic evidence does not support this construction.
First, the plain language of the term does not suggest that the aggregation server must be capable of being used with more than one OLAP server concurrently. The natural meaning of "for use with any one of a plurality of different OLAP servers" is that the aggregation server could be used with any one of the servers, but not necessarily with more than one server at the same time.
Hyperion also relies on HyperRoll's amendments to the drawings and claims, contending that these amendments illustrate that the stand-alone data aggregation server must be capable of operating concurrently with a plurality of different OLAP servers. Hyperion Br at 22. But Hyperion misreads the prosecution history. The patent examiner stated in a summary of an October 16, 2001, interview, "The applicants agreed to provide numbering of the figures, and to resolve an inconsistency between Figures 6B and 7A and also showing a plurality of OLAP servers and display a plurality of OLAP servers." Doc #197, Ex B at 1. Plaintiffs subsequently filed an amendment on October 23, 2001, adding, inter alia, FIG 6E and noting in the specification:
[FIG 6E shows] "the Aggregation Server can be plugged into (e.g., interfaced to) OLAP Servers (two shown as 605' and 605") of different users and vendors. As shown, the Aggregation Server 603 is operably plugged into (e.g., interfaced to) OLAP Server 605' of one user or vendor, yet it is also capable of being operably plugged into OLAP server 605" of another user or vendor, as indicated by the dotted lines. This dramatic move discontinues the restricting dependency of aggregation from the analytical functions of OLAP * * *.
The patent never says anything about requiring the aggregation server to be capable of connecting to the two OLAP serversconcurrently. If anything, the dotted line in FIG 6E suggests that although one could switch the OLAP server to which the aggregation server connects, the aggregation server in that embodiment does not connect to more than one OLAP server at a time. This interpretation is consistent with the claim language and with HyperRoll's proposed construction.
Accordingly, the court rejects Hyperion's contention that "OLAP server" is indefinite and its proposed construction for the term "for use with any one of a plurality of different OLAP servers." The court adopts HyperRoll's construction for this term: "capable of being used with different OLAP servers." The court declines to construe further the term "OLAP server" given that its meaning is clear in the relevant claims.
C. "aggregation engine * * * storing the resultant aggregated data in a multidimensional data store"
This term "aggregation engine" appears in claims 1, 5 and 7-10 of the '544 patent. Hyperion contends here, as it did for numerous terms in the '604 patent, that "aggregation engine" should be interpreted as a means-plus-function term under 35 USC § 112(6). Hyperion asserts that the specification does not recite sufficient structure to perform the claimed function for an "aggregation engine" and therefore the term is indefinite and the claims in which it appears are invalid. Alternatively, Hyperion contends that the specification has not enabled one of ordinary skill to make and use the invention because "HyperRoll has failed to describe an aggregation engine that would be capable of storing the resultant aggregated data in a multidimensional data store." Hyperion Br at 25.
The court first addresses Hyperion's means-plus-function argument. Hyperion contends that the "aggregation engine does not connote sufficient structure to perform the storing function[;] at best it only connotes sufficient structure to perform theaggregation function." Hyperion Reply Br at 15. But this argument misses the point. The relevant question is whether the claim recites sufficient structure such that one of ordinary skill in the relevant art, having read the claim, could build an aggregation engine. Just because an engine is an "aggregation" engine does not preclude that engine from also performing some other function, such as storing data. And common sense dictates that storing data in a multidimensional database is not a particularly complicated action that would befuddle one of ordinary skill in the art. Accordingly, such a person likely could read the claim and build an aggregation engine that also stores data.
Moreover, Hyperion's enablement argument is without merit. Contrary to Hyperion's contention, the specification describes aggregation engines that store data. See '544 patent at 7:37-40 ("[T]he aggregation engine carries out a high-performance aggregation algorithm and novel storing and searching methods within the MDDB."); id at 10:64-11:6 ("[A] stand-alone Aggregation Server of the present invention, having an integrated aggregation engine and MDDB * * * the stand-alone Aggregation Server performs aggregation functions * * * and multi-dimensional data storage functions * * *"). And as described above, because storing data in a multidimensional database does not appear to be a particularly difficult action for one skilled in the art, the court concludes that the '544 patent has satisfied the enablement requirement for this term.
Accordingly, the court rejects Hyperion's proposed construction and declines to construe this term.
IV
In sum, the court has construed many of the disputed terms in the '604 and '544 patents according to the intrinsic record. The court declined to construe some terms in these patents because their meaning was already sufficiently clear.Additionally, the parties are instructed to appear on October 3, 2006, at 9:00 AM for a further case management conference to discuss what issues, if any, remain to be resolved in these cases.
IT IS SO ORDERED.