Summary
holding that [i]mporting a negative limitation into a claim, particularly where the claim language does not contain such a limitation, is generally not favored."
Summary of this case from Nuance Commc'ns, Inc. v. Abbyy Software House, Inc.Opinion
No. 2:04-CV-436(TJW).
March 22, 2006.
Michael Scott Dowler, Brian Langston Jackson, and Stephen L. Lundwall, Howrey LLP, Houston, TX, Robert E. Krebs, Thelen Reid Priest LLP, San Jose, CA, Ronald F. Lopez, Thelen Reid Priest, San Francisco, CA, and Sidney Calvin Capshaw, III, Brown McCarroll, Longview, TX, for Hyperion Solutions Corporation.
David J. Beck, Beck Redden Secrest, Houston, TX, Benjamin M. Stern, Gary A. Walpert, Mark G. Matuschak, Wilmer Cutler Pickering Hale Dorr, Boston, MA, Caren K. Khoo, Matthew T. Byrne, Paul B. Keller, Peter J. Shen, Wilmer Cutler Pickering Hale and Dorr LLP, New York, NY, for OutlookSoft Corporation.
MEMORANDUM OPINION AND ORDER
The court issues this memorandum opinion and order to resolve the parties' claim construction disputes.
I. Introduction
Plaintiff Hyperion Solutions Corporation ("Hyperion") has asserted United States Patent Nos. 4,989,141 ("the `141 patent") and 5,189,608 ("the `608 patent") (collectively, "the Hyperion patents") against Defendant OutlookSoft Corporation ("OutlookSoft"). OutlookSoft, in turn, has asserted United States Patent Nos. 6,341,292 ("the `292 patent") and 6,539,403 ("the `403 patent") (collectively, "the OutlookSoft patents") against Hyperion.
II. General Principles Governing Claim Construction
"A claim in a patent provides the metes and bounds of the right which the patent confers on the patentee to exclude others from making, using or selling the protected invention." Burke, Inc. v. Bruno Indep. Living Aids, Inc., 183 F.3d 1334, 1340 (Fed. Cir. 1999). Claim construction is an issue of law for the court to decide. Markman v. Westview Instruments, Inc., 52 F.3d 967, 970-71 (Fed. Cir. 1995) (en banc), aff'd, 517 U.S. 370 (1996).
To ascertain the meaning of claims, the court looks to three primary sources: the claims, the specification, and the prosecution history. Markman, 52 F.3d at 979. Under patent law, the specification must contain a written description of the invention that enables one of ordinary skill in the art to make and use the invention. A patent's claims must be read in view of the specification, of which they are a part. Id. For claim construction purposes, the description may act as a sort of dictionary, which explains the invention and may define terms used in the claims. Id. "One purpose for examining the specification is to determine if the patentee has limited the scope of the claims." Watts v. XL Sys., Inc., 232 F.3d 877, 882 (Fed. Cir. 2000).
Nonetheless, it is the function of the claims, not the specification, to set forth the limits of the patentee's claims. Otherwise, there would be no need for claims. SRI Int'l v. Matsushita Elec. Corp., 775 F.2d 1107, 1121 (Fed. Cir. 1985) (en banc). The patentee is free to be his own lexicographer, but any special definition given to a word must be clearly set forth in the specification. Intellicall, Inc. v. Phonometrics, 952 F.2d 1384, 1388 (Fed. Cir. 1992). And, although the specification may indicate that certain embodiments are preferred, particular embodiments appearing in the specification will not be read into the claims when the claim language is broader than the embodiments. Electro Med. Sys., S.A. v. Cooper Life Sciences, Inc., 34 F.3d 1048, 1054 (Fed. Cir. 1994).
This court's claim construction decision must be informed by the Federal Circuit's decision in Phillips v. AWH Corporation, 2005 WL 1620331 (Fed. Cir. July 12, 2005) (en banc). In Phillips, the court set forth several guideposts that courts should follow when construing claims. In particular, the court reiterated that "the claims of a patent define the invention to which the patentee is entitled the right to exclude." 2005 WL 1620331 at *4 (emphasis added) ( quoting Innova/Pure Water, Inc. v. Safari Water Filtration Systems, Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). To that end, the words used in a claim are generally given their ordinary and customary meaning. Id. at *5. The ordinary and customary meaning of a claim term "is the meaning that the term would have to a person of ordinary skill in the art in question at the time of the invention, i.e. as of the effective filing date of the patent application." Id. This principle of patent law flows naturally from the recognition that inventors are usually persons who are skilled in the field of the invention. The patent is addressed to and intended to be read by others skilled in the particular art. Id.
The primacy of claim terms notwithstanding, Phillips made clear that "the person of ordinary skill in the art is deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification." Id. Although the claims themselves may provide guidance as to the meaning of particular terms, those terms are part of "a fully integrated written instrument." Id. at **6-7 ( quoting Markman, 52 F.3d at 978). Thus, the Phillips court emphasized the specification as being the primary basis for construing the claims. Id. at **7-8. As the Supreme Court stated long ago, "in case of doubt or ambiguity it is proper in all cases to refer back to the descriptive portions of the specification to aid in solving the doubt or in ascertaining the true intent and meaning of the language employed in the claims." Bates v. Coe, 98 U.S. 31, 38 (1878). In addressing the role of the specification, the Phillips court quoted with approval its earlier observations from Renishaw PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998):
Ultimately, the interpretation to be given a term can only be determined and confirmed with a full understanding of what the inventors actually invented and intended to envelop with the claim. The construction that stays true to the claim language and most naturally aligns with the patent's description of the invention will be, in the end, the correct construction.
Consequently, Phillips emphasized the important role the specification plays in the claim construction process.
The prosecution history also continues to play an important role in claim interpretation. The prosecution history helps to demonstrate how the inventor and the PTO understood the patent. Phillips, 2005 WL 1620331 at *9. Because the file history, however, "represents an ongoing negotiation between the PTO and the applicant," it may lack the clarity of the specification and thus be less useful in claim construction proceedings. Id. Nevertheless, the prosecution history is intrinsic evidence. That evidence is relevant to the determination of how the inventor understood the invention and whether the inventor limited the invention during prosecution by narrowing the scope of the claims.
Phillips rejected any claim construction approach that sacrificed the intrinsic record in favor of extrinsic evidence, such as dictionary definitions or expert testimony. The en banc court condemned the suggestion made by Texas Digital Systems, Inc. v. Telegenix, Inc., 308 F.3d 1193 (Fed. Cir. 2002), that a court should discern the ordinary meaning of the claim terms (through dictionaries or otherwise) before resorting to the specification for certain limited purposes. Id. at **13-14. The approach suggested by Texas Digital — the assignment of a limited role to the specification — was rejected as inconsistent with decisions holding the specification to be the best guide to the meaning of a disputed term. Id. According to Phillips, reliance on dictionary definitions at the expense of the specification had the effect of "focus[ing] the inquiry on the abstract meaning of words rather than on the meaning of the claim terms within the context of the patent." Id. at *14. Phillips emphasized that the patent system is based on the proposition that the claims cover only the invented subject matter. Id. What is described in the claims flows from the statutory requirement imposed on the patentee to describe and particularly claim what he or she has invented. Id. The definitions found in dictionaries, however, often flow from the editors' objective of assembling all of the possible definitions for a word. Id. Phillips does not preclude all uses of dictionaries in claim construction proceedings. Instead, the court assigned dictionaries a role subordinate to the intrinsic record. In doing so, the court emphasized that claim construction issues are not resolved by any magic formula. The court did not impose any particular sequence of steps for a court to follow when it considers disputed claim language. Id. at *16. Rather, Phillips held that a court must attach the appropriate weight to the intrinsic sources offered in support of a proposed claim construction, bearing in mind the general rule that the claims measure the scope of the patent grant. The court now turns to a discussion of the disputed claim terms.
III. Hyperion Patents
A. Description of the Technology
The Hyperion Patents relate to improvements in accounting software that companies use to gather, store, and organize their financial data. The patented software allows companies to receive financial information from a variety of sources in various formats, and easily manipulate that data to perform desired tasks such as generate an SEC report, create budgets, track expenses, consolidate accounts, and otherwise perform whatever accounting functions a company needs for its corporate data. It accomplishes this by storing the variety of data it receives in a common format in a database.
The asserted claims from the Hyperion patents are directed to different methods of operating a financial database, and the elements of those claims generally fall into three main categories or functions: (1) storing data, (2) inputting data; and (3) outputting data. The Court will address the relevant technology of each category/function.
1. Storing Data
Companies must often collect financial information from numerous sources, in circumstances where the data is in many different formats. For example, some companies collect data that is maintained manually (such as a handwritten ledger), electronically (such as an Excel spreadsheet) or in on-line services (such as the Dow Jones News/Retrieval Service). Complicating matters is the fact that many of these companies collect data in various combinations of these forms. The Hyperion patents effectively and efficiently deal with this disparate data by providing a unique way of storing the various inputs.
The Hyperion patent inventors recognized that the stored data could be more easily identified, collected, and output from the database if the data was stored in a common database with associated "attributes." Attributes tell the user something about the stored data so that certain data associated with one group of attributes can be distinguished from data associated with a different group of attributes.
The patent specification describes the use of four attributes to store data in the common database, which it calls Schedule, Entity, Period, and Type (SEPT). The Schedule attribute identifies the source of input data, such as whether the data comes from an income statement or tax schedule. The Entity attribute identifies the reporting group from which the input data comes, such as whether the data is attributable to Company ABC or division X of Company ABC. The Period Attribute identifies the range of time covered by the input data, such as a fiscal year, calendar year, etc. The Type attribute provides additional information about the nature of the input data, such as whether the data is actual, budget, or forecast type data.
The Hyperion patents illustrate how the SEPT attributes might logically appear. See Col. 4, ll. 35-38 of the `141 patent. Data is classified in the database according to the particular attribute values with which it is associated. For example, the data stored in the first row of the database (data in datacell1 through datacellx) has S1E1P1T1 attributes associated with it. Similarly, data stored in the second row of the database (data in datacell1 through datacelly) has S2E2P2T2 attributes associated with it.
2. Inputting Data
The Hyperion patents also describe the manner in which the incoming data from various sources is placed into the database. In particular, the patents describe the use of an "input template" for receiving financial data from virtually any source or format.
According to the Hyperion patents, a user of the patented system creates a template for each format in which the company receives input data. The user defines the input template so that the template knows exactly what form the input data is in, how the input data in arranged in its original format, and how the data should subsequently be stored in the database.
3. Outputting Data
Once data is in the common database and associated with a set of attributes, the patented system describes a robust reporting capability, whereby data can be output from the database into any user-defined format. Data is extracted from the database and output using an "output template."
An output template is essentially the opposite of an input template. The output template tells the system what data to take from the common database and how to organize that data in an output report. Output templates are user-definable, which enables a user to decide exactly what groupings of data should be selected from the common database and how that data should be organized and presented for output.
B. The Asserted Claims Claims 1, 5, and 6 of the `141 patent
1. A method of operating on a computer a financial database in which financial data is organized in accordance with at least the attributes of time period, financial schedule and business entity to which such data pertains comprising the steps of:
defining in said computer the time periods in which said financial data is organized,
for each time period, defining in said computer the financial schedules and business entities in which said financial data is organized,
receiving financial data in the form of financial schedules of different business entities for defined periods of time, each of said schedules having one of a plurality of first formats,
creating for each different first format a template for conversion of financial data from said first format to a common second format,
storing with the aid of said templates financial data from the defined time periods, financial schedules and business entities in said second format in a database in said computer, said database being organized in accordance with said attributes of time period, financial schedule and business entity,
selecting financial data stored in said database for output from said database by generating a display of the different time periods, financial schedules and business entities for which financial data is stored in said database, and indicating to the computer by means of the display the time periods, financial schedules and business entities for which financial data is to be output from the database, and
generating an output from the database of the financial data for the time periods, financial schedules, and business entities selected by means of the display.
5. A method of generating in a computer a spreadsheet of financial information of the type used in financial schedules comprising the steps of:
storing said financial information in a first format in a storage means in which each of a plurality of financial data values is associated with a set of identifying attributes,
defining for each said financial data value a range value which identifies it,
generating a reference file which associated the financial data values stored in said storage means with individual cells of said spreadsheet, said reference file comprising coded headings for said spreadsheet which specify by range value and identifying attribute the financial data values to be located in the individual cells of the spreadsheet, and
using said reference file and the financial data values stored in said storage means to generate the spreadsheet
6. The method of claim 5 wherein the coded headings comprise:
a value that specifies the range value or an identifying attribute
a means for identifying the value as a range value or an identifying attribute, and
an indicator that the heading is a code.
Claims 1 and 4 of the `608 patent
1. In a computer, a method of storing and generating financial information of the type used in financial schedules comprising the steps of:
storing financial information in a first format in a storage means in which format each of a plurality of financial data values is associated with a set of at least three identifying attributes and some data values are associated with a set of attributes different from that associated with other data values;
specifying by user input to said computer a plurality of second formats in which are received data values to be stored in said storage means, each of said second formats associating each of a plurality of financial data value with one of said sets of at least three identifying attributes, whereby a plurality of user-defined data input templates are defined;
using said data input templates to convert data values received in each of the plurality of second formats into said first format and storing such data values in said storage means in said first format;
specifying by user input to said computer a plurality of third formats in which data values stored in said storage means are to be provided for output, each of said third formats associating a plurality of financial data values stored in said first format and associated with a first set of at least three attributes with a plurality of financial data values stored in said first format and associated with second set of at least three attributes, whereby a plurality of user-defined of data output templates are defined; and
using one of said data output templates to convert data values stored in said storage means to said third format.
4. The method of claim 1 wherein said financial information is output by:
specifying a particular type of schedule,
specifying a combination of attributes such as entity, period and type;
specifying a number of rows and columns in which to display output data, and
specifying the locations of the attributes on the display of output data.
C. Analysis of the Disputed Terms
1. attribute
Hyperion contends that an attribute is "an identifier used to classify financial data." OutlookSoft contends that attribute is "an identifier used to organize financial data." Thus, the debate is simply whether an attribute classifies or organizes data.
While Hyperion cites to one example in the prosecution history to support its construction, OutlookSoft proposes the correct construction. In the `141 patent, claim 1 recites "financial data is organized in accordance with at least the attributes. . . ." Thus, the claim language itself supports OutlookSoft's construction. Accordingly, the Court adopts OutlookSoft's construction. "Attribute" means "an identifier used to organize financial data."
2. financial schedule
Hyperion asserts that a financial schedule is simply "a source of financial data." OutlookSoft contends that financial schedule is "a kind of document that data comes from (for example, an income statement, a tax schedule)."
OutlookSoft points to numerous statements made during prosecution wherein Hyperion essentially defined the schedule attribute as "a kind of document." See December 15, 1989, Amendment. In the same response, the inventors also stated that the attribute of schedule is to identify "the kind of document the data comes from (e.g., an income statement, a tax schedule) . . ." and "to refer to a particular type of document from which data is gathered." Id. OutlookSoft contends that these statements narrow the construction of the claim term. See Omega Eng'g Inc. v. Raytek Corp. 334 F.3d 1314, 1325-28 (Fed. Cir. 2003).
Hyperion responds by noting that the specification specifically calls out that the source of the financial data, i.e., the schedule, can be something more than a conventional paper document. That is, the patent specification specifically contemplates electronic data as a financial schedule. `141 patent at 2:16-25; 4:12-14; 5:59-61; 7:12-14; 9:37-49; 12:63-68; and 13:14-16. Thus, Hyperion contends, there is ample support for Hyperion's broader construction. Neither party is completely correct.
OutlookSoft is correct that, in many respects, Hyperion chose to act as its own lexicographer for the term "financial schedule." The statements made during prosecution of the Hyperion patents clearly act to define "financial schedule" as a type of document. However, Hypeiron did not surrender electronic documents in this definition. Accordingly, "financial schedule" is "a kind of document (whether a paper document or electronic file) that data comes from."
3. a plurality
OutlookSoft contends that a plurality is "a group of two or more." Hyperion asserts that plurality is simply "two or more" and cites to Federal Circuit authority supporting its position. See Dayco Prods., Inc. v. Total Containment, Inc., 258 F.3d 1317, 1327-28 (Fed. Cir. 2001). Hyperion's construction for plurality is correct. Accordingly, "plurality" means "two or more."
4. range value
Hyperion contends that a range value is "a name associated with certain data that is used to extract that data from the database." OutlookSoft asserts that the proper construction is "a shortcut to refer to several data cells each having a different SEPT value where the user can extract data from all desired cells at once."
OutlookSoft seeks to incorporate the limitation of SEPT from the preferred embodiment into the term "range values." In fact, OutlookSoft seeks to incorporate the SEPT limitation into many claim terms, arguing that SEPT is the invention rather than the preferred embodiment. While OutlookSoft points to some statements made during prosecution and in the summary of the invention, the Court is not persuaded that the Hyperion patents are limited exclusively to SEPT.
The plain language of the claims supports the Court's view. For example, claim 1 of the `141 patent requires the use of only three attributes: S, E, and P. Claim 5 of the `141 patent does not require any particular number of attributes, nor does it require that the attributes be of any particular type. Claim 1 of the `609 patent (and claim 1 originally filed with the application for the `141 patent) requires that at least three attributes be used, but (like claim 5 of the `141 patent) it does not specify what they must be. Thus, the Hyperion claims make clear that the inventors made use of the attributes in general and did not limite thei invention to SEPT. Any construction limited to SEPT would therefore be incorrect. Accorindlgy, the Court adopts Hyperion's construction of the term "range value."
5. reference file
Hyperion's construction of "reference file" is "computer instructions that tell the computer how to extract data from a database and where to place that data in a spreadsheet." OutlookSoft asserts that the proper construction is "a modified worksheet that begins with one or two predefined characters (for example a pound sign (#) or a double pound sign (##)) used to tell the computer how to extract data from a database and where to place that data in the modified worksheet."
OutlookSoft points to the specification to support its construction:
After a worksheet is selected, it is modified by the addition of codes in the first column and row of the worksheet which tell the computer system what data to extract from the database and where to display it in the modified worksheet. This modified worksheet is referred to as a reference file.
`141 patent, 22:58-63.
Thus, OutlookSoft is correct that the specification requires that the reference file be, at a minimum, some sort of modified worksheet. Where OutlookSoft goes wrong is in the attempt to incorporate additional limitations from the preferred embodiment into its construction. Accordingly, "reference file" means a "modified worksheet that includes computer instructions that tell the computer how to extract data from a database and where to place that data in a spreadsheet."
6. coded heading(s)
Hyperion's construction is "instructions in the reference file indicating what data to extract from the database." OutlookSoft's construction is "an instruction in a reference file consisting of one or two predefined characters (for example, a pound sign (#) or a double pound sign (##)), a code, and a value, identifying a starting point and a direction in which to place data from the database in the reference file." Again, OutlookSoft attempts to incorporate limitations from the preferred embodiment. The Court adopts Hyperion's construction of "coded heading(s)."
7. a means for identifying the value as a range value or an identifying attribute
Both parties agree that this phrase is governed by § 112 ¶ 6. Hyperion contends that the corresponding structure is the phrase "code" identified at column 22, line 67. OutlookSoft contends that this phrase is software and as such requires that the Court determine the algorithm that performs the function. OutlookSoft is correct in that regard. See Harris Corp. v. Ericsson Inc., 417 F.3d 1241, 1253 (Fed. Cir. 2005). The patented invention clearly contemplates that software determines whether the value is a range value or an identifying attribute.
However, OutlookSoft's proposed construction is not the algorithm that performs this function. Instead, OutlookSoft asserts that the structure is "the letter `R' identifying a range value, or the letters `S,' `E,' `P,' and `T' identifying the attributes of Schedule, Entity, Period, and Type." OutlooksSoft's structure is the "what" that is identified rather than the "how" (i.e., the algorithm) that determines what is identified.
Accordingly, the Court must determine the algorithm disclosed in the specification that performs the function of identifying the value as a range value or an identifying attribute. The written description does not provide the exact structure for determining how the invention determines whether a value is a range or an attribute. However, the object code of the present invention is attached. This Court has held that code necessarily reveals the algorithm that performs the function. See Gobeli Research Ltd. v. Apple Computer, Inc., 384 F. Supp. 2d 1016, 1023 (E.D. Tex. 2005). The only code attached to the Hyperion patents was the FASTAR system which only used the SEPT methodology. Accordingly, the structure for performing the function of identifying the value as a range value or an identifying attribute is "that part of the object code that determines whether a value is the letter `R' identifying a range value, or the letters `S,' `E,' `P,' and `T' identifying the attributes of Schedule, Entity, Period, and Type."
Pursuant to 35 U.S.C. § 112 ¶ 6, the Court construes the claim to also cover structural equivalents.
Finally, the Court notes that OutlookSoft seeks to have numerous additional phrases construed. However, the Court has already construed the necessary constituent elements of these phrases and will not construe the phrases separately for OutlookSoft. In any event, any construction of these phrases would necessarily be consistent with the Court's earlier construction and its admonition that the SEPT preferred embodiment not be read into the claims.
IV. OutlookSoft Patents
A. Description of the Technology
OutlookSoft filed a patent application on May 30, 2000. That application issued as the `292 patent, entitled "Spreadsheet-Based Network Information Exchange with Two-Part Cache," on January 22, 2002. OutlookSoft filed a continuation of the `292 patent application on December 19, 2001. This continuation issued on March 25, 2003, as the `403 patent, entitled "Method and System for Facilitating Networked Information Exchange."
The OutlookSoft patents disclose and claim methods and systems for making the exchange of data over a computer network faster and more efficient. Historically, financial accountants and managers used spreadsheets to view and keep track of data. In the late 1970s and 1980s, those users took advantage of computer spreadsheet programs like Lotus 1-2-3 and Microsoft Excel to create and manage their spreadsheets.
At the same time, local-area networks ("LANs"), such as office-wide computer networks, became more common. As the Internet and World Wide Web grew in the early 1990s, office-wide LANs gave way to company-wide networks known as wide-area networks ("WANs"). These various types of networks allowed more than one user to access the same information.
Despite having access to the same data through a WAN, users in different locations still had trouble preparing budgets, forecasts, and other business performance management reports ("BPMs"). The trouble ostensibly stemmed from problems with timely exchange of, and access to, data over the WAN connecting the dispersed company offices. Company-wide budgets, for example, required data from different departments, divisions, and other reporting groups in different locations. Multiple users attempting to access this information invariably led to network congestion.
The technical term for the problem users experienced is "latency." Latency refers to the amount of time it takes for a computer at one locations to receive a response from a computer at another location in a network. For example, latency refers to the delay between a client's request for data and the server's response to the request.
In BPM computer systems of the 1990s, when a user's spreadsheet needed data, the spreadsheet program on the user's computer would send a separate data request — a query — to the server for each data cell of the spreadsheet. Because a typically complex spreadsheet may contain thousands of individual data cells, thousands of queries, sent as individual information packages, would be sent separately to the server. This could, and often would, create bottlenecks in the network, increasing latency and slowing down the entire network.
"Cache" is king for OutlookSoft's accounting software patents. To solve the latency problems, the inventors of the OutlookSoft patents added a special "cache" system to the client computer. In addition, the inventors included the idea of putting more than one query into each information package sent to the server. These innovations reduce the latency problems in several ways.
First, a spreadsheet can obtain data more quickly from the cache than by waiting for a response from the server. In practice, this requires that the cache store data that was input by the client or retrieved from the server, making it locally available. Then, when an application program needs data to create or update a spreadsheet, it firsts checks locally in the cache for the data requested by the application program and provides that data, if available, to the application. This eliminates the need to send a query to the server for data that is already stored in the cache.
Second, the present invention also addresses a more efficient method from retrieving data not stored in the cache. If the necessary data is not in the cache, all unfulfilled data requests are combined in a single query for transmission over the network to the server. Instead of sending multiple queries over the network, the cache combines all queries it needs to send to the server so that they can be sent as a single combined query. Thus, the caching mechanisms and query combination functions as set forth in the OutlookSoft patents reduce latency by retrieving data from a local cache (eliminating requests to the server) and by combining queries into a single request (minimizing network traffic).
B. The Asserted Claims Claims 1 and 3 of the `292 patent
1. A system for facilitating efficient database-related information exchanges across a network, comprising:
(a) a server that includes at least one database; and
(b) a client that includes a spreadsheet program and a cache, and that communicates with said server across a network, said spreadsheet program generating at least one spreadsheet having a plurality of data cells;
wherein said cache stores data for use by said spreadsheet program in rendering said at least one spreadsheet, and
wherein, in response to said spreadsheet program attempting to render said at least one spreadsheet, said cache determines whether data required to render said at least one spreadsheet has been previously stored by said cache; and
wherein, to the extent data required to render said at least one spreadsheet has not been previously stored by said cache, said cache formulates a single query for transmission from said client across said network to said server requesting all required data.
3. A system according to claim 1, wherein said cache receives a response from said server across said network that includes data not previously stored by said cache.Claim 2 of the `403 patent
2. A method for facilitating database-related information exchanges across a network, comprising:
(a) providing an application program at a client computer, said client computer being in communication with said network;
(b) initiating a query associated with said application program at said client computer;
(c) automatically determining whether data responsive to said query is available at said client computer;
(d) to the extent data responsive to said query is not available at said client computer, combining said query with at least one additional query associated with said application program, for simultaneous transmission from said client computer across said network; and
(e) receiving data at said client computer that is responsive to said combined queries, said data being received across said network.
C. Analysis of the Disputed Terms
1. Cache
OutlookSoft asserts that the proposed definition of cache is "a mechanism for data storage and transfer." Hyperion asserts that the proper construction is a "computer memory having a first part that stores data and a second part that stores data requests." Both parties cite to functions the cache performs in claim 1 and both parties cite to statements made by the Examiner during prosecution. However, the parties' citations do not define "cache." Instead, these citations relate to additional claim limitations. To incorporate these limitations into the term cache would render the limitations within claim 1 moot. Bedrock principles of claim construction counsel against a construction that renders additional limitations superfluous. See Merck Co., Inc. v. Teva Pharmaceuticals USA, Inc., 395 F.3d 1364, 1372 (Fed. Cir. 2005).
An example of how the parties incorrectly support their respective positions may prove beneficial. In support its two-part cache argument, Hyperion places great emphasis on the Notice of Allowability of the `292 File History. The reason for allowance in the file history was:
Applicant's invention in claim 1 claims features of the two part cache function described in the preferred embodiment in pages 18-20. Claim 1 claims a spreadsheet with a cache `wherein said cache stores data for use by said spreadsheet program in rendering said at least one spreadsheet.' This claim limitation is the first part — the data cache — of Applicant's inventive two part cache. The second part of Applicant's inventive spreadsheet cache — the `key' cache — is claimed in the language `said cache formulates a single query for transmission from said client across said network to said server requesting all required data.'
In other words, the data cache and key cache functionality that Hyperion seeks to have incorporated into the term "cache" is actually specifically claimed in claim 1. To include the functionality of the data cache and key cache in the construction of the term cache would therefore render a large part of claim 1 superfluous. OutlookSoft's proposed construction suffers from the same deficiencies. Thus, the Court adopts neither party's proposed construction.
The Court will instead develop its own construction using the common and well understood meaning of the term cache while at the same time allowing for the multi-functionality that the elements in claim 1 require. Generally, a cache is nothing more than temporary memory storage. However, in this case, the cache also performs other functions. Thus, there must be an associated set of computer instructions that allow for the functionality described in the claims of the OutlookSoft patents. Accordingly, within the context of this patent, "cache" is "temporary memory storage operating in conjunction with computing instructions to perform various functions."
2. to the extent data required to render said at least one spreadsheet has not been previously stored by said cache, said cache formulates a single query for transmission from said client across said network to said server
The parties actually proposed constructions relating to a slightly longer phrase that included "required data." However, the Court finds that breaking the phrase into discrete sections will provide clearer constructions. The principal dispute between the parties is whether the addition of a negative limitation proposed by Hyperion is appropriate. Importing a negative limitation into a claim, particularly where the claim language does not contain such a limitation, is generally not favored. See Omega Eng'g, Inc. v. Raytek Corp., 334 F.3d 1314, 1329, 1332-33, 1335 (Fed. Cir. 2003).
The Court instead applies a plain language construction. Accordingly, "to the extent data required to render said at least one spreadsheet has not been previously stored by said cache, said cache formulates a single query for transmission from said client across said network to said server" means "when data needed to generate the spreadsheet is not stored in the cache, combining requests for data into one package before sending it to the server."
3. Required Data
Hyperion does not offer a proposed construction as it contends that such a construction is unnecessary if the Court adopts its construction for the phrase recited in Section 2. OutlookSoft's proposed construction for "required data" is "all data needed to create a spreadsheet." However, OutlookSoft's proposed construction is too broad. The correct construction for "required data" is "all data necessary to create a spreadsheet that is not contained in the cache."
4. cache receives a response from said server across said network that includes data not previously stored by said cache
OutlookSoft contends that the proper construction is "the cache receives data from the server, including data items not previously stored in the cache." Hyperion contends that the phrase means the "cache receives data items not previously stored in the cache from the server." The Court construes this phrase in accordance with its plain meaning. Accordingly, "cache receives a response from said server across said network that includes data not previously stored by said cache" means "the cache receives data items from the server that includes data items not previously stored in the cache."
5. to the extent data responsive to said query is not available at said client computer, combining said query with at least one additional query associated with said application program, for simultaneous transmission from said client computer across said network
The parties' proposed constructions are similar, but not identical, to those proposed above. Hyperion seeks to add a negative limitation while OutlookSoft does not. Further, OutlookSoft attempts to limit the construction to spreadsheet programs, and the parties disagree on the construction of "simultaneous." For the vast majority of the phrase, the Court again applies a plain meaning construction. For the "simultaneous transmission" term, the Court construes the phrase to mean "sending to the server in a single request or package."
Accordingly, the phrase "to the extent data responsive to said query is not available at said client computer, combining said query with at least one additional query associated with said application program, for simultaneous transmission from said client computer across said network" is construed to mean "when data needed to respond to the data request of the application program is not stored in the client computer, combining that data request with at least one other data request of the application program, for sending to the server in a single request or package."