Opinion
CASE NO. 6:14-cv-625
05-31-2016
LEAD CASE
ORDER
MEMORANDUM OPINION AND ORDER
This Memorandum Opinion construes the disputed claim terms in United States Patent Nos. 5,682,526 ("the '526 Patent") and 5,715,451 ("the '451 Patent") asserted by Plaintiffs Uniloc USA, Inc. and Uniloc Luxembourg S.A. (collectively "Uniloc"). On February 10, 2016, the parties presented oral arguments on the disputed claim terms at a Markman hearing. For the reasons stated below, the court ADOPTS the following constructions.
BACKGROUND
In general, both patents relate to methods and systems for processing patient medical data. The '526 Patent relates to a system for organizing, recording, and displaying medical patient information. '526 Patent Abstract. The patent describes the prior art techniques as traditionally maintaining information in manual physical "charts." Id. at 1:18-21. Such techniques are stated to be disadvantageous for a number of reasons, including capability to only view at one location, inability to automatically enter data, illegible information, etc. Id. at 1:30-38. The patent describes the prior art electronic alternatives as being "rigid" databases which lacked support for typical medical environments. Id. at 1:40-52. The patent describes these databases as not including tools for entering and viewing information in the familiar medical "flowsheet" context and not allowing modification by the health care providers. Id. The '526 Patent states that a mechanism is disclosed which may customize patient information hierarchy that defines and organizes the information for each patient and presents patient data flowsheets. The patient data may be stored according to a hierarchy that may be entered and viewed in a manner that is optimized for the structure and procedures of the particular health care organization. 2:1-9. Users may add, modify, and rearrange global or local patient information parameters that make up the hierarchy. 2:9-11.
The patents are not formally related, however, the '526 Patent is incorporated by reference into the '451 Patent. '451 Patent at 1:6-11. The '451 Patent relates generally to a method and system for constructing formulae for processing medical data. '451 Patent Abstract. The system of the '451 Patent is said to be particularly useful when employed with automated medical information systems such as that of the '526 Patent. Id. at 2:53-60. The '451 Patent allows users to interact with a formula generation facility in order to construct a formula for a medical parameter. '451 Patent at 1:30-38. The facility presents a user with a visual interface for construction of the formula. Id. at 1:40-46. The formulas may generate values, apply summary functions, apply logical operators and comparators, and generate higher-level patient information or even preliminary medical judgements. Id. at 1:50-59.
APPLICABLE LAW
"It is a 'bedrock principle' of patent law that 'the claims of a patent define the invention to which the patentee is entitled the right to exclude.' " Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (quoting Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1115 (Fed. Cir. 2004)). The Court examines a patent's intrinsic evidence to define the patented invention's scope. Id. at 1313-1314; Bell Atl. Network Servs., Inc. v. Covad Commc'ns Group, Inc., 262 F.3d 1258, 1267 (Fed. Cir. 2001). Intrinsic evidence includes the claims, the rest of the specification and the prosecution history. Phillips, 415 F.3d at 1312-13; Bell Atl. Network Servs., 262 F.3d at 1267. The Court gives claim terms their ordinary and customary meaning as understood by one of ordinary skill in the art at the time of the invention. Phillips, 415 F.3d at 1312-13; Alloc, Inc. v. Int'l Trade Comm'n, 342 F.3d 1361, 1368 (Fed. Cir. 2003).
Claim language guides the Court's construction of claim terms. Phillips, 415 F.3d at 1314. "[T]he context in which a term is used in the asserted claim can be highly instructive." Id. Other claims, asserted and unasserted, can provide additional instruction because "terms are normally used consistently throughout the patent." Id. Differences among claims, such as additional limitations in dependent claims, can provide further guidance. Id.
"[C]laims 'must be read in view of the specification, of which they are a part.' " Id. (quoting Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995)). "[T]he specification 'is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term.' " Id. (quoting Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)); Teleflex, Inc. v. Ficosa N. Am. Corp., 299 F.3d 1313, 1325 (Fed. Cir. 2002). In the specification, a patentee may define his own terms, give a claim term a different meaning that it would otherwise possess, or disclaim or disavow some claim scope. Phillips, 415 F.3d at 1316. Although the Court generally presumes terms possess their ordinary meaning, this presumption can be overcome by statements of clear disclaimer. See SciMed Life Sys., Inc. v. Advanced Cardiovascular Sys., Inc., 242 F.3d 1337, 1343-44 (Fed. Cir. 2001). This presumption does not arise when the patentee acts as his own lexicographer. See Irdeto Access, Inc. v. EchoStar Satellite Corp., 383 F.3d 1295, 1301 (Fed. Cir. 2004).
The specification may also resolve ambiguous claim terms "where the ordinary and accustomed meaning of the words used in the claims lack sufficient clarity to permit the scope of the claim to be ascertained from the words alone." Teleflex, Inc., 299 F.3d at 1325. For example, "[a] claim interpretation that excludes a preferred embodiment from the scope of the claim 'is rarely, if ever, correct.' " Globetrotter Software, Inc. v. Elam Computer Group Inc., 362 F.3d 1367, 1381 (Fed. Cir. 2004) (quoting Vitronics Corp., 90 F.3d at 1583). But, "[a]lthough the specification may aid the court in interpreting the meaning of disputed language in the claims, particular embodiments and examples appearing in the specification will not generally be read into the claims." Constant v. Advanced Micro-Devices, Inc., 848 F.2d 1560, 1571 (Fed. Cir. 1988); see also Phillips, 415 F.3d at 1323.
Although "less significant than the intrinsic record in determining the legally operative meaning of claim language," the Court may rely on extrinsic evidence to "shed useful light on the relevant art." Phillips, 415 F.3d at 1317 (quotation omitted). Technical dictionaries and treatises may help the Court understand the underlying technology and the manner in which one skilled in the art might use claim terms, but such sources may also provide overly broad definitions or may not be indicative of how terms are used in the patent. Id. at 1318. Similarly, expert testimony may aid the Court in determining the particular meaning of a term in the pertinent field, but "conclusory, unsupported assertions by experts as to the definition of a claim term are not useful." Id. Generally, extrinsic evidence is "less reliable than the patent and its prosecution history in determining how to read claim terms." Id.
I. Agreed Terms
'526 Patent Claim Term | Agreed Construction |
---|---|
patient information hierarchy | an organization of information related to apatient that is arranged into categories and oneor more subcategories |
local parameter | a parameter where each instance of theparameter is independent from one another andwhere each instance of the parameter can havedifferent values for a given patient |
result value | data relating to a patient |
result parameter | a parameter that may contain a result value fora particular patient at a particular time |
storing the predetermined result value inconjunction with the parameter | no construction necessary |
'451 Patent Claim Term | Agreed Construction |
---|---|
the method comprising | comprising |
I. Claim Construction of Disputed Terms
1. "parameter" (used at least in asserted claims 2, 4, 5, 10-11, and 13-16 of the '526 Patent)
Uniloc's Proposed Construction | Defendants' Proposed Construction |
---|---|
Adopt prior claim construction, "piece ofpatient information" | "a data field for patient information" |
The two issues central to the parties' dispute over this term are whether a previous construction should be adopted from a prior case and whether a parameter is a "repository" that holds patient information or the patient information itself. As to the first dispute, Uniloc argues that the Court should adopt a separate court's prior construction and construe "parameter" as a "piece of patient information." Docket No. 395 at 2 (relying on a prior finding that the specification defines parameter as a piece of patient information). Defendants respond that the prior construction is not consistent with the parties' agreed constructions in this case. Docket No. 392 at 13. Defendants contend that Uniloc's construction of "parameter" ("piece of patient information") is synonymous and indistinguishable from the construction of "result value." Id. at 14 (noting that the parties agree that "result value" means "data relating to a patient"). As Defendants explain, the parties agree that "result parameter" is "a parameter that may contain a result value for a particular patient at a particular time." Id. Defendants argue that under Uniloc's construction for parameter, the term "result parameter" becomes "a piece of patient information that may contain a result value...," which Defendants claim is illogical. Id. Defendants argue that "[u]nder Defendants' construction of "parameter," a result parameter is "a data field for patient information that may contain a result value...," which is plainly understandable." Id.
As to the second dispute, Defendants argues that "[w]hen read as a whole, the '526 patent describes parameters as something that can be used to store patient information—not as patient information itself." Docket No. 392 at 12 (relying on '526 Patent at 4:28-33, 6:3-8, 7:8-10, Fig. 18, 11:31-52). Uniloc responds that its proposed construction does not exclude the possibility for a "parameter" to hold information, but that a parameter can also be a "placeholder" that does not yet have populated information. Docket No. 415 at 22:16-20.
At the hearing, Uniloc proposed "a category or subcategory of patient information." Docket No. 415 at 15:7-11. Defendants were concerned that this proposal is too similar to the agreed construction of "patient information hierarchy," which the parties agree means "an organization of information related to a patient that is arranged into categories and one or more subcategories." Id. at 17:23-18:7. Defendants also argued that Uniloc's new proposal does not distinguish between a parameter and what is stored in a parameter. Id.
On the whole, the specification consistently describes the parameter as not the actual data but rather the name of the data field within which the actual patient information is placed. See Figs. 3, 4:60-64 (describing Fig. 3), 6:3-8 ("[a]uthorized users may create new parameters in order to store and display new pieces of patient information"); see also 7:8-10 4:28-33, 11:32-33, 11:41-43. However, a parameter does not need to contain information at all time—that is, Uniloc correctly points out that parameters does not necessarily have to hold patient information at all times.
Uniloc also expressed concerns that defining parameter as a single "field" may read out the preferred embodiment of Fig. 4, which lists several "fields" of information for each parameter. '526 at 6:28-29 (describing Fig. 4 The parameter definition table 400 contains the following columns, or fields . . . ."). Defendants submit that multiple "fields" can be a single field, but to clarify the issue, Defendants agreed to modify their proposed construction to "one or more a data fields for patient information." Docket No. 415 at 23:2-3.
Accordingly, the Court construes "parameter" as "one or more data fields for patient information."
2. "represent them at a higher conceptual level" ('526 Patent, claim 4)
Uniloc's Proposed Construction | Defendants' Proposed Construction |
---|---|
group together parameters | no construction necessary |
Defendants contend that Uniloc improperly changes the phrase "represent" to "group" and broadens the phrase by removing the phrase "at a higher conceptual level." Defendants point to Figure 10 as an example of a flowsheet in which an encapsulating parameter ("Demerol," red box) has been expended to show the encapsulated parameters ("dose," "dose units," and "routine," green box):
Image materials not available for display. '526 Patent Figure 10 (annotated and truncated). Defendants contend that this parameter can then be collapsed, as shown in Figure 8:
Image materials not available for display. '526 Patent Figure 8 (truncated). Defendants contend that the "Demerol" parameter appears by itself as shorthand "representing" the encapsulated parameters that describe "dose," "dose units," and "routine". Docket No. 392 at 18.
Uniloc contends that the Defendants are trying to require that the encapsulating parameters "indicate something about each and every one of the encapsulating parameters." Docket No. 395 at 2. Uniloc contends that the disclosed embodiments allow a user to flexibly categorize the parameters of patient information in a hierarchy, such that any parameter may be encapsulated by an encapsulating parameter. Id.
At the hearing, Defendants agreed that their proposal does not require that the encapsulating parameters must indicate something about each and every one of the encapsulated parameters (besides the fact that they are represented by an encapsulating parameter at a higher level). Docket No. 415 at 36:18-37:10. With this understanding, the parties agreed to that no construction is necessary.
Accordingly, the Court find that no construction is necessary for "represent them at a higher conceptual level."
3. "user" ('526 Patent, claim 1, 2, 4-6, 10, 11, 14, 15, 18)
Uniloc's Proposed Construction | Defendants' Proposed Construction |
---|---|
no construction necessary | "end user of the computer system" |
The parties dispute whether software developers who customize the program, as opposed to the health care professionals who use the customized product, are considered a "user." Defendants do not dispute that the accused products are often customized to the needs of the health care organization, and that process can be done by internal or external consultants. See Docket No. 415 at 40:1-15. Defendants claim they are not limiting end-users to healthcare providers at the point of care, but to any end-user "who can add, modify, and rearrange." Id. at 41:21-23. Defendants only want to clarify that the software developers who "actually created that tool, the developers of the software" cannot be users. Id. at 39:11-13. Uniloc contends that the discovery evidence shows that Defendants use their own software during software development, testing, certification, training, and demonstrations. Docket No. 395 at 3. Uniloc further asserts that the Defendants create patient information hierarchies for their respective customers, using the very same software features a customer would use to create the same. Id.
Defendants' proposed construction invites confusion by potentially excluding consultants, software support staff that customize the products at customer demands, and people who perform quality-control testing, training or run demonstrations. Defendants' point is well taken—the people that are building the software are not users unless/until they actually use the software. However, at what point that happens is not is not clear from the parties' arguments and by all accounts is a noninfringement argument (as opposed to an argument over claim scope that should be resolved with claim construction principles). The ordinary meaning of "user" resolves Defendants concerns sufficiently well in the context of determining the claim scope. Whether a particular software developer becomes a user will depend upon the facts of that particular user and should be decided by a jury.
Accordingly, the Court finds that no construction is necessary for "user."
4. "computer system" ( '526 Patent, at least claims 2, 4, 5, 10, 11, 13-16, 18)
Uniloc's Proposed Construction | Defendants' Proposed Construction |
---|---|
"a patient information network programmedwith software tools that enable a user tocustomize a patient information hierarchy" | not properly before the Court; in thealternative, no construction necessary |
The parties generally dispute whether a "computer system" refers to a general-purpose computer system absent any special programming that facilitates the particular method steps, or instead whether a "computer system" is limited to a patient information network as Uniloc proposes. Uniloc asserts that the specification confirms that the computer system must be programmed with special-purpose software. Specifically, Uniloc asserts that the statement that the "general-purpose computer upon which the facility preferably operates" confirms that the "facility" is what makes possible the disclosed operation. Docket No. 384 at 19 (citing '526 at 2:23-25). Uniloc asserts that the embodiments would not operate on general-purpose computers alone, absent the specialized programming of the "facility." Docket No. 395 at 4. Uniloc also relies on the surrounding claim language for its proposed limitations. See, e.g., Docket No. 384 at 19.
Defendants contend that Uniloc's proposed construction adds numerous limitations in an attempt to secure a backdoor reversal of this Court's Order that Claim 1 of the '526 Patent is invalid under 35 U.S.C § 101. Docket No. 392 at 10. For example, Defendants argue that "Uniloc's construction renders the surrounding claim language redundant when incorporated into the claim language itself." Id. at 11. Defendants also cite support in the specification showing that a computer system is a normal general-purpose computer system. See, e.g., '526 Patent at 2:23-26 ("FIG. 1 is a high-level block diagram of the general-purpose computer system upon which the facility preferably resides.").
The Court previously looked at this term in the context of Defendants' prior § 101 motion and determined that "the Court cannot find... any limiting language that could result in a specific programming, a special-purpose computer, or any other application of linking that could result in a construction that adds a non-conventional element to this claim." Docket No. 315 at 9. Nothing in Uniloc's briefs shows why that finding was wrong. The statements Uniloc cites in the specification are not clear statements of disavowal or disclaimer. In contrast, the patent expressly states that the computer system could be a "general-purpose computer system upon which the facility preferably resides." '526 Patent 2:23-26. Additionally, incorporating "patients" and "hierarchy" are unnecessary as those terms already appear in the various claims.
Accordingly, the Court finds that no construction is necessary for "computer system."
5. "flowsheet" ('526 Patent claims 4, 5, 10, 14-16, 18)
Uniloc's Proposed Construction | Defendants' Proposed Construction |
---|---|
"a user-defined template in which patient datastored according to the patient informationhierarchy may be entered and viewed" | "a form in which patient data may be enteredand viewed" |
The parties dispute whether "hierarchy" should be included in the construction and whether "template" (or "views") is more appropriate than "form." Uniloc also wants to clarify that flowsheets are electronic.
At the hearing, Uniloc proposed using "views" rather than "template." Docket No. 415 at 70:4-12. --------
Regarding the hierarchy dispute, a "flowsheet" itself does not necessarily require a hierarchy; rather once a flowsheet is customized by the user, the customized flowsheet is described as "defin[ing] views in which patient data stored according to the hierarchy." '529 Patent 3:23-29. Additionally, the hierarchy and customization concepts are found elsewhere in the claims.
As to the "template"/"views" versus "form" dispute, the specification treats templates different from forms. See, e.g., '526 Patent at 10:27-29 (distinguishing between a patient flowsheet and a flowsheet template). Similarly, the specification states that customized flowsheets define the hierarchy views. '526 Patent at 3:25-29 ("[t]he facility further permits users to customize patient data flowsheets ("flowsheets"), which define views in which patient data stored according to the hierarchy may be entered and viewed."). The specification separately states what a "flowsheet" is known to be: "Health care providers have traditionally maintained such patient information manually, on physical 'charts' comprised of paper forms, also known as 'flowsheets.' " '526 Patent at 1:19-23. Also, both parties acknowledge that the claimed flowsheets are electronic. See Docket No. 415 at 68:12-14. Therefore, Uniloc's remaining concern—that flowsheets in the context of the claims are in an electronic, not physical format—is no longer in dispute.
Accordingly, the Court construes "flowsheet" as "a form in which patient data may be entered and viewed."
6. "flowsheet group" ('569 Patent claims 10, 15-16, and 18)
Uniloc's Proposed Construction | Defendants' Proposed Construction |
---|---|
"a collection of parameter(s) or placeholder(s)in a flowsheet that are related for purposes ofdisplaying result values and for adding resultvalues to those parameter(s) or placeholder(s)" | "a group within a form in which patient datamay be entered and viewed"Alternatively: "a collection of parameters orplaceholders in a flowsheet" |
At the hearing, the parties agreed to the construction of "a collection of parameters or placeholders in a flowsheet." Docket No. 415 at 78:17-19.
Accordingly, the Court construes "flowsheet group" as "a collection of parameters or placeholders in a flowsheet."
7. "displayed in conjunction with" ('526 Patent claims 1-3)
Uniloc's Proposed Construction | Defendants' Proposed Construction |
---|---|
No construction necessary | "displayed at the same time as" |
Defendants contend that "in conjunction with" can have different meanings depending on the claim in question. Docket No. 415 at 1-11. Defendants contend that in the context of claims 1-3, a parameter can have several possible result values. Docket No. 392 at 14. Claims 2 and 3 depend from claim 1. In claim 1, the term appears as the "linked-to parameters are displayed in conjunction with the new parameter." '526 Patent 13:1-2 (emphasis added). According to Defendants, when a user creates a new parameter, the user can designate one of its possible result values as a "linked-from possible result value" and designate "linked-to parameters" to which it is linked. Docket No. 392 at 14-15. Defendants contend that if the new parameter has the linked-from possible result value, the linked-to parameters are "displayed in conjunction with the new parameter." Id. at 15. In this context, Defendants argue that "the linked-to parameters are displayed in conjunction with the new parameter" plainly means the parameters are displayed "at the same time." Id.
Defendants argue that the specification supports such a reading:
Users may use a flowsheet to enter one or more result values. ... If the user enters a linked-from result value, the parameters to which the result value are linked are added to the flowsheet . . . [i]n step 1210, the facility displays the linked-to parameter and its result values beneath the linked-from parameter. After the facility processes each linked-to parameter, these steps conclude.
'526 Patent at 9:42-10:17. Defendants contend that when a user enters a result value for a parameter in a flowsheet, if the result value is a linked-from possible result value, the associated linked-to parameters will be automatically added to the flowsheet. Docket No. 392 at 15. Defendants assert that the specification provides an example with regard to the cough parameter: Entering "productive" (a linked-from result) as the value of the "cough" parameter (the linked-from parameter) on the flowsheet causes "sputum color" and "sputum amount" parameters (linked-to parameters) to be displayed. Id. (citing '526 Patent at 9:42-10:17, 2:42-43, Fig. 8). Defendants also point to the prosecution statement to argue that "injunction with means at the same time." See Docket No. 392 Ex. D, Response to Office Action, at 6 ("This feature of Applicants' invention allows additional parameters to automatically be added to a flowsheet only when relevant to patient condition as indicated by the particular result value entered for a related parameter."). Finally, Defendants point to an extrinsic evidence dictionary to assert that "conjunction" means "simultaneous occurrence in space or time." Docket No. 392 at 16.
Uniloc contends that "in conjunction with" is easily understood by a jury and does not require construction. Docket No. 395 at 5. Uniloc asserts that "in conjunction with" generally refers to a logical interrelation, consistent with the specification. See, e.g., '526 Patent at 4:29-32 ("[t]he patient information hierarchy is used to organize the parameters, in conjunction with which pieces of patient information are stored, in a logical organization from which users may easily select them"), 4:40-41 (stating that the patent will discuss the result table in conjunction with Fig. 7), 12:25-26 (similar), 12:27-28 (similar), 12:32-33 (similar).
The specification does not necessarily require that the "linked-to parameters" must be displayed "at the same time" as the "linked-from parameter." For example, what if the parameter added to the flowsheet and displayed (sputum color) was added and displayed but only immediately displayed and the other parameters (cough) were not. A separate window or box could open up displaying the linked-to parameters even though the "cough parameter" is no longer displayed. Likewise, there is nothing in specification that prevents the linked-to parameter from being displayed on the next page of the flowsheet. Again, the parameter would not be "displayed at the same time" in such a scenario. Furthermore, the passages in the specification and file history which Defendants cite to discuss adding the linked-to parameter (for example sputum color) to the flow sheet but do not have the explicit "at the same time" requirement. Docket No. 392 Ex. D, Response to Office Action at 6. Finally, there is no temporal language in in claim 3 that would require the linked-to parameter to be displayed "at the same time" as the linked-from parameter. '526 Patent at 13:16-26.
Accordingly, the Court finds that no construction is necessary for "displayed in conjunction with."
8. "computer system" ('451 Patent claims 1, 2)
Uniloc's Proposed Construction | Defendants' Proposed Construction |
---|---|
"one or more programmable electronic devicesprogrammed with a formula constructionfacility having a window-based user interface" | Not properly before the Court; in thealternative, no construction necessary |
The parties raise generally the same arguments as they do for the term "computer system" in the '526 Patent. See Docket No. 415 at 59:22-60:8). The Court finds that no construction is necessary for the same reasons as discussed above in the context of the '526 Patent.
Accordingly, the Court finds that no construction is necessary for "computer system."
9. "formula construction subsystem" ('451 Patent claims 7-8)
Uniloc's Proposed Construction | Defendants' Proposed Construction |
---|---|
No construction necessary | Indefinite |
Defendants argue this term, which only appears in claims 7 and 10, is indefinite. Defendants contend that without reference in the specification, the public is left to guess what is meant at the very core of the claim, which does not meet the reasonable certainty standard in Nautilus, Inc. v. Biosig Instruments, Inc., 134 S. Ct. 2120, 2130 (2014). Docket No. 392 at 28.
Defendants further argue that the claim language itself does not provide sufficient structure. Docket No. 392 at 29. Defendants note that Claim 7 states that an "apparatus for constructing a formula" is, in part, comprised of a "formula construction subsystem for constructing a formula for producing a displayable textual patient information string from a selected time-indexed medical data variable." '451 Patent at claim 7. According to Defendants, "the only description of or limitation on a "formula construction subsystem" provided by this claim is that it is "for" constructing a certain type of formula." Docket No. 392 at 29. Defendants state "[s]imilarly, claim 10 recites an "apparatus for constructing a formula" comprising, in part, "a formula construction subsystem for constructing a formula based on one or more of the plurality of time-indexed medical values in response to input from a user...." Id.
Finally, Defendants further argue that Claims 7 and 10 are inconsistent. Docket No. 392 at 29. Specifically, Defendants note that Claim 7 requires the formula for producing the information string from a single time indexed variable, while Claim 10 requires "a formula based on one or more of the plurality of time-indexed values." Id. Defendants assert that these two different descriptions add further ambiguity. Id.
Uniloc contends that the first element of claim 7 introduces the "formula construction subsystem" and recites a detailed description of the term. Uniloc contends that each of the other elements reference "formula construction subsystem," providing additional context to the term. Docket No. 384 at 21. As to the differences in claims 7 and 10, Uniloc contends that the fact that two claims recite distinct limitations does not render the claims indefinite. Docket No 395 at 9. Uniloc asserts that given the emphasis in the patent on the "facility" software, it is absurd to argue that the specification is silent concerning a formula construction facility / subsystem. Id.
Uniloc also makes a minor attempt to argue that Defendants waived their right to raise indefiniteness. Docket No. 384 at 21-22. However, Uniloc does not dispute it was aware that Defendants claimed this term was indefinite for nearly a year; Uniloc also does not dispute that Defendants identified this term as indefinite in its disclosures pursuant to P.R. 4-2. See Docket No. 415 at 80:20-81:18. Given these facts, Defendants have not waived ther right to argue this term is indefinite.
Nevertheless, the Court rejects Defendants' arguments on the merits. The claim language provides context for the "formula construction subsystem" by separately identifying "a formula construction subsystem," "a display device," an "input device," and "memory," which together comprise "the apparatus of constructing . . . a formula." '451 Patent claim 7; see also claim 10. The formula construction subsystem is plainly the software necessary to run the claimed apparatus. Furthermore, in context of the specification, the facility refers to the computer programs or software. The specification states "[t]he computer programs that preferably comprise the facility 109." '451 Patent at 3:2-3. As shown in Figure 1, the facility 109 is contained in the memory 103. The '451 incorporates the '526 specification, which states that the facility is comprised of software tools. See '526 Patent at 3:19-20 ("A patient information management facility of the patient information ("the facility") is comprised of software tools."). Additionally, claims 7 and 10 are not inconsistent. Claim 7 has a formula based on "a selected" variable and claim 10 has a formula based on "one or more" variables. In reading the claim elements in light of the specification, one of ordinary skill would understand the formula construction subsystem is the apparatus' software.
In light of the foregoing, the Court holds that the term "formula construction subsystem," when viewed in light of the claim language and specification, sufficiently informs those skilled in the art about the scope of the invention with reasonable certainty. The parties' dispute does show that construing the term would aid the jury, however. As discussed above, the facility refers to the software the users interact with to construct the formulae. '451 claims 7, 10.
Accordingly, the Court construes "formula construction subsystem" as "formula construction software."
10. "user" ('451 Patent claims 1, 2, 7, and 8)
Uniloc's Proposed Construction | Defendants' Proposed Construction |
---|---|
No construction necessary | Claims 1 & 2: "end user of the computersystem"Claims 7 & 8: "end user of the apparatus" |
For the same reasons discussed in the context of the '526 Patent above, the Court finds no construction necessary.
Accordingly, the Court finds that no construction is necessary for "user."
11. "window-based user interface" ('451 Patent claims 1, 2 and 7)
Uniloc's Proposed Construction | Defendants' Proposed Construction |
---|---|
"a working area of a display with special-purpose devices that enable a user to interactwith a formula construction facility on thecomputer system" | "user interface with an area of the screen withvisible boundaries within which information isdisplayed" |
At the hearing, the Court proposed the following construction: "an area of the display with visible boundaries within which information may be displayed and entered that enables a user to interact with a computer system." Uniloc agreed to the proposed construction with the change than that "computer system" is replaced with "software program" "or however the Court construes "the formula construction subsystem" term. Docket No. 415 at 92:19-93:1. Defendants "do not necessarily [] disagree" with replacing computer system with software. Id. at 95:1-14. To be consistent with the construction of "formula construction subsystem" as "formula construction software" discussed above, the Court will use "software" in the instant term.
Accordingly, the Court construes "windows-based user interface" as "an area of the display with visible boundaries within which information may be displayed and entered that enables a user to interact with software."
SIGNED this 31st day of May, 2016.
/s/_________
ROBERT W. SCHROEDER III
UNITED STATES DISTRICT JUDGE
APPENDIX A
United States Patent Number 5 ,682,526:
Claim Term | Court's Construction |
---|---|
"parameter"(used at least in asserted claims 2, 4, 5, 10-11,and 13-16) | "one or more data fields for patientinformation" |
"represent them at a higher conceptual level"(used at least in asserted claim 4) | no construction necessary |
"user"(used at least in asserted claims 1, 2, 4-6, 10,11, 14, 15, and 18) | no construction necessary |
"computer system"(used at least in asserted claims 2, 4, 5, 10-11,13-16, and 18) | no construction necessary |
"flowsheet"(used at least in asserted claims 4, 5, 10, 14-16and 18) | "a form in which patient data may be enteredand viewed" |
"flowsheet group"(used at least in asserted claims 10, 15-16, and18) | "a collection of parameters or placeholders in aflowsheet" |
"displayed in conjunction with"(used in asserted claim 4) | no construction necessary |
| Agreed Construction |
---|---|
patient information hierarchy | an organization of information related to apatient that is arranged into categories and oneor more subcategories |
local parameter | a parameter where each instance of theparameter is independent from one another andwhere each instance of the parameter can havedifferent values for a given patient |
result value | data relating to a patient |
result parameter | a parameter that may contain a result value fora particular patient at a particular time |
|
storing the predetermined result value inconjunction with the parameter | no construction necessary |
Claim Term | Court's Construction |
---|---|
"computer system"(used in asserted claims 1 and 2) | no construction necessary |
"formula construction subsystem"(used in asserted claims 7-8) | formula construction software |
"user"(used in asserted claims 1, 2, 7, and 8) | no construction necessary |
"window-based user interface"(used in asserted claims 1, 2 and 7) | an area of the display with visible boundarieswithin which information may be displayedand entered that enables a user to interact withsoftware |
| Agreed Construction |
---|---|
the method comprising | comprising |