Opinion
CV-22-00018-PHX-MTL
02-03-2023
TD Professional Services, Plaintiff, v. Truyo Incorporated, et al., Defendants.
CLAIM CONSTRUCTION ORDER
MICHAEL T. LIBURDI, UNITED STATES DISTRICT JUDGE.
The Court held a Markman hearing on January 18, 2023 and now enters the following claim construction Order.
I. BACKGROUND
Plaintiff TD Professional Services owns U.S. Patent Nos. 10,304,062 and 10,628,833 (the “'062 Patent” and the “'833 Patent,” respectively; collectively, the “Patents-in-Suit”). The Patents-in-Suit claim a computer system and methods that employ blockchain-based technology for data regulation compliance. Defendants offer a compliance software product for the European Union's General Data Protection Regulation (“GDPR”). (Doc. 65, ¶ 22.) Plaintiff alleges that Defendant Intraedge Inc.'s products and related methods directly infringe the Patents-in-Suit and that Defendant Intraedge induced Defendant Truyo, Inc. to infringe the same. (Doc. 60, ¶¶ 81-96.)
The '062 Patent issued on May 28, 2019. (Ex. 1 to Plaintiff's Opening Claim Construction Brief, Doc. 94-1.) The '833 Patent is a continuation from the '062 Patent that issued on April 21, 2020. (Ex. 2 to Plaintiff's Opening Claim Construction Brief, Doc. 94-2.) The Patents-in-Suit share a specification, except for three additional paragraphs in the '833 Patent that are not relevant here. The field of invention for both Patents-in-Suit is described as “computer architectures that automatically comply with data regulations by generating or employing immutable audit ledgers;” particularly “computer systems that effectively comply with data processing regulations including, but not limited to, the [GDPR].” (Doc. 94-1, Column 1, lines 8-14.) The Background of the Invention section of the specification provides in part:
Because of the nearly identical specification, for ease of reference, the Court cites only to the '062 Patent to represent both Patents-in-Suit unless otherwise noted.
Hereinafter, patent citations will identify the column and line numbers using a colon, e.g., 1:8-14.
Ideally, such a computer system architecture would permit the data subjects themselves to access the data being stored about them, yet also permit merchants, financial, medical and academic professionals (and others) to only access pseudonymized data about the data subjects (thereby maintaining the data subjects' privacy and anonymity) . . . [and] would seamlessly and automatically generate an auditably verified record in a timely fashion that the data stored therein complies with data processing regulations such as GDPR.(Doc. 94-1, 2:13-22.)
The '062 Patent issued with 2 independent claims-claims 1 and 17-and 18 dependent claims. All but one of the disputed terms are in independent claim 17. Dependent claim 19 contains the other disputed term, “private blockchain.” (Doc. 94-1, Col. 11-12.) The '833 Patent issued with 2 independent claims- claims 1 and 18-and 20 dependent claims. All the disputed terms are in independent claim 18, except for three terms that only appear in the '062 Patent claims, as noted in the table in Part III, infra. (Doc. 94-2, Col. 10-12.) Only method claims, claims 17-20 of the '062 Patent and claims 18-20 of the '833 Patent, are at issue in this action. (Doc. 94 at 2.)
The parties have asked the Court to construe thirteen terms from the Patents-in-Suit. Pursuant to Markman v. Westview Instruments, Inc., 517 U.S. 370, 372 (1996), the Court must construe the claims as a matter of law. The parties have filed briefs supporting their proposed constructions of the claim terms. (Docs. 94, 96, 99.) Having considered the arguments and evidence presented in the parties' briefs, exhibits, and at the Markman hearing, the Court construes the disputed terms as follows.
The parties originally identified twenty-seven terms for this Court's construction. (See Doc. 73.) The parties later stipulated that the Court need not construe six of the original terms (Doc. 92) and provided an agreed construction for another eight of those terms (Doc. 79). A list of the thirteen terms construed in this Order is contained in the table in Part III, infra.
II. LEGAL STANDARD
Claim construction, the determination of the meaning and scope of the asserted claim terms in a patent, is a question of law exclusively within the province of the Court. Markman, 517 U.S. at 372; O2 Micro Int'l Ltd. v. Beyond Innovation Tech. Co., 521 F.3d 1351, 1360 (Fed. Cir. 2008). In construing claim terms, considering the intrinsic evidence, such as the language of the claims, the specification, and the prosecution history, is paramount. Phillips v. AWH Corp., 415 F.3d 1303, 1312-17 (Fed. Cir. 2005) (en banc) (quotation omitted). The Court should first “look to the words of the claims themselves,” giving them their plain and ordinary meaning, unless clearly stated otherwise. Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996). The plain and ordinary 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.” Phillips, 415 F.3d at 1312-13. The plain and ordinary meaning of a term should control, unless “a patentee sets out a definition and acts as his own lexicographer, or . . . disavows the full scope of a claim term either in the specification or during prosecution.” Torner v. Sony Computer Entm't Am. LLC, 669 F.3d 1362, 1365 (Fed. Cir. 2012). The claim language can provide insight based on the context of how the terms are used and by comparison to the use of the same or similar terms in other claims in the patent. Phillips, 415 F.3d at 1314.
The Court next looks to the patent specification as “the single best guide to the meaning of a disputed term” and “usually dispositive.” Id. at 1315; see also Merck & Co. v. Teva Pharm. USA, Inc., 347 F.3d 1367, 1371 (Fed. Cir. 2003) (explaining that “claims must be construed so as to be consistent with the specification”). Courts therefore may rely heavily on the written description of the claims in the specification for guidance. Phillips, 415 F.3d at 1317. When reviewing the specification, however, courts must avoid reading limitations from the specification into the claims. Id. at 1323 (“[A]lthough the specification often describes very specific embodiments of the invention, we have repeatedly warned against confining the claims to those embodiments.”). Courts should also consider the patent's prosecution history, or the record of the patent application proceedings before the United States Patent and Trademark Office (the “USPTO”). Phillips, 415 F.3d at 1317. The prosecution history, although lacking the “clarity” of the specification, is also part of the intrinsic record and provides evidence of how the USPTO and the inventor understood the patent and what its claims cover. Id. In particular, the prosecution history may provide evidence on whether the inventor limited the scope of the claimed invention to obtain the patent, thereby making the claim scope narrower than it otherwise would be. Id.
The Court may also consider extrinsic evidence, such as technical dictionaries, learned treatises, and the testimony of experts and inventors. Id. For example, expert testimony can help “ensure that the court's understanding of the technical aspects of the patent is consistent with that of a person of skill in the art, or to establish that a particular term in the patent or the prior art has a particular meaning in the pertinent field.” Id. at 1318. But the Court must discount any expert testimony “that is clearly at odds with the claim construction mandated by the claims themselves, the written description, and the prosecution history, in other words, with the written record of the patent.” Id. (internal quotations omitted). Although it may prove useful, extrinsic evidence is less significant than the intrinsic record for determining the meaning of claim language. Id. In most situations, analysis of the patent and its prosecution history will resolve any ambiguity in a disputed claim term. Vitronics, 90 F.3d at 1583.
“Because dictionaries, and especially technical dictionaries, endeavor to collect the accepted meanings of terms used in various fields of science and technology, those resources have been properly recognized as among the tools that can assist the court in determining the meaning of particular terminology to those of skill in the art of the invention.” Phillips, 415 F.3d at 1318.
III. CLAIM CONSTRUCTION
The following chart summarizes the Court's adopted constructions for each of the disputed claim terms. The analysis supporting the constructions follows.
Claim Term
Term Location
Adopted Construction
“data input stream”
'062 Patent, Cl. 17(a) '833 Patent, Cl. 18(a)
A transmission of data related to an exchange or interaction between parties
“data collection terminal”
'062 Patent, Cl. 17(a) '833 Patent, Cl. 18(a)
A terminal for collecting data that includes a compliance device driver
“compliance markup language tags”
'062 Patent, Cl. 17(b)
Text, defined by a data controller, that instructs the compliance markup language parser to identify, categorize, and forward data elements
“compliance device driver”
'062 Patent, Cl. 17(b) '833 Patent, Cl. 18(b)
Software, resident in the data collection terminal, that intercepts the data input stream
“compliance markup language parser”
'062 Patent, Cl. 17(c) '833 Patent, Cl. 18(c)
Software that performs pseudonymization and determines which data is sent to the data output device
“automated compliance network appliance”
'062 Patent, Cl. 17(c) '833 Patent, Cl. 18(c)
A physical device (having a processor, memory and local storage)
“network interface connection”
'062 Patent, Cl. 17(c) '833 Patent, Cl. 18(c)
A physical USB drive or physical router
“local storage”
'062 Patent, Cl. 17(c) '833 Patent, Cl. 18(c)
Plain and ordinary meaning
“pseudonymized data”
'062 Patent, Cl. 17(c) '833 Patent, Cl. 18(c)
Data in which some portion of the fields are replaced with one or more artificial identifiers (rather than being removed)
“blockchain miners”
'062 Patent, Cl. 17(d) '833 Patent, Cl. 18(d)
Processors that achieve consensus in a blockchain system by solving mathematical problems
“data lake”
'062 Patent, Cl. 17(e) '833 Patent, Cl. 18(e)
A data repository that stores raw, unstructured data, and is not a database
(e) . . ., while simultaneously; (f) . . ., and (g) . . .;
'062 Patent, Cl. 17(e)
Plain and ordinary meaning
“private blockchain”
'062 Patent, Cl. 19
Plain and ordinary meaning
A. “data input stream”
Plaintiff proposes the following construction: “Any data that is input into the described invention and is capable of being collected by a collection terminal.” (Doc. 104-1 at 1.) Defendants propose the following competing construction: “A continuous transmission of data related to an exchange or interaction between parties.” (Id.) In its reply, Plaintiff stipulates that the “data” in the “data input stream” is limited to “data concerning ‘an exchange or interaction between parties,'” but does not agree that the transmission must be “continuous.” (Doc. 99 at 2-3.)
The disputed term is mentioned four times in independent claim 17 of the '062 Patent. Claim 17 requires:
(a) collecting a data input stream with a data collection terminal; (b) selecting in-scope data in the data input stream that corresponds to pre-identified data fields by identifying compliance markup language tags embedded in the data input stream. . .; (e) transmitting the data input stream into a data lake as raw, unstructured and unaltered data. . . .(Doc. 94-1, 11:16-12:7.) The specification explains that “[t]he data input stream can comprise data about can be [sic] purchases, restaurant bills, legal agreements, academic grades, financial transactions, travel locations and itineraries, etc.” (Id. at 5:5-8.) Importantly, none of these references to the “data input stream” in the patent itself require that it be input as a continuous transmission, as Defendants suggest. Although Defendants attempt to rely on extrinsic evidence in the form of expert testimony and a definition of “streaming data transmission,” the Court finds these sources unpersuasive and unsupported by the intrinsic record. Phillips, 415 F.3d at 1318. On the other hand, Plaintiff's proposed construction unnecessarily repeats limitations from the claim language that do not provide clarity on the meaning of the term. Bicon, Inc. v. Straumann Co., 441 F.3d 945, 950 (Fed. Cir. 2006) (“[C]laims are interpreted with an eye toward giving effect to all terms in the claim.”) Thus, the Court construes “data input stream” to mean a transmission of data related to an exchange or interaction between parties.
Defendants' proffered definition for “streaming data transmission” is a “method of transmitting a media file in a continuous stream of data that can be processed by the receiving computer before the entire file has been completely sent.” (Doc. 96 at 11.) Defendants do not point to any support in the intrinsic record that the invention contemplates the transmission of media files or should be limited as such. Indeed, the preamble of Claim 17, “[a] method of providing an auditable record showing transaction compliance with data regulations,” does not suggest that the incoming data stream is a media file.
B. “data collection terminal”
Plaintiff proposes the following construction: “Any device for collecting a data input stream, including but not limited to, a point of sale terminal, a web page, a cash register, a check in counter, a hand held mobile device, a virtual terminal and/or an API.” (Doc. 101-1 at 2.) Defendants propose the following competing construction: “A terminal for collecting data that includes a compliance device driver.” (Id.)
The parties dispute whether the data collection terminal must include a compliance device driver. “Data collection terminal” is mentioned once in independent claim 17 and once in dependent claim 18 of the '062 Patent. Claim 17 requires “collecting a data input stream with a data collection terminal.” (Doc. 94-1, 11:16-17.) Claim 18 further describes the same method using “a point of sale terminal, a webpage, a cash register, a check-in counter, a hand-held mobile device, or an API.” (Id. at 12:19-23.) “Compliance device driver” is also mentioned once in Claim 17: “. . . wherein the in-scope data are selected by a compliance device driver. . . .” (Id. at 11:23-24.)
The specification describes the “data collection terminal” and “compliance device driver” in further detail, in reference to Figures 1, 2, and 3. Figure 1 “is a system diagram of the present invention.” (Id. at 4:26.) In box 1, Figure 1 illustrates a “Data Collection Terminal with Compliance Device Driver.” (Id. at Fig. 1.) Figure 2 “is a system diagram showing further details of the compliance enabled data collection terminal” of Figure 1. (Id. at 4:27-28.) In box 9, Figure 2 illustrates a “Compliance Device Driver.” (Id. at Fig. 2.) Figure 3 “is a system diagram showing further details of the compliance device driver” of Figure 1. (Id. at 4:29-30.)
The specification explains:
Referring first to FIG. 1, an overview of computer architecture 101 for providing compliance with data regulations is provided, as follows. A data collection terminal 1 is configured to receive a data input stream. A compliance device driver (9 in FIG. 2) is resident in data collection terminal 1. The compliance device driver performs . . . two functions.(Id. at 4:49-55). The specification further explains, “[a]s can be seen, the automated compliance network appliance 2 is in communication with compliance device driver 9 within data collection terminal 1.” (Id. at 5:25-27.) The specification goes on:
FIG. 2 shows further details of the data collection terminal with compliance device driver 1, as follows. In various aspects, data collection terminal 1 can include any suitable data input device 7 for collecting data, including, but not limited to, a point of sale terminal, a webpage, a cash register, a check-in counter, a hand-held mobile device, or an API.(Id. at 5:54-60.) The specification does not contemplate or describe any variation of a compliance device driver that is not present in the data collection terminal. Furthermore, the specification does not suggest that having the compliance device driver within the data collection terminal is optional or preferred, as it does with other components of the system. As an example, Figure 2 also illustrates that the data collection terminal contains a “data input device” in box 7, a “POS application” in box 8, and an “output device” in box 11. (Id. at Fig. 2.) Notably, with reference to these components, the specification explains that “[t]he data collection terminal optionally comprises a data input device and a data output device.” (Id. at 3:51-52 (emphasis added); see also id. at 5:61-62 (“Preferably, data collection terminal 1 comprises a data input device 7 and a data output device 11.”) (emphasis added).) “In optional preferred aspects, the data collection terminal includes a Point Of Sale (POS) Application 8 therein.” (Id. at 6:14-15 (emphasis added).) In contrast, the specification does not use optional language when describing that the compliance device driver resides in the data collection terminal. Thus, the Court finds that the specification supports Defendants' proposed construction requiring the data collection terminal to contain a compliance device driver.
Moreover, as Plaintiff pointed out at the hearing, the specification uses the terms “preferably,” “optionally, “for example,” or “can De” 28 times to identify preferred aspects of the invention. Such qualifying language is not used with respect to whether the data collection terminal includes a compliance device driver. See Rexnord Corp. v. Laitram Corp., 274 F.3d 1336, 1345 (Fed. Cir. 2001) (relying on an inventor's “careful” and “consistent” use of phrases throughout the specification identifying preferred embodiments to find that an inventor has described an invention that encompasses more than one embodiment).
Plaintiff rejects the explanation of these terms in the specification because it is in reference to the system claims, as opposed to the method claims at issue here. The Court notes, however, that Plaintiff's insistence that the detailed description of the invention must be split into two sections is unsupported by any authority. See Philips, 415 F.3d at 1313 (“[T]he 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 [it] appears, but in the context of the entire patent, including the specification.”). Additionally, the prosecution history shows that in making amendments and arguments to the USPTO, the applicant argued the system and method claims together, citing the same evidence from the specification for both types of claims. (See Doc. 94-6 at 2, 5.) Moreover, there are only two paragraphs in the entire specification that specifically reference the method claims and neither of them discuss the compliance device driver. (Doc. 94-1, 8:34-56.) Thus, to the extent Plaintiff asks the Court to limit its consideration to those two paragraphs, the Court declines. Only reviewing that section of the specification for support would implicate potential written description and enablement issues related to the “compliance device driver” in claim 17. See Liebe-Flarsheim Co v. Medrad, Inc., 358 F.3d 898, 911 (Fed. Cir. 2004) (holding that where claim terms are ambiguous, “claims should be so construed, if possible, as to sustain their validity.”). The parties did not brief these issues and the Court need not reach them to resolve the parties' dispute.
For its part, Plaintiff seeks to define the data collection terminal from claim 17 using various examples enumerated in claim 18 with the addition of “a virtual terminal.” Independent claims are presumed to have broader scope than their dependents, however. Acumed LLC v. Stryker Corp., 483 F.3d 800, 806 (Fed. Cir. 2007). The presence of a particular limitation in a dependent claim raises a presumption that the limitation is not found in the independent claim. Id. “That presumption is especially strong when the limitation in dispute is the only meaningful difference between an independent and dependent claim, and one party is urging that the limitation in the dependent claim should be read into the independent claim.” Id. Here, Plaintiff does not adequately explain a meaningful difference between its proposed construction and the limitations in claim 18. The addition of “a virtual terminal” to the list from claim 18 does not do enough to differentiate the claims because it is not a term found in the intrinsic record. Moreover, Plaintiff's attempt to limit the data collection terminal to the enumerated list of preferred embodiments in the specification is contrary to established precedent. Comark Communications, Inc. v. Harris Corp., 156 F.3d 1182, 1187 (Fed. Cir. 1998) (holding that it is generally improper to read a limitation from the specification into the claim). Thus, the Court declines to adopt Plaintiff's proposed construction. The Court adopts Defendants' proposed construction, a terminal for collecting data that includes a compliance device driver, for the reasons discussed above.
C. “compliance markup language tags”
Plaintiff proposes the following construction: “Metadata that identifies or bounds certain information within a data input stream, in relation to pre identified data fields, including but not limited to any markup language from any text e-coding system.” (Doc. 104-1 at 1.) Defendant proposes the following competing construction: “User-defined text that instructs the compliance markup language parser to identify, categorize, and forward data elements related to compliance regulations.” (Id.)
Claim 17 is directed to “[a] method of providing an auditable record showing transaction compliance with data regulations.” (Doc. 94-1, 11:14-15.) Claim 17 requires: “selecting in-scope data in the data input stream that corresponds to pre-identified data fields by identifying compliance markup language tags embedded in the data input stream, wherein the pre-identified data fields are determined by data compliance regulations . . .” (Id. at 11:18-22.) The specification describes the functionality of the compliance device driver and compliance markup language parser using “compliance markup language tags”:
The '883 Patent claims do not recite compliance language markup tags.
[T]he compliance device driver 9 applies a compliance markup language parser (15 in FIG. 3) to the selected data, thereby generating pseudonymized data. . . . Specifically, as seen in FIG. 3, the compliance markup language parser 15 scans the data subject receipt data stream 13 and identifies compliance markup language tags that are embedded within data stream 13 as defined by a data controller 32 (FIG. 6). The compliance markup language tags instruct the compliance markup language parser 15 to identify, categorize, and forward data elements within the data stream to automated compliance network appliance 2.(Id. at 5:9-24 (emphasis added).) Additionally, the specification explains that Figure 7, which “illustrates the use of compliance markup language to generate a printed sales receipt” is “exemplary” of how the invention uses the compliance markup language tags to define “data elements that fall within the scope of GDPR or other data regulation[s].” (Id. at 4:39-40; 8:66-9:21.)
As Plaintiff notes, the central dispute is “whether the ‘compliance markup language tags' are properly limited to ‘data elements related to compliance regulations.'” (Doc. 94 at 10.) Plaintiff argues that the background information on compliance regulations in the specification is not definitional. Plaintiff further argues that limiting the tags to compliance regulations is not required because the claims already include that “the pre-identified data fields are determined by data compliance regulations.” (Doc. 94 at 12-13.) Defendant argues that the text of the claims themselves clearly require that the tags relate to compliance regulations, “so any proposed construction should appropriately contextualize this aspect of the claim term.” (Doc 96 at 14.)
The Court finds this limitation unnecessary in view of the claim language. The disputed term itself includes the word “compliance,” indicating that the markup language tags are related to compliance. Moreover, claim 17 requires that “the pre-identified data fields are determined by data compliance regulations.” (Doc. 94-1, 11:21-22.) The claim language explicitly links those pre-identified data fields to the compliance markup language tags: “selecting in-scope data in the data input stream that corresponds to preidentified data fields by identifying compliance markup language tags embedded in the data input stream. . . .” (Id. at 11:18-22.) It is clear from the claim that the data is selected based on data compliance regulations. Thus, the Court need not look to other evidence to resolve this dispute. Vitronics, 90 F.3d at 1582 (observing that “we look to the words of the claims themselves . . . to define the scope of the patented invention”). The Court finds that requiring the tags to be related to compliance regulations is unnecessary.
Additionally, the parties agree that the construction of a related term, “compliance markup language” is “a language that uses tags to identify compliance-related attributes of elements of a data stream.” (Doc. 101 at 8.)
Additionally, the phrase “user-defined text” in Defendants' construction is too broad to have intrinsic support in the specification. Instead, it is more accurate to construe the term to incorporate that the text underlying the tags is defined by the data controller. The term “user defined” is only used once in the specification, while the term “data controller” is used nineteen times. In the one instance where “user defined” appears, the specification notes that the tags “are user defined by [the] data controller.” (Doc. 94-1, 9:3-5.) Data controllers are defined as “organizations that collect, process, or control [] personal data from EU residents [] to comply with regulations.” (Id. at 1:28-30.) The specification explains that the compliance markup language parser “identifies compliance markup language tags that are embedded within data stream [] as defined by a data controller.” (Id. at 5:18-20; see also 6:58-59 (the system operates “in accordance with the processing requirements defined by data controller 32.”).) Although the data controller is a user of the system, the specification also identifies other users who do not have access to define the markup language tags. (See id. at 2:14-17 (“permit the data subjects themselves to access the data being stored about them, yet also permit merchants, financial, medical and academic professionals (and others) to only access pseudonymized data”); 3:34-36 (“data privacy is maintained such [that] these 3rd parties cannot access the full sets of all of the data stored corresponding to each data subject”); 3:41-43 (“auditors can view the compliance data without requiring access to any of the private information or systems”).) Thus, the Court's construction substitutes “data controller” for “user” in Defendants' proposed construction.
Finally, the Court finds that describing the tags in terms of their functionality is appropriate here. In describing the compliance device driver's functionality, the specification explains that the tags instruct the compliance markup language parser “to identify, categorize, and forward data elements within the data stream.” (Id. at 4:54-5:24.) This is the only explanation of the tags' functionality in the specification and the inventor did not use suggestive language indicating that these functions are merely a preferred embodiment. See Rexnord, 274 F.3d at 1345. The specification further describes “an exemplary” use of the tags that is consistent with the functional description identified above. (Doc. 94-1, 8:66-9:2 (“An opening compliance tag 38 and a closing compliance tag 44 define the opening and closing boundaries for data elements that fall within the scope of GDPR or other data regulation.”).)
Plaintiff's construction, on the other hand, includes the unsupported terms “metadata” and “text e-coding system.” The Court finds that introducing these terms of art without support from intrinsic or extrinsic evidence would unnecessarily complicate the meaning of compliance markup language tags. Accordingly, the Court adopts the following construction: text, defined by a data controller, that instructs the compliance markup language parser to identify, categorize, and forward data elements.
Although Plaintiff proposes this construction, Plaintiff's arguments are directed towards why Defendants' construction is incorrect, not why its own construction is the right one. (See Docs. 94, 99.)
D. “compliance device driver”
Plaintiff proposes the following construction: “Any non-transitory computer-readable medium having instructions stored therein that when executed by a computing device selects the in-scope data.” (Doc. 101-1 at 2.) Defendant proposes the following competing construction: “Hardware and software, resident in the data collection terminal, that intercepts the data input stream via a piping instruction.” (Id.)
As discussed above, “compliance device driver” is mentioned once in Claim 17:
selecting in-scope data in the data input stream . . . wherein the in-scope data are selected by a compliance device driver comprising a non-transitory computer-readable medium having instructions stored therein that when executed by a computing device selects the in-scope data[.](Doc. 94-1, 11:18-27 (emphasis added).) The specification explains:
The compliance device driver performs the following two functions. First, it selects data in the data input stream that corresponds to pre-identified data fields. . . . Second, the compliance device driver 9 applies a compliance markup language parser (15 in FIG. 3) to the selected data, thereby generating pseudonymized data.(Id. at 4:54-57; 5:9-11).
Similarly, independent Claim 18 of the '833 patent recites: “selecting data in the data input stream, . . . wherein the data are selected by a compliance device driver comprising a non-transitory computer-readable medium having instructions stored therein that when executed by a computing device selects the data[.y (Doc. 94-2, 12:14-21.)
First, the parties dispute whether the “compliance device driver” includes both hardware and software. Plaintiff supports its proposed construction based on a definition of compliance device driver that is already recited in independent claim 17. As such, it does not provide any additional clarity and would render the entire clause following the term redundant. Bicon, 441 F.3d at 950 (“[C]laims are interpreted with an eye toward giving effect to all terms in the claim.”). Accordingly, the Court declines to adopt Plaintiff's proposed construction. Defendants rely on the specification and prosecution history. Defendants also argue that to a person of ordinary skill in the art, “a non-transitory computer-readable medium having instructions stored therein” plainly means that the compliance device driver is both hardware and software. (Doc. 96 at 18.) The Court finds that, given the explicit definition in claim 17 that the compliance device driver comprises “a non-transitory computer-readable medium having instructions stored therein,” there is no need to include the terms “hardware and software” in the construction. Moreover, the Court has adopted a construction of “data collection terminal” that includes the compliance device driver therein, as discussed above, and nothing in the intrinsic record requires that the compliance device driver itself be a hardware component within the data collection terminal. Defendant's citation to the prosecution history and Plaintiff's expert's testimony both support this.
During prosecution, the applicant explained that the invention teaches “a physical compliance device (having a device driver resident therein)” and the claims were “amended to describe the compliance device being a non-transitory computer readable medium having instructions stored therein.” (Doc. 94-6 at 2.) Although Defendant points to this language as requiring the driver itself to be hardware, the Court disagrees. The applicant clearly distinguishes between a compliance device and a compliance device driver. Phillips, 415 F.3d at 1317 (“[T]he prosecution history can often inform the meaning of the claim language by demonstrating how the inventor understood the invention and whether the inventor limited the invention in the course of prosecution, making the claim scope narrower than it would otherwise be.”) (citing Vitronics, 90 F.3d at 1582-83). This interpretation is also supported by Plaintiff's expert testimony that a person of ordinary skill in the art would ordinarily refer to a driver as software that is stored on hardware, such as the computer-readable non-transitory medium with stored executable instructions recited in claim 17. (See Doc. 99 at 9); see also Philips, 415 F.3d at 1318 (“[E]xpert testimony can be useful to a court for a variety of purposes, such as to . . . establish that a particular term in the patent or the prior art has a particular meaning in the pertinent field.”) (citing Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1308-09 (Fed. Cir. 1999)).
The parties also dispute whether “intercepts the data input stream via a piping instruction” is a required limitation. As noted above, the specification describes that the compliance device driver performs two functions: selecting data from the data input stream and applying a parser to the selected data to create pseudonymized data. (Doc. 94-1, 4:49-57; 5:9-11). The specification describes these steps in further detail as follows:
First, the full data stream 13 relating to a data subject is
received. Next, at 14, the data stream is intercepted via a piping instruction that re-directed the data stream to the compliance markup language parser 15. After processing by parser 15, the data is then directed into output device 11. Compliance markup language parser 15 performs pseudonymisation [sic] (and optionally encryption as well) at 18, thereby sending pseudomynized [sic] data to automated compliance network appliance 2. (In the absence of data stream intercept 14, the data would instead simply pass directly into output device 15 without being pseudonymised [sic]).(Id. at 6:25-36.) This discussion makes it clear that intercepting the data stream is an important, necessary step in the invention. If there is no interception step, “the data would instead simply pass directly into output device 15 without being [pseudonymized].” (Id.) One advantage of the invention is to “shield[] private information from public stakeholders.” (Id. at 4:21-22.) Without intercepting the data for pseudonymization, one purpose of the invention would not be achieved. Courts must construe claims in a manner that achieves the invention's contemplated purpose and covers any preferred embodiments outlined in the specification. Accent Packaging, Inc. v. Leggett & Platt, Inc., 707 F.3d 1318, 1326 (Fed. Cir. 2013) (“[A] claim interpretation that excludes a preferred embodiment from the scope of the claim is rarely, if ever, correct.”) (citation omitted). Further, the above excerpt is the only portion of the specification that details how the compliance device driver selects the in-scope data as claimed in Claim 17.
Defendants argue that the data interception must occur “via a piping instruction” because the specification only teaches intercepting the data in this manner. (Doc. 96 at 20-22.) Plaintiff argues that intercepting the data using a piping instruction is a preferred embodiment only, so the compliance device driver should not be limited to operating by this process. (Doc. 99 at 8.) “Our case law is clear that an applicant is not required to describe in the specification every conceivable and possible future embodiment of his invention.” Rexnord, 274 F.3d at 1344 (citing SRI Int'l v. Matsushita Elec. Corp. of America, 775 F.2d 1107, 1121 (Fed. Cir. 1985) (en banc)). “[I]f structural claims were to be limited to devices operated precisely as a specification-described embodiment is operated, there would be no need for claims. Nor could an applicant, regardless of the prior art, claim more broadly than that embodiment.” Id. (quoting SRI Int'l, 775 F.2d at 1121). Elsewhere in the specification, this data interception step is described more broadly:
[T]he compliance device driver 9 applies a compliance markup language parser (15 in FIG. 3) to the selected data, thereby generated pseudonymized data. . . . [T]he compliance markup language parser 15 scans the data subject receipt data stream 13 and identifies compliance markup language tags that are embedded within data stream 13 as defined by a data controller 32 (FIG. 6). The compliance markup language tags instruct the compliance markup language parser 15 to identify, categorize, and forward data elements within the data stream to automated compliance network appliance 2.(Doc. 94-1, 5:9-24.) “When the claim language is assessed on its own, and when the written description is examined carefully, one finds that the patentee has described an invention that embraces” data interception and routing techniques broadly, and the Court need not limit the process to occurring via a piping instruction. See Rexford, 274 F.3d at 1345; Valve Corp. v. Ironburg Inventions Ltd., 8. F.4th 1364, 1381 (Fed. Cir. 2021) (the proposed construction “improperly imports a limitation into the claim from a preferred embodiment”) (quoting TrebroMfg., Inc. v. Firefly Equip., LLC, 748 F.3d 1159, 1166 (Fed. Cir. 2014)).
Accordingly, the Court adopts the following construction: software, resident in the data collection terminal, that intercepts the data input stream.
E. “compliance markup language parser”
Plaintiff proposes the following construction: “Software that performs or contributes to the selection of in scope data based on any markup language from any text e-coding system.” (Doc. 104-1 at 1.) Defendant proposes the following competing construction: “Software that is part of the compliance device driver that performs pseudonymization, and determines which data is sent to the data output device.” (Id.)
The parties' dispute centers on whether the compliance markup language parser is part of the compliance device driver. Neither party argues for or against Plaintiff's proposed construction, and the Court notes that it is unnecessarily broad and introduces a “text e-coding system” that has no support in the intrinsic record.
In its reply, Plaintiff clarifies that it does not dispute that the compliance markup language parser performs pseudonymization or determines which data is sent to the data output device. (Doc. 99 at 10-11.)
Claim 17 provides, in part:
(b) selecting in-scope data in the data input stream that corresponds to pre-identified data fields by identifying compliance markup language tags embedded in the data input stream, . . . wherein the in-scope data are selected by a compliance device driver. . .;
(c) applying a compliance markup language parser to the in-scope selected data, and wherein the compliance markup language is applied by an automated compliance network appliance comprising a network interface connection having a processor, memory, and local storage, thereby generating pseudonymized data. . . .(Doc. 94-1, 11:18-12:2). From the claim language alone, it is not clear that the compliance markup language parser is a required component of the compliance device driver. Similarly, the specification suggests the parser could be part of the compliance device driver but also refers to it as a separate component with its own functionality. For example, the specification describes that the compliance device driver applies the parser to pseudonymize selected data that is sent to the automated compliance network appliance. (Id. at 5:9-11; 5:27-31 (“Automated compliance network appliance . . . receives the pseudonymized data generated by the compliance driver [] and then transmits [it] to the Internet.”).) Elsewhere in the specification, the parser performs the pseudonymization and sends the pseudonymized data to the automated compliance network appliance without reference to the compliance device driver. (Id. at 6:30-33.)
Figure 3 “is a system diagram showing further details of the compliance device driver of FIG. 1” and includes a compliance markup language parser in box 15. (Id. at 4:29-30; Fig. 3.) In reference to Figure 3, the specification explains that “the data stream is intercepted via a piping instruction that re-directed the data stream to the compliance markup language parser 15.” (Id. at 6:27-29.) After receiving the data selected by the compliance device driver, the compliance markup language parser scans it “and identifies compliance markup language tags . . . embedded within data stream” and uses those tags “to identify, categorize, and forward data elements within the data stream to [the] automated compliance network appliance.” (Id. at 5:16-24.) These descriptions do not limit the location of the compliance markup language parser to the compliance device driver.
Defendants argue that the specification describes a compliance markup language parser housed within the compliance device driver and provides no alternative teachings regarding the parser's location. (Doc. 96 at 23.) In reference to the method claims, however, the specification does not limit the location of the parser to the compliance device driver or any other component of the system. “In another aspect, the present system includes a method of providing an auditable record showing transaction compliance with data regulations, by: . . . applying a compliance markup language parser to the selected data, thereby generating pseudonymized data. . . .” (Doc. 94-1 at 2:51-59; see also id. at 8:34-42.) The Court finds that the specification supports variations of the invention where the compliance markup language parser is not within the compliance device driver, particularly in view of the plain language of claim 17. See Raytheon Co. v. Roper Corp., 724 F.2d 951, 957 (Fed. Cir. 1983) (“That claims are interpreted in light of the specification does not mean that everything expressed in the specification must be read into all the claims.”). Thus, the Court adopts the following construction: software that performs pseudonymization and determines which data is sent to the data output device.
F. “automated compliance network appliance”
Plaintiff proposes the following construction: “Any network interface connection having processor, memory, and local storage and having some physical embodiment.” (Doc. 104-1 at 1.) Defendants propose the following competing construction: “A physical device (having a processor, memory and local storage), separate from the data collection terminal and compliance device driver.” (Id.)
The parties agree that the “automated compliance network appliance” contains a processor, memory, and local storage in physical form. This is supported by the plain language of claim 17(c), requiring “an automated compliance network appliance comprising a network interface connection having a processor, memory and local storage[.]” There is also support in the prosecution history. The applicant amended the claims to overcome the examiner's rejection of the claims as abstract “software per se” under 35 U.S.C. § 101. (Doc. 94-6 at 2-3.) The applicant noted that the independent claims were amended to include “a physical network interface connection” and argued that the amended claims “clearly describe a physical system . . . (i.e.: comprising a network appliance that is a USB drive or router. . . .).” (Id. at 2.) Thus, the parties only remaining dispute centers on whether the automated compliance network appliance must be separate from both the data collection terminal and compliance device driver. (Doc. 99 at 12.)
The Court finds that Plaintiff's proposed inclusion of “any network interface” within the construction would render the claim language redundant because claim 17 already requires that the claimed automated compliance network appliance comprise a network interface connection. Thus, the Court adopts the portion of Defendants' construction requiring that the automated compliance network appliance simply be a physical device. Bicon, 441 F.3d at 950 (“[C]laims are interpreted with an eye toward giving effect to all terms in the claim.”) This is in accordance with the parties' agreement.
Independent claim 17 does not address the present dispute. Independent claim 1 requires “an automated compliance network appliance in communication with the compliance device driver,” the compliance device driver being “resident in the data collection terminal.” (Doc. 94-1 at 9:55-56; 10:5-6.) The specification also teaches this. (Id. at 5:25-27.) Figures 1, 2, and 3 all show that the automated compliance network appliance, box 2, is separate from the data collection terminal and the compliance device driver. (See id. at Figs. 1-3.) Specifically, Figure 3, which shows details of the compliance device driver, illustrates two pathways from the compliance markup language parser, box 15, that the data may take: one pathway leading to an output device, box 11, and another pathway leading to the automated compliance network appliance. (Id. at Fig. 3.)
Defendants argues that the written description and figures require that the automated compliance network appliance be separate from the data collection terminal and compliance device driver. (Doc. 96 at 26-27.) Defendants point to the two pathways for data transfer in Figure 3, arguing that, “because there are two data streams, the [automated compliance network appliance] must be separate from the compliance device driver.” (Doc. 96 at 26.) The Court is unpersuaded. The specification expressly contemplates that including the output device, box 11 of Figure 3, within the data collection terminal is optional. (Doc. 94-1 at 3:51-52.) The specification does not explicitly reference where the automated compliance network appliance is housed within the system. That the invention teaches optionally including the output device within the data collection terminal, however, undermines Defendants' logic that the automated compliance network appliance must be separate based on the flow of data in Figure 3. See Gart v. Logitech, Inc., 254 F.3d 1334, (Fed. Cir. 2001) (finding a proposed construction improper where it would “add a limitation appearing in the specification and the drawings, but not appearing in the unambiguous language of the claim”).
Defendants also rely on extrinsic evidence, including the deposition testimonies of inventor Scott Hines and the applicant's prosecuting attorney Mr. Heckdon, who both testified that the figures show that the automated compliance network appliance is separate from, but in communication with, the compliance device driver. (See Doc. 96-12, 133:7-10; see also Doc. 96-6, 110:17-113:21.)
Regarding, the prosecution history, Defendants argue that the applicant “clearly treated the [automated compliance network appliance] and compliance device driver as being separate from one another by adding different physical limitations to each element[.]” (Id. at 27.) During prosecution, the applicant argued that the amended claims comprise “a network appliance that is a USB drive or router, operating together with a physical compliance device (having a device driver resident therein) . . . .” (Doc. 94-6 at 2). The amended claims require that the compliance device driver comprise “a non-transitory computer-readable medium having instructions stored therein” and the automated compliance network appliance comprise “a network interface connection having a processor, memory and local storage.” (Doc. 96-4 at 8.) Defendants' arguments fail to clearly explain how these statements during prosecution explicitly disavow embodiments of the invention where these components are not separate. Purdue Pharma L.P. v. Endo Pharmaceuticals Inc., 438 F.3d 1123, 1136 (Fed. Cir. 2006) (prosecution disclaimer requires that a patentee make “a clear and unmistakable disavowal of [claim] scope during prosecution”). As Plaintiff notes, nothing in the applicant's responses explicitly disavowed coverage of an automated compliance network appliance housed within any other component of the claimed invention. See Omega Eng 'g Inc. v. Raytek Corp., 334 F.3d 1314, 1323 (Fed. Cir. 2003).
Moreover, neither party requests that the Court construe the term “in communication with,” which is a term of art in the specification that Defendants argue definitively establishes that their construction is the correct one. The Court is not persuaded that sufficient evidence in the intrinsic record exists to limit the term as Defendants propose, nor that the extrinsic evidence is clear on this issue. The only explicit limitation on the claim term scope comes from the applicant's amendments and arguments during prosecution, limiting the automated compliance network appliance to a physical device. Accordingly, the Court adopts the following construction: a physical device (having a processor, memory and local storage).
Although the Court finds that including “having processor, memory, and local storage” is likely redundant in view of the claim language, the parties stipulate to include it in the Court's adopted construction.
G. “network interface connection”
Plaintiff proposes the following construction: “USB drive or router which has some physical embodiment.” (Doc. 104-1 at 1.) Defendant proposes the following competing construction: “A physical USB drive or physical router.” (Doc. 96 at 27.) Plaintiff concedes that the parties' proposed constructions are “not materially different.” (Doc. 99 at 13.) Given these concessions, the Court adopts Defendants proposed construction as the most concise version of the parties' agreed upon meaning. Moreover, Defendants' construction is consistent with the intrinsic record, including the specification and the prosecution history, as discussed above with respect to the term “automated compliance network appliance.” (Doc. 94-1, 3:60-64; Doc. 94-6 at 2.)
H. “local storage”
Plaintiff proposes the following construction of: “Storing data in a hardware device and/or in memory.” (Doc. 104-1 at 1) Defendant proposes that the term be given its plain and ordinary meaning. (Id.)
The parties dispute whether “local storage” is limited to a hardware storage device or whether it can encompass storing data in memory. The Court resolves the parties' dispute by adopting the plain and ordinary meaning because the parties agree that a person of ordinary skill in the art would understand local storage to cover data storage in a hardware device. Moreover, because claim 17 recites “a network interface connection having a processor, memory, and local storage,” adding memory to the definition of local storage would improperly render its inclusion in the claim redundant. Bicon, 441 F.3d at 950 (“Allowing a patentee to argue that physical structures and characteristics specifically described in a claim are merely superfluous would render the scope of the patent ambiguous. . . .”). The Court's adopted construction is supported by an absence of inventor lexicography or claim scope disavowal in the intrinsic record that would give local storage a specialized meaning in this context. See Torner, 669 F.3d at 1365 (holding that unless “a patentee sets out a definition and acts has his own lexicographer” or disavows claim scope, the plain and ordinary meaning of the term should control).
I. “pseudonymized data”
The Court adopts the following construction that the parties have agreed to: data in which some portion of the fields are replaced with one or more artificial identifiers (rather than being removed). (See Doc. 101-1 at 2.) This is supported by the definition provided in the specification. (Doc. 94-1, 5:11-16 (“As understood herein, ‘pseudonymized data' is data in which most of the identifying fields within a data record are replaced within one or more artificial identifiers, or pseudonyms, thereby rendering the data less identifying to provide for greater Data Subject privacy.”)); Philips, 415 F.3d at 1316 (Where “the specification [] reveal[s] a special definition given to a claim term by the patentee that differs from the meaning it would otherwise possess. . ., the inventor's lexicography governs.”).
J. “blockchain miners”
Plaintiff proposes the following construction: “Any blockchain network participant that participates in verifying blocks of data transactions.” (Doc. 101-1 at 2.) Defendant proposes the following competing construction: “Processors that achieve consensus in a blockchain system by solving ‘proof of complexity' mathematical problems.” (Id.)
The parties' dispute centers on whether the invention is limited to a blockchain verification system that utilizes blockchain miners to solve proof of complexity math problems.
Claim 17 mentions the term “blockchain miners” twice:
... (d) transmitting the pseudonymized data of the in-scope data in batches to blockchain miners; . . . (f) receiving verified blockchain blocks from the blockchain miners, and (g) storing the verified blockchain blocks in a blockchain derived immutable audit ledger. . . .(Doc. 94-1, 12:4-14.) The specification explains the invention's blockchain component by referring to blockchain miners as a preferred embodiment:
A first advantage of the present system is that it utilizes blockchain technology to reliably generate the immutable audit ledger. . . . The immutable audit ledger is preferably generated by utilizing a private blockchain in which blocks are added to the blockchain after they have been verified by dedicated miners. A “proof of complexity” problem solving system is used. This approach advantageously allows dedicated miners to solve the mathematical problem rapidly enough to allow the miners to achieve consensus within a desired time frame, while still providing sufficient randomness in the selection of the miner awarded the right to write the block.(Id. at 2:65-3:10 (emphasis added).) The specification further explains:
Preferably, the automated compliance network appliance transmits data to the Internet in batches such that it is pre-prepared for the blockchain miners. An advantage of sending data in batches to a group of pre-selected private miners is that the blocks can be solved (i.e.: consensus can be
achieved between the miners) and written faster (as compared to using individual data transmissions and a public blockchain approach).(Id. at 3:14-21; see also id. at 7:9-11 (“If the data was not sent in batches to the blockchain miners, the blockchain miners will be required to validate each data subject transaction one by one.”).) The specification also explains the use of a private blockchain employing a proof of complexity system as a preferred embodiment:
Preferably, the blockchain is a private blockchain that uses a proof of complexity problem/solution to write individual blocks to the chain. . . . In operation, the validated transactions are recorded by the miners on a shared distributed ledger. Specifically, whichever miner solves the proof of complexity problem first will get to write the block (after independent verification of the block by the other miners). By using a private or permissioned blockchain with a private field of miners. . ., the required proof of complexity can be reduced. This is very advantageous in reducing the time required to verify and add blocks to the chain. . . . In accordance with the present private blockchain system, miner consensus on blocks may be achieved (for example) in as little as 12 hours, and potentially less time. It is to be understood, of course, that the average time to solve and write the blocks will depend both upon the specific numerical problem the miners are assigned and the number of miners working on the problem. . . . Another advantage of using private minors [sic] is that you don't have to pay them.(Id. at 7:40-8:4.) Finally, the specification describes using “hashes” to verify transactions with respect to the same preferred embodiment:
[E]ach line in [the blockchain derived, immutable audit ledger] 5 contains . . . a hash value associated with the contents. Ledger data is hashed together and the collection of the hashes is grouped into a block. The contents of each block is then hashed with the hash of the previous block. The blocks are then validated by other blockchain miners. The hash stored in the blockchain can be compared to the hash of the transaction in the data lake to verify that the contents of the data lake have not been changed.(Id. at 8:6-17; see also id. at 9:37-42 (“A transaction bundling software system 48 is a system within the blockchain platform that prepares data blocks received from automated compliance network appliance 2 into blocks of data that can be hashed and written to the immutable ledger 5 by the blockchain miners 49.”).) Notably, the specification explicitly contemplates the use of other types of blockchain verification systems: “In accordance with the present system, proof of work (i.e.: solving computationally intense mathematical problem[s]), proof of complexity and proof of stake consensus modeling (which uses less resources) can be used.” (Id. at 7:66-8:2.)
Defendants argue that the blockchain verification model in the claimed invention must be limited to proof of complexity problems solved using computer processers. (Doc. 96 at 35.) Defendants rely on the claim language and the specification's written description and figures, arguing that only a proof of complexity model is supported because there are no details on how a proof of stake model would be integrated into the invention. (Id. at 34-36) Specifically, Defendants point to Figure 9, illustrating “the present invention in a preferred system of operation,” that includes a box for “mining HW.” (See Doc. 94-1, 3:5-6, Fig. 3.) Defendants rely on expert testimony, arguing that proof of complexity and proof of work are synonymous, while proof of stake operates by a different mechanism that does not use processors to solve complex math problems. (Doc. 96 at 36-37.) Defendants note that during Plaintiff's expert's deposition, when asked if the specification described algorithms to implement a proof of stake model, the expert stated, “I can't imagine that it would or why it would.” (Id. at 36 (quoting Doc. 96-11, 279:15-18).) At the hearing, Defendants' expert also opined that the terms “proof of complexity,” “blockchain miners,” and “hashes” are all terms of art that a person of skill in the art would recognize limit the invention to exclude proof of stake systems.
Plaintiff argues that “[n]othing in the claim language limits the ‘blockchain miners' to ‘proof of complexity.'” (Doc. 94 at 26.) Plaintiff further argued at the Markman hearing that the specification's use of “preferably” in reference to blockchain shows that a proof of complexity model is a nonlimiting preferred embodiment. Plaintiff relies on the one sentence in the specification noting that proof of work, proof of complexity, and proof of stake models can all be used with the present system. (Doc. 94 at 26; see also Doc. 94-1, 7:66-8:2.) Plaintiff also cites a Techopedia definition of “mining” to show that a person of ordinary skill in the art would not understand “mining” to be limited to “proof of complexity” models. (Doc. 94 at 27.) Defendants argue that Plaintiff's definition actually supports Defendants' position because it defines mining to require a fast computer processor and references that the term is “best known for its association with bitcoin.” (Doc. 96 at 37.) Defendant offers the Techopedia definition for “bitcoin mining,” which references a proof of work consensus model and mining “through mathematical processes.” (Id. at n.14 (citing Doc. 96-14 at 2).)
The Techopedia definition states, in relevant part:
Mining, in the context of blockchain technology, is the process of adding transactions to the large distributedpublic ledger of existing transactions, known as the blockchain. The term is best known for its association with bitcoin, though other technologies using the [blockchain] employ mining. . . . Mining involves creating a hash of a block of transactions that cannot be easily forged, protecting the integrity of the entire blockchain without the need for a central system. Mining is typically done on a dedicated computer, as it requires a fast CPU, as well as higher electricity usage and more heat generated than typical computer operations. . . .(Doc. 96-13 at 2-3.)
The Court notes that specification contemplates the use of proof of work and proof of stake iterations of blockchain verification. The Court also notes that each time the proof of complexity process is explained, the specification uses words to suggest that it is a preferred embodiment. The claim language itself, however, limits the claimed invention to the use of “blockchain miners” to verify blockchain blocks. (Doc. 94-1, 12:4-10.) The specification does not define blockchain miners, indicating that the inventor used that term in accordance with its commonly understood meaning to a person of skill in the art at the time of the invention. See Torner, 669 F.3d at 1365 (holding that unless “a patentee sets out a definition and acts has his own lexicographer” or disavows claim scope, the plain and ordinary meaning of the term should control). Defendants' expert explained that to a person of ordinary skill in the art, employing blockchain miners is specific to proof of work and proof of complexity models, while proof of stake models refer to their verification entities as “validators.” The expert further testified that because miners solve complex math problems, only computer processors could be used as miners. In other words, the expert opined that human validators would not be able to verify the data transactions contemplated in the specification. Plaintiff's expert did not refute these points. The Court is persuaded by Defendants' expert and explanation of the parties' proffered technical definitions. Phillips, 415 F.3d at 1318 (expert testimony and technical dictionary definitions can help “ensure that the court's understanding of the technical aspects of the patent is consistent with that of a person of skill in the art, or to establish that a particular term in the patent or the prior art has a particular meaning in the pertinent field”). This extrinsic evidence is consistent with the usage of “blockchain miners” in the intrinsic record. The Court finds that, in view of the extrinsic evidence, the claim language itself limits the claimed invention to those blockchain systems that utilize blockchain miners to verify blockchain transactions.
Courts must be careful not to read preferred embodiments into the claims. Comark, 156 F.3d at 1187. The Court finds that although the specification references a proof of complexity approach as a preferred embodiment, the claim's use of blockchain miners is not so limited. The specification explains that the preferred proof of complexity implementation requires the miners to solve mathematical problems and explains how such a system would operate to generate the immutable audit ledger. (See Doc. 94-1, 2:65-3:21, 7:40-8:15.) The specification also states that “proof of work (i.e.: solving computationally intense mathematical problem[s]) . . . consensus modeling” can be used. (Id. at 7:66-8:2.) Based on the specification and expert testimony, the Court finds that the inventor's use of miners would not preclude any other type of system that utilizes complex math problems for verification, such as proof of work. Moreover, a person of skill in the art would understand how to implement different approaches to blockchain validation that use miners, such as proof of work, without needing a separate detailed description. Phillips, 415 F.3d at 1323 (“[A]lthough the specification often describes very specific embodiments of the invention, we have repeatedly warned against confining the claims to those embodiments.”). On the other hand, other verification approaches that employ techniques other than complex math problems and miners, such as proof of stake models, are not sufficiently described to enable a person of ordinary skill in the art to implement the claimed invention using those methodologies. Netword, LLC v. Centraal Corp., 242 F.3d 1347, 1352 (Fed. Cir. 2001) (“Although the specification need not present every embodiment or permutation of the invention and the claims are not limited to the preferred embodiment of the invention, neither do the claims enlarge what is patented beyond what the inventor has described as the invention.”) (internal citations omitted).
Thus, the Court adopts the following construction: processors that achieve consensus in a blockchain system by solving mathematical problems.
K. “data lake”
Plaintiff proposes the following construction of “data lake”: “Any stored collection of raw or near raw, structured or unstructured data.” (Doc. 104-1 at 1.) Defendant proposes the following competing construction: “A data repository that (a) stores raw, unstructured data, and (b) is not a database.” (Id.)
The parties dispute whether the data stored in the data lake must be entirely raw and unstructured, and whether the claimed data lake encompasses a database. Plaintiff concedes that the plain language of claim 17 of the '062 Patent requires the data to be raw and unstructured but argues that this limitation should not apply to the meaning of data lake in the '833 patent claims. (Doc. 99 at 16.) Plaintiff also “acknowledges that a ‘data lake' and a ‘data base' generally refer to different things, although companies can and do use data base software as a data lake.” (Doc. 94 at 27.)
Claim 17 of the '062 Patent requires “transmitting the data input stream into a data lake as raw, unstructured and unaltered data.” (Doc. 94-1, 12:6-7.) Claim 18 of the '833 Patent is broader on its face, requiring “transmitting the data input stream into a data lake.” (Doc. 94-2, 12:29.) As previously noted, the '062 Patent and the '833 Patent share a specification, meaning that the detailed description to support both sets of claims is identical, as relevant here. The '833 Patent also expressly incorporates “the entire disclosure” of the '062 Patent “by reference in its entirety for all purposes.” (Doc. 94-2 at 1:9-13.) The shared specification does not reference “raw, unstructured data” or otherwise define “data lake.” During prosecution of the '062 Patent, however, the applicant characterized the data lake as different from a database to overcome the examiner's rejection of the claims as abstract under 35 U.S.C. § 101. The applicant explained that:
the presently claimed system stores data in a data lake. A data lake is fundamentally different from a simple database. A database is a very structured system of storing data records. In contrast, a data lake is basically a pool of raw, unstructured data. Data is not prepared, classified, structured, or otherwise pulled apart or otherwise sorted out in a data lake. Instead, data is simply dumped into a data lake in its raw form.(Doc. 96-4 at 12-13 (emphasis in original).) The applicant further relies on the use of a data lake to differentiate the invention from other systems:
The presently claimed computer architecture combines a data lake together with a blockchain generated record of the data in the data lake in a single unified system. This is fundamentally different from existing blockchain systems that use simple databases. Data in a database can easily be changed, and it is often impossible to reliably tell if the data in the database has been changed. The present computer architecture solves this problem by instead using a data lake (not a database). The present computer architecture simply “tosses all the raw data into the data lake” so to speak. As such, the data in the data lake can't easily be changed. Also, simply tossing the data into a data lake can be done very quickly. As such, the present system's use of a data lake increases the overall speed at which the system operates (as compared to existing systems that use old fashioned databases).
Importantly, as the data is being tossed into the data lake, the present system simultaneously generates a legally auditable record of the data in the data lake. The advantage of the present approach (i.e.: simply tossing all of the raw data into a data lake while simultaneously generating an auditable record of the
integrity of this data - all within a single computer architecture) has not been attempted prior to the present invention. The present novel architecture provides substantially increased speed, greatly increased security while using far less computer resources as compared to existing computer systems.(Id. at 13 (emphasis in original).) This explanation accompanied an amendment to the independent claims of the '062 Patent adding “as raw, unstructured and unaltered data” to the limitation requiring the data input stream to be transmitted into a data lake. (Id. at 9.)
“The doctrine of prosecution disclaimer is well established in Supreme Court precedent, precluding patentees from recapturing through claim interpretation specific meanings disclaimed during prosecution.” Omega, 334 F.3d at 1323. Generally, the Court begins with a heavy presumption that claim terms carry their full ordinary and customary meaning. Id. But, “a patentee may limit the meaning of a claim term by making a clear and unmistakable disavowal of scope during prosecution.” Purdue, 438 F.3d at 1136. Disavowal may occur, for instance, when the patentee “explicitly characterizes an aspect of his invention in a specific manner to overcome prior art.” Id. The patentee must have taken a position before the USPTO that would lead a competitor to believe that the applicant had disavowed coverage of the relevant subject matter. Omega, at 1325 (citing Schwing GmbH v. Putzmeister Aktiengesellschaft, 305 F.3d 1318, 1324-25 (Fed. Cir. 2002)). If a patentee “has unequivocally disavowed a certain meaning to obtain his patent, the doctrine of prosecution disclaimer attaches and narrows the ordinary meaning of the claim congruent with the scope of the surrender.” Id. at 1324.
Although theparties argue that the similar concept of prosecution history estoppel is at issue here, the Court notes that the proper analysis at the claim construction stage is under the doctrine of prosecution disclaimer. Omega, 334 F.3d at 1326 n.1 (Fed. Cir. 2003).
The specification only contemplates that the data stored in the data lake be “unaltered,” not that it be raw or unstructured. (Doc. 94-1, 8:5-6.) Plaintiff points to Figure 7 for support, arguing that it “clearly identifies] an example of structured data submitted to the data lake” because it “shows a common point of sale transaction that in its raw form is structured into a ‘header section' and an itemized list of data structured into columns.” (Doc. 94 at 28.) After reviewing the prosecution history, however, the Court finds that the applicant's arguments to the USPTO would lead a competitor to believe that that they were disavowing coverage of a database with “prepared, classified, structured, or otherwise pulled apart or otherwise sorted out” data. The applicant's statements, emphasizing the advantages of using a data lake over a data base, limit claim 17's use of “data lake” to “a pool of raw, unstructured data” and “not a database.” (Doc. 96-4 at 12-13.) The prosecution history shows that the applicant narrowed the scope of “data lake” to overcome the examiner's rejection of the claims as an unpatentable abstract idea. (Doc. 96-3 at 5.) Based on the intrinsic record, the Court finds that prosecution disclaimer clearly applies to the '062 Patent.
The Court also finds that the disclaimer applies to the '833 Patent's use of the term “data lake.” “[T]he prosecution history of one patent is relevant to an understanding of the scope of a common term in a second patent stemming from the same parent application.” Microsoft Corp. v. Multi-Tech Systems, Inc., 357 F.3d 1340, 1349 (Fed. Cir. 2004). “[T]he prosecution of one claim term in a parent application will generally not limit different claim language in a continuation application,” Invitrogen Corp. v. Clontech labs., Inc., 429 F.3d 1052, 1078 (Fed. Cir. 2005), but, “[a] disclaimer in the parent application [can] carr[y] forward into the construction of the same claim term in the child,” Cordis Corp. v. Boston Scientific Corp., 658 F.3d 1347, 1356 n.5 (Fed. Cir. 2011). See also Omega, 334 F.3d at 1333 (“As long as the same claim limitation is at issue, prosecution disclaimer made on the same limitation in an ancestor application will attach.”). The relevant test is whether “the purported disclaimers are directed to specific claim terms that have been omitted or materially altered in subsequent applications (rather than to the invention itself).” Saunders Grp., Inc. v. Comfortrac, Inc., 492 F.3d 1326, 1333 (Fed. Cir. 2007). If so, the prior prosecution disclaimer does not apply to limit the claimed invention in the later patent where those same claim terms are not used. Id. When the same claim terms are used, it is possible to explicitly rescind a prosecution disclaimer in an earlier patent such that a continuation patent is not bound by the claim scope limitation, however. See Hakim v. Cannon Avent Grp., PLC, 479 F.3d 1313, 1318 (Fed. Cir. 2007). To effectively rescind a prior disclaimer, the applicant “must be sufficiently clear to inform the examiner that the previous disclaimer . . . may need to be re-visited.” Id.
Neither party specifically addresses the relevant tests for prosecution disclaimer and recission with respect to continuation applications. At the Markman hearing, Defendants argued that courts must interpret common terms in a patent consistently across all related patents. Plaintiff argued that the '833 Patent's use of “data lake” in independent claim 18 is “deliberately” “much broader” because it does not include the “as raw, unstructured data” limitation added during prosecution of the '062 Patent. (Doc. 99 at 17.) The parties both rely on Microsoft for support. 357 F.3d 1340. In Microsoft, the Federal Circuit affirmed a district court's construction limiting claim terms in three related patents based on the applicant's statements during prosecution of one of the patents. Id. at 1348-1350. The court found that the applicant's statements made during prosecution, were “relevant to an understanding of the common disclosure” in the shared specification because the applicant's statement was a representation of its own understanding of the inventions disclosed in all three patents.” Id. at 1350.
In so doing, the court refused to apply some of the applicant's statements to all of the asserted patents “because they refer[red] more specifically to the references cited against the claims of [one] patent only.” Id. at 1349 n.5.
Here, the Court finds that the '833 Patent's use of “data lake” must be limited by the applicant's statements during prosecution of the '062 Patent. As discussed above, the applicant discussed the advantages of the invention's data lake for three paragraphs. (Doc. 96-4 at 12-13.) The applicant clearly indicated that the data lake was important to the overall invention and provided specific advantages over conventional computer systems. (Id.) The Court finds that these statements were not limited to the “raw, unstructured data” amendment, but were instead intended to convince the examiner that the entire claimed invention was patentable and not abstract. (Id. at 11-13); see Microsoft, 357 F.3d at 1350 (“We take the patentee at its word and will not construe the scope of the [continuation] patent's claims more broadly than the patentee itself clearly envisioned.”).
For both the Patents-in-Suit, the claims were rejected under 35 U.S.C. § 101 as directed to unpatentable subject matter. The applicant's prosecution disclaimer is thus not specific to the examiner's rejection of the '062 Patent. Indeed, the '833 Patent's own prosecution history belies Plaintiff's arguments to the contrary. The applicant made the following remarks when faced with a similar rejection during prosecution of the '833 patent: “The Examiner rejected the pending claims as being directed to non-statutory subject matter. Suitable amendment has been made to overcome these rejections (substantially paralleling similar amendments that were made in the parent case (now issued U.S. Patent 10,304,062)).” (Doc. 96-5 at 8.) The amendments to the '833 Patent claims did not include the “as raw, unstructured data” limitation, but both independent claim 17 and 18 require a “data lake.” There is no evidence before the Court that the applicant sought to recapture a broader scope for data lake in the '833 Patent claims. See Microsoft, 357 F.3d at 1350 (“Any statement of the patentee in the prosecution of a related application as to the scope of the invention would be relevant to claim construction, and the relevance of the statement made in this instance is enhanced by the fact that it was made in an official proceeding in which the patentee had every incentive to exercise care in characterizing the scope of its invention.”). Plaintiff fails to point to any portion of the '83 3 Patent's prosecution history where the applicant explicitly rescinded the prior disclaimer or otherwise “inform[ed] the examiner that the previous disclaimer . . . may need to be revisited.” See Hakim, 479 F.3d at 1318.
Accordingly, the Court adopts Defendants' proposed construction for both Patents-in-Suit: a data repository that stores raw, unstructured data, and is not a database.
L. “(e) ..., while simultaneously; (f) ..., and (g) ...;”
Plaintiff proposes the following construction: “Transmitting, receiving, and storing as described, in a manner satisfied by the same values.” (Doc. 101-1 at 2.) Conversely, Defendants argue that “[s]teps (e), (f) and (g) must all be performed at the same time.” (Id.) Plaintiff asserts that “simultaneously,” as used in the patent, is a term of art in computer science, while Defendants seek to rely on the conventional definition of the term.
Claim 17 provides, in part:
(e) transmitting the data input stream into a data lake as raw, unstructured and unaltered data, while simultaneously;
(f) receiving verified blockchain blocks from the blockchain miners, and
(g) storing the verified blockchain blocks in a blockchain derived immutable audit ledger, wherein the blockchain derived immutable audit ledger certifies that the data stored in the data lake is correct and unaltered. . . .(Doc. 94-1, 12:6-14.) Simultaneously does not appear in the specification. It was added during prosecution to overcome an examiner's rejection under 35 U.S.C. §§ 101, 102, and 103. (See Doc. 96-4.)
During prosecution, “the Examiner requested . . . evidence of ‘something more' than a conventional computer system” and that the applicant “explain how the present invention solves [] existing problems.” (Doc. 96-4 at 11.) In response, the applicant discussed the problem with existing solutions:
[P]rior to the present invention, a single computer architecture solution that simultaneously stored all of the data, quickly verified the integrity of all of the data (i.e.: could produce a legal audit trail for regulators that proved that the data had not been altered), yet also permit both data subjects and 3rd parties to access the data, while still automatically protecting the data privacy rights of the data subjects from the 3rd parties had not been achieved. Instead, existing computer “solutions” were both slow in operation and vulnerable to hacker attacks that could compromise data privacy.(Id. at 12 (emphasis in original).) The applicant then explained why the present invention solved those problems:
Importantly, as the data is being tossed into the data lake, the present system simultaneously generates a legally auditable record of the data in the data lake. The advantage of the present approach (i.e.: simply tossing all of the raw data into a data lake while simultaneously generating an auditable record of the integrity of this data - all within a single computer architecture)
has not been attempted prior to the present invention. The present novel architecture provides substantially increased speed, greatly increased security while using far less computer resources as compared to existing computer systems.(Id. at 13 (emphasis in original).)
Plaintiff offers expert testimony and a secondary dictionary definition to argue that persons of skill in the art of computer science use the term simultaneously differently than its commonly understood meaning. (Doc. 94 at 31.) Specifically, Plaintiff's expert testified at the hearing that time is not a relevant factor in “simultaneous sequences” in computer science. As an example, Plaintiff's expert explained that, to a person of ordinary skill in the art, “simultaneous equations” means that two or more equations are necessary to solve a math problem, but they are not necessarily solved at the same time. Defendants, on the other hand, offer a primary definition for the word simultaneously arguing that the term refers to events happening at the same time. (Doc. 96 at 41.)
The Court finds that no construction is necessary in this case because the plain and ordinary meaning of the term is clear. “Simultaneously” is straightforward and readily understandable by lay juries, so it does not require further clarification. See Philips, 415 F.3d at 1314. Further, the applicant's statements during prosecution regarding the advantage of speed over other inventions are directly related to the term “simultaneously” being added to the claims to secure a patent. (See Doc. 96-4 at 12-13.) These statements provide support that the applicant intended “simultaneously” to represent its commonly understood meaning related to events that occur at or near the same time. Phillips, 415 F.3d at 1317 (“[T]he prosecution history can often inform the meaning of the claim language by demonstrating how the inventor understood the invention. . . .”) (citing Vitronics, 90 F.3d at 1582-83).
Plaintiff fails to explain how its preferred construction, relying on an unsupported term of art, can be reconciled with the speed advantages touted during prosecution. Plaintiff's expert also relied on a definition for “simultaneous equations” at the hearing, which is a phrase not found in the intrinsic record. At bottom, Plaintiff's dictionary definitions and expert testimony are unsupported extrinsic evidence. Philips, 415 F.3d at 1318 (“[C]onclusory, unsupported assertions by experts as to the definition of a claim term are not useful to a court.”). As such, the extrinsic evidence is “unlikely to result in a reliable interpretation of patent claim scope unless considered in the context of the intrinsic evidence.” Id. at 1318-19. Moreover, given that the intrinsic record supports the common usage of the word simultaneously, Defendants' proposed construction is unnecessary. Thus, the Court adopts the plain and ordinary meaning of the term “simultaneously,” as used in claim 17.
M. “private blockchain”
Plaintiff proposes the following construction: “A distributed transaction ledger controlled by a central authority.” (Doc. 101-1 at 2.) Defendant proposes the following competing construction: “A blockchain system requiring a proof of complexity solution, where only preselected members can record transactions to the blockchain.” (Id.)
Dependent claim 19 recites “[t]he method of claim 17, further comprising: utilizing a private blockchain to verify the data in the immutable audit ledger.” (Doc. 94-1, 12:24-26.) The specification describes using “a private or permissioned blockchain with a private field of miners (i.e.: a blockchain system in which anyone can read, but only preselected members can record transactions to the blockchain).” (Id. at 7:52-55.)
Additionally, the specification uses the term “private” in four other contexts. (See id. at 1:31-34 (“‘[P]ersonal data' is any information relating to an individual, whether it relates to his or her private, professional, or public life.”); id. at 3:41-43 (“[A]uditors can view the compliance data without requiring access to any of the private information or systems. . . .”); id. at 4:16-22 (“[T]he present system can . . . still shield[] private information from public stakeholders.”); id. at 6:41-44 (“[The system] should provide a secure bridge of communication between the private network . . . and the public Internet.”).) In each instance, the specification clearly uses the term “private” to mean not public, which comports with the common usage of the word. Moreover, the parties do not appear to dispute the meaning of “blockchain” itself, which is a term of art readily understood by a person of ordinary skill in the art. Such a person would presumably understand the difference between a public blockchain and a private blockchain. Innova/Pure Water, Inc. v. Safari Water Filtration Systems, Inc., 381 F.3d 1111, 1116 (Fed. Cir. 2004) (“A court construing a patent claim seeks to accord a claim the meaning it would have to a person of ordinary skill in the art at the time of the invention.”).
As discussed above with respect to “blockchain miners,” the Court does not find support in the intrinsic record to limit the invention to blockchain systems that only utilize proof of complexity solutions. For those same reasons, the Court rejects Defendants' proposed construction requiring “a blockchain system requiring a proof of complexity solution.” Moreover, claim 19, where private blockchain appears, is dependent on claim 17. It follows, then, that the private blockchain of claim 19 already includes the limitations to claim 17 imposed via this Court's construction of “blockchain miners” above. See 35 U.S.C. § 112(d) (a dependent claim does not recite the elements of the referenced independent claim but is construed to incorporate all the limitations of that claim).
Thus, the Court adopts the plain and ordinary meaning of the term “private blockchain.”
IV. CONCLUSION
For the foregoing reasons, the Court construes the disputed claim terms as set forth in the table above in Part III, supra.