Opinion
No. 1:13-cv-01035-SEB-TAB
07-16-2014
CARCHECKUP LLC, Plaintiff, v. CARMD.COM CORPORATION, INNOVA ELECTRONICS CORPORATION, Defendants.
ORDER ON CLAIM CONSTRUCTION
Before the Court are questions of claim construction arising from the pending patent litigation. After the parties filed a "Joint Claim Construction Statement" [Docket No. 31] on March 5, 2014, they submitted briefs addressing the disputed issues. Pursuant to the United States Supreme Court's holding in Markman v. Westview Instruments, Inc., 517 U.S. 370 (1996), we held a claim construction hearing on July 8, 2014. Having considered the written and oral arguments of the parties, we construe the disputed claim terms in the manner detailed below.
Factual Background
The parties have not yet conducted discovery or submitted motions addressing the merits of the suit; we accordingly present only a brief summary of the facts to elucidate our other rulings. Plaintiff CarCheckup, LLC designs and manufactures electronic devices to aid automobile owners and drivers. Compl. ¶ 1. The device at issue is a small, handheld unit that plugs into an electronic port in a car and relays diagnostic data via the internet to a computer server database, which then produces a report for the car owner. Docket No. 33 at 1-4. Plaintiff alleges that Defendants CarMD.com ("CarMD") and Innova Electronics Corporation ("Innova") have infringed on two patents Plaintiff holds in the device: Patent No. 6,807,469 ("the '469 Patent") and Patent No. 6,925,368 ("the '368 Patent"). The '368 Patent is a continuation of the '469 Patent, both of which are entitled "Auto Diagnostic Method and Device." Docket No. 33 at 1 (citing '368 Patent at 1:4-8). Plaintiff is the sole owner of both the '469 Patent and the '368 Patent. Compl. ¶¶ 16, 18.
The two patents are attached to Plaintiff's opening claim construction brief [Docket No. 33] as Exhibit 1 ('469) and Exhibit 2 ('368).
The two defendant corporations share a CEO and a principal place of business, and they have the same legal representation. CarMD is a California corporation. Compl. ¶ 2. Plaintiff alleges that CarMD sells two products infringing its patents: the "CarMD Handheld Device and Software Solution Kit," which it began selling in 2006, and the "Vehicle Health System" (a larger package including the handheld device and other accessories), which it started selling in 2010. Id. at ¶¶ 20-39. Innova is a Nevada corporation doing business in California; it sells the 3030e CanOBD2 Car Reader and 3030f CanOBD2 Diagnostic Tool, both of which are "code readers" designed to enable electronic diagnosis of problems with a user's car. Id. at ¶¶ 40-52. Plaintiff asserts, and Innova denies, that Innova also sells CarMD's allegedly infringing products in addition to its own. Id. at ¶ 55.
Both the '469 Patent and the '368 Patent consist of 24 claims. Plaintiff alleges that CarMD and Innova have infringed claims 1, 7, 17, 18, 19, and 21 of both patents by selling the CarMD products, and that Innova has infringed claims 1, 17, 18, 19, and 21 of both patents by selling the Innova products. See Compl. ¶¶ 54-56, 63-65. Plaintiff seeks a judgment of infringement, injunctive relief, and damages pursuant to 35 U.S.C. § 284.
The Disputed Claims
Although both patents consist of a total of 24 claims, the language in dispute here is principally contained within two independent claims: Claim 1 and Claim 17. Both claims are reproduced below, with the disputed terms emphasized.
Claim 1:
A vehicle monitoring and maintenance device capable of being connected to a diagnostic port of a vehicle, the monitoring and maintenance device comprising a hand holdable data acquisition and transfer device including
(a) a first data link connectable to a data port of a vehicle for retrieving data from a vehicle;wherein the global computer network communicable device is capable of communicating, over a global computer network, with a server containing a processor and a database for processing the unprocessed diagnostic data into natural language diagnostic information, and wherein the hand holdable data acquisition and transfer device lacks sufficient data processing capability to fully process the unprocessed diagnostic data into human-usable diagnostic information.
(b) a second data link connectable to a global computer network communicable device; and
(c) a processor and memory unit capable of retrieving unprocessed diagnostic data containing error codes from the vehicle via the first data link, storing the unprocessed diagnostic data for a time period, and transferring the unprocessed data to the global computer network communicable device, through the second data link
Claim 17:
A method of monitoring and maintaining a vehicle having a diagnostic port comprising
(1) retrieving unprocessed data from a diagnostic data port of a vehicle by employing a hand holdable data acquisition and transfer device for use by vehicle owners, the data acquisition and transfer device comprising:
(a) a first data link connectable to a diagnostic port of a vehicle for retrieving unprocessed data from a vehicle,
(b) a second data link connectable to a global computer network communicable device; and(2) transferring the data from the data acquisition and transfer unit to a global computer network communicable device,
(c) a data capture and memory unit capable of retrieving unprocessed data from the vehicle via the first data link, storing the unprocessed diagnostic data for a limited time period, and transferring the unprocessed data to the global computer network, through the second data link, wherein the hand holdable data acquisition and transfer device lacks sufficient data processing capability to fully process the unprocessed data into human-useable diagnostic information;
(3) transferring the data, via a global computer network, from the global computer network communicable device to a server,
(4) providing a remote server including software having diagnostic information necessary to identify, from the unprocessed data, sources of conditions within the vehicle giving rise to error codes in the unprocessed data,
(5) using the remote server to process the unprocessed data and to prepare a vehicle condition report in a natural language; and
(6) transferring the vehicle condition report, via a global computer network, to a global computer network communicable device, for displaying the vehicle condition report in a natural language thereon.
Legal Analysis
Standard for Claim Construction
Before addressing the merits of a patent infringement suit, the district court is required to decide any outstanding issues of claim construction as a matter of law. See Markman v. Westview Instruments, Inc., 517 U.S. 370, 384-386 (1996); Vederi, LLC v. Google, Inc., 744 F.3d 1376, 1382 (Fed. Cir. 2014). As the scope of a claim Ais necessarily determined by the language of the claim, claim construction must begin with these words.@ Dow Agrosciences LLC v. Crompton Corp., 381 F. Supp. 2d 826, 831 (S.D. Ind. 2005). Absent an express intent otherwise, claim terms are to be given Athe ordinary and customary 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.@ Phillips v. AWH Corp., 415 F.3d 1303, 1313 (Fed. Cir. 2005).
The most important tools at the court's disposal in determining the ordinary and customary meaning of disputed terms constitute the intrinsic evidence—the claims themselves, the specification, and the prosecution history. Dow Agrosciences, 381 F. Supp. 2d at 831. Extrinsic evidence, such as dictionaries and treatises, may also be used to construe the claim=s meaning, but such evidence is afforded less legal significance than that from intrinsic sources. See C.R. Bard, Inc. v. U.S. Surgical Corp., 388 F.3d 858, 862 (Fed. Cir. 2004). In short, as the Federal Circuit emphasized in Phillips:
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.415 F.3d at 1316 (quoting Marposs Societa= per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998)).
Discussion
In their "Joint Claim Construction Statement," the parties identified six sets of claim terms the meaning of which remain in dispute. We will address each in turn, but we note at the outset that two central definitional issues cut across these six disputed terms. At the claim construction hearing, Defendants wisely conceded many of the more minor definitional points in order to focus their arguments on these core questions, which are as follows:
At the hearing, Defendants outlined three core questions. However, we find that their third question—"What is a data capture and memory unit?"—is less material to the heart of the parties' disagreement.
(1) What does it mean to "process" data? Relatedly, what is the difference between "unprocessed" and "processed" data?We are aware as we construe the six disputed terms that these key questions underlie and inform the parties' arguments and, we surmise, shape their longer term strategic goals in this litigation. I. "Unprocessed diagnostic data" and "unprocessed data" ('469 patent, claims 1, 7, 17; '368 patent, claims 1, 7 and 17)
(2) What is the difference, if any, between "natural language diagnostic information" and "human-useable diagnostic information"?
| Plaintiff's Proposed Construction | Defendants' Proposed Construction |
| Data about problems or malfunctions in a vehicle that requires processing to be understood by a typical consumer, such as diagnostic trouble codes (DTCs) or error codes | Data in the form and format retrieved from the vehicle. |
Both parties agree that "unprocessed diagnostic data" and "unprocessed data" are used interchangeably in the patents and should be construed identically. Docket No. 33 at 8; Docket No. 34 at 6; see also Edwards Lifesciences LLC v. Cook, Inc., 582 F.3d 1322, 1330 (Fed. Cir. 2009) (noting that different terms may be construed alike if the claims and specification use them "interchangeably").
They also agree to the interchangeability of "diagnostic data" and "data" as they appear in other disputed terms. For the purposes of brevity, we will sometimes refer to only one of the two formulations, but our constructions apply to both.
A. Subject matter of the retrieved data -
Plaintiff contends that the term "diagnostic data"/"data" should be construed to refer only to "data about problems or malfunctions in a vehicle"—more specifically, to error codes. In support of this theory, it points to a number of statements in the specification that it maintains give context to the term's use in the claims. In the introductory sentence outlining the technical field of the "present invention" as a whole, the patentee described the invention as "a device and method for retrieving error codes from a vehicle data port." '469 Patent at 1:10-14 (emphasis added). See Verizon Servs. Corp. v. Vonage Holdings Corp., 503 F.3d 1295, 1308 (Fed. Cir. 2007) ("When a patent . . . describes the features of the 'present invention' as a whole, this description limits the scope of the invention.") (quoting Honeywell Int'l, Inc. v. ITT Indus., 452 F.3d 1312, 1318-1319 (Fed. Cir. 2006)). Elsewhere in the specification, error codes are the only types of "data" ever mentioned specifically. See, e.g., id. at 6:26-33; see also 12:25-35 (noting that the device performs no further functions if it does not detect DTCs).
Defendants do not object to Plaintiff's treatment of Diagnostic Trouble Codes (DTCs) and "error codes" as interchangeable terms. See '469 Patent at 12:25-35 (describing "diagnostic trouble codes (DTCs), which are also known as error codes").
Defendants counter that "diagnostic data" denotes any data retrieved from the vehicle's diagnostic port—in other words, the data itself need not be "diagnostic" in nature. Docket No. 34 at 10. In support, they point to Claim 10, which speaks only of the retrieval of "data" from the vehicle, and Claim 14, which states that "data retrieved from the onboard computer includes diagnostic data." Docket No. 34 (citing '368 Patent at 17:56-58 , 18:27-28). Defendants did not pursue this line of argument at the Markman hearing, and we think with good reason. We conclude that a reader skilled in the relevant art, taking into account both the use of the term "diagnostic data" in the claims (on an interchangeable basis, the parties have conceded, with plain "data") and the frequent descriptions of diagnostic data such as error codes in the specification, would understand the term not to refer to all conceivable types of data retrievable from an automobile, but rather information relevant to the diagnosis of problems or malfunctions with that vehicle.
Defendants also point to the prosecution history, which here provides somewhat tentative support for their view. A provisional application described "data" (not "diagnostic data") as including "other vehicle operational information." See Defs.' Ex. 20.
B. The meaning of "unprocessed"
Plaintiff defines "unprocessed" data as that which "requires processing to be understood by a typical consumer." See Docket No. 33 at 10. Defendants define it as "raw data that has not been converted into any other form, or format, or otherwise organized, stored, sorted, validated, aggregated or analyzed"; they have simplified this further as comprising data "in the form and format retrieved from the vehicle." Docket No. 34 at 10. Because Defendants' proposed definition of "unprocessed" better accords with the plain meaning of the term, we adopt it.
Our task in claim construction is generally to give a term its "ordinary and customary meaning"—the meaning that the term would have to a "person of ordinary skill in the art in question at the time of the invention." Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (citing Innova/Pure Water, Inc. v. Safari Water Filtration Sys., Inc., 381 F.3d 1111, 1116 (Fed. Cir. 2004)). The person of ordinary skill in the art, in turn, 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.; Multiform Desiccants, Inc. v. Medzam, Ltd., 133 F.3d 1473, 1477 (Fed. Cir. 1998).
Here, neither the claims themselves nor the specification give clear guidance as to the meaning of the term "unprocessed" as used by the patentee. This is hardly surprising; as a negative term, "unprocessed" can only be understood in conjunction with what it means to "process." Read as a whole, the claims and specification use the term to describe data which has been removed from the automobile, but which has been the subject of no further action—that action being "processing," the meaning of which we will need to define shortly. For instance, Claim 1 describes the method in which the device retrieves, stores, and transfers the unprocessed data; although the handheld unit itself "lacks sufficient data processing capability to fully process the unprocessed diagnostic data into human-useable diagnostic information," the server to which it transfers the unprocessed data via the internet will subsequently process the unprocessed data "into natural language diagnostic information." '469 Patent, 16:48-17:7.
Plaintiff seeks to graft an additional meaning onto this wholly negative definition: it construes data in its "unprocessed" form as being necessarily incomprehensible to the typical consumer. To be sure, the specification mentions in several places that the "non-mechanical layperson," '469 Patent, 3:3-5, the car "user," id. at 14:27-61, or the "consumer" who would otherwise be "left to the mercy of the automobile technician," id. at 2:55-56, are the targets of the patented invention. Another portion of the specification, which Plaintiff relied upon both in its brief and at the hearing, explains that the end goal of the device is to convert unprocessed data into something the typical consumer will find useful. In order to understand the thrust of this passage, a specification excerpt of greater length is helpful.
When the error codes have been successfully transferred from the device to the server, the software contained within the server matches the captured codes to code interpretations contained on the database contained on the server. The OBD II database, which interprets such codes, is in the public domain, and contains a list of several code records. Each record contains a DTC code and a brief description.'469 Patent, 14:6-18 (internal cross-references omitted; emphasis added). As we shall discuss further below, this passage shows that the result of the device's processing is "preferably" comprehensible to the consumer and implies that the original unprocessed data is not "written in a natural language"; it does not, however say anything about the format or comprehensibility of the unprocessed data itself.
Additionally, the software includes an extended description/definition that is written in a natural language, and preferably, is written on a level which enable [sic] the typical consumer to understand the problems that exist in his vehicle.
C. Adopted construction
We therefore adopt the following construction of the first set of disputed terms—one which draws from the more persuasive aspects of both parties' proposals: we construe "unprocessed diagnostic data" as meaning "data about problems or malfunctions in a vehicle, such as diagnostic trouble codes (DTCs) or error codes, remaining in the original form and format in which they were retrieved from the vehicle." II. "Processing the unprocessed diagnostic data into natural language diagnostic information"/ "processing the unprocessed data into natural language information" ('469 patent, claim 1; '368 patent, claim 1)
We have opted not to further define the word "data" itself because neither party has disputed the term's plain-sense meaning.
| Plaintiff's Proposed Construction | Defendants' Proposed Construction |
| Interpreting the unprocessed data/diagnostic data into descriptions in a natural language format which may be understood by a typical consumer | Manipulating the unprocessed data/diagnostic data (as defined above) from its original form and format into a report format that allows the vehicle owner or service technician to learn about the malfunction conditions affecting his or her car. |
In order to construe this language, we must determine the meaning of the terms "processing" and "natural language diagnostic information."
The parties do not dispute that "natural language information" and "natural language diagnostic information" are interchangeable terms.
A. "Processing"
Noting that the specification, in various places, uses the words "convert," "correlate," or "interpret" to describe the device's processing function, Plaintiff argues that "[t]he data processing component portion of the claim essentially refers to the interpretation (or conversion or correlation) of the error codes into natural language information via use of a database." Docket No. 33 at 11. We are not convinced by Plaintiff's choice of words or by its contention that "processing" can only refer to the rendering of data into "a natural language format which may be understood by a typical consumer." The patent, read as a whole, does not support such a limited reading—nor does it define the term "process" in isolation.
It is axiomatic in claim construction that claim language should generally be read to avoid redundancy. Bicon, Inc. v. Straumann Co., 441 F.3d 945, 951 (Fed. Cir. 2006); see also Orlando Food Corp. v. United States, 423 F.3d 1318, 1324 (Fed. Cir. 2005) (in a statutory construction case, noting the rebuttable presumption that terms "should be construed to avoid redundant language"). Claim 1 of the patent describes an external server "containing a processor and database for processing the unprocessed diagnostic data into natural language diagnostic information." '469 Patent at 17:1-4. If, as Plaintiff appears to argue, "processing" refers only to the rendering of data into natural language diagnostic information, then a significant portion of the claim is superfluously worded. Plaintiff's argument is further weakened by the patentee's use of "processing" with a different predicate elsewhere in the claims themselves; both Claim 1 and Claim 17 explain that the device lacks the ability to "fully process the unprocessed diagnostic data into human-usable diagnostic information." Id. at 17: 5-7; 19:4-7.
Plaintiff insists that "natural language" and "human useable" have the same meaning. We reject such a construction below. See supra, § III.
What, then, does the term "processing" mean by itself? The specification is not particularly helpful in this regard. Plaintiff proposes three candidate synonyms, each of which appears in the specification in conjunction with the device's processing function:
1. Correlating - "The processing unit of the device includes software for processing the information retrieved from the error code, which . . . correlates the error codes to specificWe believe that Plaintiff has misinterpreted the specification here. In light of the multiplicity of verbs appearing in the text in conjunction with "processing," it seems more likely that the patentee was describing different examples or aspects of processing than that it was setting forth its own "lexicography" of the term. Cf. CCS Fitness, Inc. v. Brunswick Corp., 288 F.3d 1359, 1366 (Fed. Cir. 2002). The intrinsic evidence with regard to the meaning of "processing" is thus not determinative, making recourse to a technical dictionary appropriate to help better understand "the way in which one of skill in the art might use the claim terms." See Starhome GmbH v. AT&T Mobility LLC, 743 F.3d 849, 856 (Fed. Cir. 2014) (quoting Phillips, 415 F.3d at 1318). Defendants have directed our attention to the Microsoft Computer Dictionary, which defines "to process" as "to manipulate data with a program." Defs.' Ex. 21 (Microsoft Computer Dictionary at 359 (4th ed. 1999)). We agree with Defendants that the term "manipulate" is broad enough to encompass the open-ended usages of the verb in the claims and specification, and thus we adopt Defendant' proposed construction in this respect.
vehicle malfunction conditions." '469 Patent at 2:4-7; see also 2:13, 4:33, 6:27-28, 15:50, 15:57.
2. Converting -- "Converting the error codes retrieved from a vehicle into a human readable and understandable action report . . . requires that the scanning device include a database." Id. at 4:49-53.
3. Interpreting - "[E]rror codes can be interpreted into information relating to the source of the problem." Id. at 6:29-30.
This reading of the specification is particularly well illustrated by a passage that uses both "correlate" and "interpret" in close proximity—but, in context, uses neither term as a substitute for processing. Plaintiff cites separate portions of the specification paragraph in its brief, but it reads in full as follows:
The primary attributes of the server are its processing speed to process data transferred to the server from the DAT device, which data comprises largely unprocessed data that is retrieved from the vehicle. Additionally, the server includes a database of information so that the error codes retrieved from the car can be correlated with error and malfunction data, so that error codes can be interpreted into information relating to the source of the problem, or alternatively, to solution information for fixing the problem that relates to the particular error code received.'469 Patent at 6:23-33. We see the use of "additionally" here as revealing. We read this passage as supporting the notion that both "correlating" and "interpreting" are potential aspects or results of the processing of data, but that neither define the term itself.
B. "Natural language diagnostic information"
The parties do not substantively disagree about the meaning of the term "natural language diagnostic information." Plaintiff construes the term as "a natural language format which may be understood by a typical consumer." See Docket No. 33 at 13 (citing '469 Patent at 4:15-22, 4:37-44, 4:48-56, 14:14-41). This is something of a tautology, if an understandable one—"natural language" in this context has an apparent, commonsense meaning. Plaintiff illustrates the point by citing to a portion of the specification that provides an example of the patented device's output.
DTC Number: P0171 [from public domain data]Id. at 14:33-41. The last two segments of this "report" are rendered in natural language—that is, non-technical, non-alphanumeric English; this contrasts pointedly with the first two segments, which consist of an error code and accompanying technical jargon. In their brief, Defendants acknowledge this core distinction: "an alphanumeric code is not 'natural language' while a phrase containing words describing a problem is." Docket No. 34 at 13. Their proposed construction, describing natural language only as a "report format," is too vague, but at the hearing they did not dispute the accuracy of Plaintiff's definition of the term.
DTC Name: System 2 Lean (Bank One) [from public domain data]
Description: Error/Air level too high [text added by applicant's software]
Suggestions: It is possible that one or more fuel injectors are clogged. As an initial remedy, try a bottle of fuel injector cleaner. [Text to be added by applicant's software].
Another dispute that occupies considerable space in the parties' briefs but seemed to exercise them little at the Markman hearing is Defendants' reference to a "service technician" as a possible target audience of the "natural language" report. Plaintiff's brief vehemently objects to importing service technicians into any construction, contending that the specification and prosecution history make clear the product is directed at consumers who lack the specialist knowledge possessed by a service technician. See Docket No. 33 at 11 (citing '469 Patent at 2:20-3:21, 5:22-46, 3:16-21). As Defendants note, however, the specification also discusses the possibility that a car owner could make use of a natural language report in conjunction with a service technician. We conclude that the dispute is pointless. As Plaintiff conceded at the hearing, "natural language" information that can be understood by a consumer can, a fortiori, be understood by a car professional. Since we have adopted the more rigorous definition of "natural language" that Plaintiff sought, any anxiety on Plaintiff's part that Defendants' mention of service technicians is a Trojan horse for weakening the definition to encompass technical jargon is unwarranted.
Plaintiff's brief also raises objections to what it views as the unduly limited scope of Defendants' proposed construction of the term "diagnostic information" mentioned in the claims. It states:
While malfunction conditions are described and certainly included within the definition of this information, the information contained in the report is not so limited. For example, the specification states that the report can contain "the cause of the error [or] a proposed solution to the malfunction." The specification also describes including in the report labor data, parts data, labor costs (or time interval) data, and parts costs data that can be correlated with the identified vehicle malfunctions to provide the consumer with a cost estimate. The information in the report may also contain repair suggestions or solutions. Thus, Defendants' proposed construction improperly limits the "natural language diagnostic information" included in the report.Docket No. 33 at 12. Defendants' brief concedes the point. Docket No. 34 at 16. Thus, we will not include what Plaintiff believes to be Defendants' overly restrictive language in our construction of the claim terms.
C. Adopted Construction
We therefore construe the claim term "processing the unprocessed diagnostic data into natural language diagnostic information" to have the following meaning: "manipulating the unprocessed diagnostic data (as previously defined) into a non-technical, non-alphanumeric verbal report in a format that may be understood by both a typical consumer and a service technician." III. "Lacks sufficient data processing capability to fully process the unprocessed diagnostic data into human-useable diagnostic information" / "lacks sufficient data processing capability to fully process the unprocessed data into human-useable information" ('469 patent, claims 1, 17; '368 patent, claims 1, 17)
Defendants' proposed construction includes the phrase "from its original form and format." However, since this language is included in the definition of "unprocessed diagnostic data" as described in Section I, its use here would be redundant.
| Plaintiff's Proposed Construction | Defendants' Proposed Construction |
| Lacks sufficient processing, memory, and database capabilities to interpret the unprocessed data/diagnostic data into descriptions in a natural language format that may be understood by a typical consumer | Lacks sufficient data processing capability, including memory capability, to manipulate the unprocessed data/diagnostic data (as defined above) from its original form and format into a visual display of diagnostic data, or diagnostic information derived therefrom. |
The parties' dispute centers on the meaning of "human-useable diagnostic information." Plaintiff treats "human-useable" as identical to "natural language"; indeed, it defines the two terms in precisely the same tautological manner. Docket No. 33 at 17. Defendants insist that the terms have distinguishable meanings, and they define "human-useable" as any "visual display of diagnostic data, or diagnostic information derived therefrom." Docket No. 34 at 17. The parties also dispute Plaintiff's construction of the term "data processing capability" as encompassing "processing, memory, and database capabilities."
A. "Human-useable" vs. "natural language"
"[W]hen construing terms in the body of a claim, the general assumption is that different terms have different meanings." Symantec Corp. v. Computer Assocs. Int'l, 522 F.3d 1279, 1289 (Fed. Cir. 2008). Unless Plaintiff can point to evidence in the record indicating otherwise, the presumption against interpreting the two terms as synonyms will stand. See Am. Piledriving Equip., Inc. v. Geoquip, Inc., 637 F.3d 1324, 1335-1336 (Fed. Cir. 2011). Here, the claims and specification confirm that the terms should be construed as distinct. As Defendants point out, the context of the terms' usage in the claims points in this direction: the claims employ "human-useable" in the negative, by way of explaining what capabilities the device lacks; in contrast, the patent uses "natural language" to describe the invention's end-product user report. See '469 Patent at 18:4-15 (Claim 10), 19:3-26 (Claim 17), 20:34-42 (Claim 23). Moreover, the specification strongly suggests that information regarding error codes can be "useable" even in the absence of a more extended "natural language" description. See id. at 6:66-7:2; 14:6-26.
In reply, Plaintiff pointed out at the hearing the specification's statement that, once the data is transferred to the server, "there error codes are processed . . . to provide a human readable report in a natural language"—implying, Plaintiff says, that the two terms have linked meanings. Id. at 14:27-31, 16: 27-31. This is less than persuasive. Plaintiff's quoted passage does not compel, or even bolster, the conclusion that all "human readable" reports are necessarily in a natural language format. In fact, the argument Plaintiff presented at the hearing suffers a distinct circularity—it seeks to prove that the two terms' close proximity in the claims signals their equivalence by pointing to occasions in the specification in which they are likewise arrayed in close proximity to one another. In neither the claims nor the specifications, however, did the patentee define the terms as synonymous; absent such evidence, a common-sense understanding should prevail.
If the term is not to be read as equivalent to "natural language," it remains to construe "human-useable" in its own right. The patent language itself is not particularly illuminating in this regard, but the prosecution history may provide some guidance. The patentee emphasized the invention's distinctions from the prior art, in which the (more expensive) diagnostic devices had the capability of "displaying or printing out a message in some format[,]" which could take the form of "either an error code (e.g. error number P0171) or some natural language description of the error (e.g. system too lean (bank one))." '469 Patent at 2:8-19. It explained that the patented device, by contrast, need not "contain any of the database or processing elements necessary to convert the error codes acquired from the vehicle into a human-readable format that either displays the nature of the problem or a suggested solution." Defs.' Ex. 19 at 12-13 (Amendment and Response, 24 Dec. 2003). According to its plain meaning, "human-useable" sets a considerably lower bar than "natural language." In the context of an auto diagnostic device with the limitations further elaborated upon in the prosecution history, we conclude that Defendants' proposed construction—a "visual display of diagnostic data, or diagnostic information derived therefrom"—is appropriate.
Webster's Third New International Dictionary defines something "usable" or "useable" as something (1) "that can be used" or (2) "that is convenient and practicable for use." Webster's Third New International Dictionary, at 2523 (3d ed. 1993).
Plaintiff objects that Defendants' inclusion of the concept of a "visual display" is unwarranted. This objection, however, stems from a theory we have already rejected—that the only kind of "human-useable" display contemplated by the patent is a "natural language" one. "Any display of the error code information," says Plaintiff, "refers to display in a human understandable or natural language format, not in error code format." Docket No. 33 at 17 (citing '469 Patent at 4:67-5:3, 14:33-41). Guided by the prosecution history and the broad plain meaning of the term, we believe that "human-useable" is a term broad enough to encompass a display of error codes unaccompanied by a natural language elaboration. As Defendants pointed out at the hearing, a consumer can "use" an error code in numerous ways, including by referring to an owner's manual.
B. "Sufficient data processing capability"
The parties also disagree over the proper construction of the term "data processing capability." Plaintiff insists that the intrinsic evidence gives the term a definition more particular than that suggested by the words themselves—in other words "data processing capability" is not simply "the ability to process." "It is clear," Plaintiff says, "that the entirety of the data processing capability as described in the claimed inventions refers to processing, memory (storage), and database capabilities." Docket No. 33 at 14 (emphasis original). Plaintiff quotes the specification, which, in describing prior art, explains that "converting the error codes retrieved from a vehicle into a human readable and understandable action report, that either suggests the cause of the error, or preferably, suggests a proposed solution to the malfunction, requires that the scanning device include a database." '469 Patent at 4:49-53. Plaintiff further quotes the prosecution history, in which the patentee stated as follows:
In this regard, it has been found by the Applicant that the most expensive components of known computerized automotive diagnostic systems tend to be the processor required to process the information, the data storage component, such as a hard drive, or the like required to hold the large amount of data that exists relating to diagnostic codes for diagnosing malfunctions in a wide array of automobiles that exist; and the data base of information itself.Pl.'s Ex. 3 at 11 (7/24/03 Amendment).
We agree with Defendants that Plaintiff has misapplied the intrinsic evidence here. It may be that an "action report" suggesting the cause of, or solution to, automotive problems will require the use of a database; it does not follow, however, that the processing of data to produce any "human-useable" information is impossible without recourse to such a database. The portion of the July 2003 Amendment cited by Plaintiff actually helps drive home this point: it discusses the "processor" and the "data base" as separate entities. See Pl.'s Ex. 3 at 11.
Just as with the construction of "processing," we do not find that the patentee used the claims or specification to craft a special lexicon for the term "data processing capability." Since we have already adopted a definition of "processing," we conclude that the term needs no further elaboration. The patent gives us no reason to construe "data processing capability" as anything more or less than the capability of processing—manipulating—data.
Neither party has ventured to define "capability" itself in any special manner; we find that the term's ordinary meaning is readily apparent.
C. Adopted Construction
We therefore construe the claim term "lacks sufficient data processing capability to fully process the unprocessed diagnostic data into human-useable diagnostic information" to have the following meaning: "lacks sufficient data processing capability (as 'processing' is elsewhere defined) to fully process the unprocessed diagnostic data into a visual display of diagnostic data, or information derived therefrom." IV. "Data capture and memory unit" ('469 patent, claim 17; '368 patent, claim 17)
| Plaintiff's Proposed Construction | Defendants' Proposed Construction |
| Unit capable of acquiring and storing data | A unit that has limited functionalities consisting solely of acquiring data and storing data |
The crux of the dispute between the parties with respect to this term is whether the "data capture and memory unit" should be read as capable of transferring unprocessed data to a server via the internet. Defendants argue that the patentee disclaimed such an expansive reading of the term in communications with the patent office; Plaintiff contends that the context of the patent and prosecution history makes clear that no such limited construction is warranted.
Defendants originally proposed a construction that would limit the "data" involved in this term to "unprocessed diagnostic data." They have since conceded, however, that the transmission of reset codes from the device to the vehicle is among the functions covered by the patent, and thus "data" must be read more broadly here. See Docket No. 34 at 23.
The parties agree that the "data capture and memory unit" described in the patent is capable of retrieving ("acquiring") data from an automobile and storing that data electronically. Docket No. 33 at 19; Docket No. 34 at 23. In Claim 17, the patent explicitly describes the functions of the "data capture and memory unit," which itself is a part of the handheld unit—the "data acquisition and transfer device" (DAT). According to the patent, the DAT includes a "data capture and memory unit capable of retrieving unprocessed data from the vehicle via the first data link, storing the unprocessed diagnostic data for a limited time period, and transferring the unprocessed data to the global computer network, through the second data link . . . ." '469 Patent at 18:65-19:3. Two other claims, 10 and 23, ascribe the same three functions to the "data capture and memory unit," but do so in more restrictive language; Claim 10 states that the unit is capable only of performing those three functions, id. at 17:63-18:3, while Claim 23 says that the unit is capable generally only of doing so. Id. at 20:21-29.
We agree with Plaintiff that Claim 17 itself outlines the capabilities of the "data capture and memory unit," and no further exercise in construction is necessary. Pursuant to the presumption that a patentee chooses its words carefully, we do not believe that Claim 17 should be read as strictly limiting the unit to the functionalities described. Cf. Absolute Software, Inc. v. Stealth Signal, Inc., 659 F.3d 1121, 1141 (Fed. Cir. 2011) (noting that a court should not construe terms so as to render qualifying words meaningless). The language of Claims 10 and 23 shows clearly that the patentee was capable of inserting explicitly restrictive language when it wanted to, and nothing in the intrinsic record contradicts this reading. In objecting to Plaintiff's proposed construction, Defendants primarily rely on the prosecution history, particularly a statement that accompanied an amendment to Claim 17. In a communication to the Patent Office, the patentee explained: "Claims 10 and 17 have been amended to recite, inter alia, that the hand-holdable device is a data capture device, with limited functionalities, that relies on a remotely located server for processing information, and a personal computer (or other internet communication capable device) for presenting the processed information to the consumer." Defs.' Ex. 19 (emphasis added). Although this statement might support the notion—undisputed between the parties—that the patented device has "limited functionalities," it is not nearly specific enough to constitute a disclaimer of a data transferring function for the data capture and memory unit. See TecSec, Inc. v. IBM Corp., 731 F.3d 1336, 1346 (Fed. Cir. 2013) ("[F]or prosecution disclaimer to attach, our precedent requires that the alleged disavowing actions or statements made during prosecution be both clear and unmistakable.") (quoting Omega Eng'g, Inc. v. Raytek Corp., 334 F.3d 1314, 1325-1326 (Fed. Cir. 2003)).
The quoted statement also refers to the "hand-holdable device" rather than the "data capture and memory unit" which constitutes a part of it. This portion of the prosecution history—most saliently the abandonment of the term "processor" for "data capture"—is consistent with the notion that the patentee was attempting to disclaim any "processing" functionality for the device. Transferring data, however, is not the same as "processing" it, as the Claims themselves make clear. See '469 Patent at 18:65-19:2 ("transferring the unprocessed data to the global computer network") (emphasis added).
Defendants also argue that the patentee's substitution of "data capture" for "processor" (the unit had originally been called a "processor and memory unit") indicates that the claim language in Claim 17 should be read to exclude any "processing" capability. But the language of Claim 17 itself settles this issue, as we have already discussed. The claim states that the "hand holdable data acquisition and transfer device"—of which the data capture and memory unit is a part—"lacks sufficient data processing capability to fully process the unprocessed diagnostic data into human-useable diagnostic information." '469 Patent at 19:4-7. There is no need to belabor the question further in construing this particular claim term.
For the reasons we have discussed, we construe the term "data capture and memory unit" simply as follows: a "unit capable of acquiring, storing, and transferring data." V. "Storing the unprocessed data to the global computer network, through the second data link" ('368 patent, claim 17)
This differs from Plaintiff's proposed construction only in that it adds the word "transferring." Since Plaintiff argued extensively in its briefs and at the hearing that a transferring function was integral to the unit's identity, we feel the interests of clarity are better served by including the word in the definition. As we have discussed above, however, the delineation of these three functions should not be read as excluding other possible functions.
--------
| Plaintiff's Proposed Construction | Defendants' Proposed Construction |
| Storing the unprocessed data for a limited time period, and transferring the unprocessed data to the global computer network, through the second data link. | This term is insolubly ambiguous. It is unclear what is meant by "storing ... to the global computer network". This language could be interpreted to mean that the unprocessed data/diagnostic data is stored in one of several locations. For example, this language could mean that the unprocessed data/diagnostic data is stored on the hand holdable data acquisition and transfer device ("DAT device") in preparation for being transferred to the global computer network communicable device. Alternatively, this language could mean that the unprocessed data/diagnostic data is stored on the global computer network communicable device in preparation for being transferred to the server via the global computer network. Or, in yet another alternative, this language could mean that the unprocessed data/diagnostic data is stored on the server in preparation for being processed into a report in a natural language or for data mining purposes or for future retrieval by the user. Alternatively, it could be that the limitation includes a typographical error that renders it nonsensical. It is too ambiguous to determine an appropriate interpretation. |
Plaintiff contends that the dispute over the claim term's construction stems from a typographical error by the U.S. Patent Office. The wording of Claim 17 of the '368 Patent, as submitted to the USPO, described a "data capture and memory unit capable of retrieving unprocessed data via the first data link, storing the unprocessed data for a limited time period, and transferring the unprocessed data to the global computer network, through the second data link . . . ." Ex. 6 (10/4/2004 Preliminary Amendment) at 14-15 (emphasis added). The phrase highlighted above was omitted from the final patent, which resulted in the "insoluble ambiguity" to which Defendants initially objected.
However, Defendants in their brief have accepted Plaintiff's ascription of the issue to a clerical error, and they have agreed to Plaintiff's proposed construction. Docket No. 34 at 26. They add only that "unprocessed data," as used in the claim, should be defined as they have elsewhere proposed. The parties did not dispute this construction at the Markman hearing. We therefore adopt Plaintiff's proposed construction. VI. "Using the remote server to process the unprocessed data" ('469 patent, claim 17; '368 patent, claim 17)
| Plaintiff's Proposed Construction | Defendants' Proposed Construction |
| Using the remote server to interpret the unprocessed diagnostic data into descriptions in a natural language format which may be understood by a typical consumer | Using the remote server to manipulate the unprocessed data/diagnostic data (defined above) from its original form and format into a different form or format. "Server" has its plain and ordinary meaning. |
The parties agree that "server" requires no further construction, and they also agree that the meaning of "to process the unprocessed data" is determined entirely by the constructions the Court adopts for the first two disputed terms (Sections I and II above). See Docket No. 33 at 28; Docket No. 34 at 26. Relying on the constructions we have adopted above, we therefore construe this term as follows: "Using the remote server to manipulate data about problems or malfunctions in a vehicle, such as diagnostic trouble codes (DTCSs) or error codes, which had heretofore remained in the original form and format in which they were retrieved from the vehicle."
Conclusion
For the reasons detailed above, we conclude that the proper construction of the disputed terms of the >469 and '368 Patents is as follows:
| Disputed Term | Court's Construction |
| 1. "Unprocessed diagnostic data" and "unprocessed data" | Data about problems or malfunctions in a vehicle, such as diagnostic trouble codes (DTCs) or error codes, remaining in the original form and format in which they were retrieved from the vehicle |
| 2. "Processing the unprocessed diagnostic data into natural language diagnostic information" | Manipulating the unprocessed diagnostic data (as previously defined) into a non-technical, non-alphanumeric verbal report in a format that may be understood by both a typical consumer and a service technician." |
| 3. "lacks sufficient data processing capability to fully process the unprocessed diagnostic data into human-useable diagnostic information" | Lacks sufficient data processing capability to fully process (as previously defined) the unprocessed diagnostic data into a visual display of diagnostic data, or information derived therefrom. |
| 4. "Data capture and memory unit" | Unit capable of acquiring, storing, and transferring data |
| 5. "Storing the unprocessed data to the global computer network, through the second data link" | Storing the unprocessed data for a limited time period, and transferring the unprocessed data to the global computer network, through the second data link. |
| 6. "Using the remote server to process the unprocessed data" | Using the remote server to manipulate data about problems or malfunctions in a vehicle, such as diagnostic trouble codes (DTCSs) or error codes, which had heretofore remained in the original form and format in which they were retrieved from the vehicle. |
IT IS SO ORDERED.
__________
SARAH EVANS BARKER, JUDGE
United States District Court
Southern District of Indiana
Distribution: Jeffrey Kersting
jkersting@fbtlaw.com
Ann G. Schoen
FROST BROWN TODD LLC
aschoen@fbtlaw.com
James Dimos
FROST BROWN TODD LLC
jdimos@fbtlaw.com
Nicholas C. Pappas
FROST BROWN TODD LLC
npappas@fbtlaw.com
Joseph A. Culig
NIRO HALLER & NIRO
jculig@nshn.com
Kara Szpondowski
NIRO HALLER & NIRO
szpondowski@nshn.com
Raymond P. Niro
NIRO HALLER & NIRO
rniro@nshn.com
Spiro Bereveskos
WOODARD EMHARDT MORIARTY MCNETT & HENRY, LLP
judy@uspatent.com