Sunstone Information Defense, Inc. v. F5, Inc.

• Court: District Court, N.D. California
• Decided: March 30, 2023
• Docket: 4:21-cv-09529
• Status: Unknown

Opinion

1 2 3 UNITED STATES DISTRICT COURT 4 NORTHERN DISTRICT OF CALIFORNIA 5 6 SUNSTONE INFORMATION DEFENSE, INC., Case No. 21-cv-09529-YGR

7 Plaintiff, CLAIM CONSTRUCTION ORDER v. 8 Re: Dkt. No. 120 9 F5, INC., Defendant. 10

11 On January 22, 2021, plaintiff Sunstone Information Defense, Inc. (“Sunstone”) brought 12 this patent infringement action against F5 and Capital One Financial Corporation (“Capital One”). 13 (Dkt. No. 1.) On April 4, 2022, the case against Capital One was stayed. (Dkt. No. 91.) 14 Sunstone accuses defendant F5 of infringing several cybersecurity-related software patents, 15 including U.S. Patent Nos. 9,122,870 (“’870 Patent” or “’870”); 10,230,7591; and 10,958,682 16 (“’682 Patent” or “’682”). These patents claim technology related to preventing malicious attacks 17 or exposure of information by autonomous programs, i.e., “bots.” The Accused Products are 18 “various computer security products and services[.]” (First Amended Compl. (“FAC”) ¶ 6, Dkt. 19 No. 89.) 20 I. BACKGROUND 21 A. The ’870 22 The title of the ’870 Patent is “Methods and Apparatus for Validating Communications in 23 an Open Architecture System.” The ’870 Patent discloses ways to “validate communications in an 24 open architecture system and,[]” predict responses “to identify malicious applications attempting 25 to interfere with communications between servers and the client devices.” (’870 Patent at 3:56- 26 61.) 27 B. The ’682 1 The title of the ’682 Patent is “Methods and Apparatus for Varying Soft Information 2 Related to the Display of Hard Information.” The ’682 Patent discloses ways to “validate 3 communications in an open architecture system and,[]” predict responses “to identify malicious 4 applications attempting to interfere with communications between servers and the client devices.” 5 (’682 Patent at 3:66-4:4.) 6 II. LEGAL STANDARD 7 Claim construction is a question of law for the court. Markman v. Westview Instruments, 8 Inc., 517 U.S. 370, 384 (1996). “The purpose of claim construction is to determine the meaning 9 and scope of the patent claims asserted to be infringed.” O2 Micro Int’l Ltd. v. Beyond Innovation 10 Tech. Co., 521 F.3d 1351, 1360 (Fed. Cir. 2008) (internal citations and quotations omitted). 11 “When the parties raise an actual dispute regarding the proper scope of the[] claims, the court, not 12 the jury, must resolve that dispute.” Id. (internal citation omitted). However, claim construction 13 need only “resolve the” controversy (id. at 1361); it is not “an obligatory exercise in redundancy” 14 where no dispute exists. U.S. Surgical Corp. v. Ethicon, Inc., 103 F.3d 1554, 1568 (Fed. Cir. 15 1997). 16 Claim terms are generally given the “ordinary and customary meaning” that they would 17 have to a person of ordinary skill in the art at the time of the invention. Phillips v. AWH Corp., 18 415 F.3d 1303, 1312-13 (Fed. Cir. 2005) (en banc) (internal citations and quotations omitted). 19 The ordinary and customary meaning is not the meaning of the claim term in the abstract. Id. at 20 1321. Rather, it is the “meaning to the ordinary artisan after reading the entire patent.” Id.; see 21 also Trs. of Columbia U. v. Symantec Corp., 811 F.3d 1359, 1364 (Fed. Cir. 2016) (“The only 22 meaning that matters in claim construction is the meaning in the context of the patent.”) (internal 23 citations omitted). 24 To determine the ordinary meaning, the court examines the claims, specification, and 25 prosecution history of the patent, which form the “intrinsic evidence” for claim construction. 26 Phillips, 415 F.3d at 1317; Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 27 1996). “[T]he context in which a term is used in the asserted claim can be highly instructive.” 1 Phillips, 415 F.3d at 1314. Additionally, “[d]ifferences among claims can also be a useful guide 2 in understanding the meaning of particular claim terms.” Id. (internal citation omitted). However, 3 a person of ordinary skill in the art is “deemed to read the claim term not only in the context of the 4 particular claim in which the disputed term appears, but in the context of the entire patent, 5 including the specification.” Id. at 1313. The specification “is always highly relevant to the claim 6 construction analysis” and usually “dispositive.” Id. at 1315 (quoting Vitronics, 90 F.3d at 1582). 7 Nevertheless, it is improper to limit the claimed invention to the preferred embodiments or to 8 import limitations from the specification unless the patentee has demonstrated a clear intent to 9 limit claim scope. Martek Biosci. Corp. v. Nutrinova, Inc., 579 F.3d 1363, 1380-81 (Fed. Cir. 10 2009). 11 In addition to the claims and specification, the prosecution history may be used “to 12 provide[] evidence of how the PTO and the inventor understood the patent.” Phillips, 415 F.3d. at 13 1317 (internal citation omitted). “Any explanation, elaboration, or qualification presented by the 14 inventor during patent examination is relevant, for the role of claim construction is to ‘capture the 15 scope of the actual invention’ that is disclosed, described and patented.” Fenner Inv., Ltd. v. 16 Cellco P’ship, 778 F.3d 1320, 1323 (Fed. Cir. 2015) (internal citation omitted). Finally, a court 17 may consider extrinsic evidence—such as dictionaries, inventor testimony, and expert opinion—if 18 it is helpful. Phillips, 415 F.3d at 1319. However, extrinsic evidence “is unlikely to result in a 19 reliable interpretation of patent claim scope unless considered in the context of the intrinsic 20 evidence.” Id. 21 There are two exceptions to the ordinary meaning construction: “1) when a patentee sets 22 out a definition and acts as his own lexicographer,” and “2) when the patentee disavows the full 23 scope of a claim term either in the specification or during prosecution.” Thorner v. Sony Comp. 24 Entm’t Am. LLC, 669 F.3d 1362, 1365 (Fed. Cir. 2012) (citing Vitronics, 90 F.3d at 1580). To act 25 as a lexicographer, the patentee “must ‘clearly set forth a definition of the disputed claim term’ 26 other than its plain and ordinary meaning.” Id. (quoting CCS Fitness, Inc. v. Brunswick Corp., 27 288 F.3d 1359, 1366 (Fed. Cir. 2002)). To disavow claim scope, the specification or prosecution 1 the language of the claims “might be considered broad enough to encompass the feature in 2 question.” Id. at 1366 (quoting SciMed Life Sys., Inc. v. Adv. Cardiovascular Sys., Inc., 242 F.3d 3 1337, 1341 (Fed. Cir. 2001)). 4 III. CLAIM CONSTRUCTION 5 A. Agreed-to Constructions 6 The parties propose five terms for construction. (See Dkt. No. 129-1, Joint Claim 7 Construction and Pre-Hearing Statement, Ex. A.) The parties agreed to the following 8 constructions (see Dkt. No. 129, Joint Claim Construction and Pre-Hearing Statement): 9 Claim Term Agreed Construction 10 ’870 Patent, Claim 11 “estimating the locations of rendered Plain and ordinary 11 features and functions displayed by meaning the client device includes estimating 12 locations of features and functions that are hidden from display by the 13 client device” ’870 Patent, Claim 7 “Hard information” “transactional text 14 and/or data displayed 15 by a client device” ’682 Patent, Claim 7 “estimating the at least one location Plain and ordinary 16 of the at least one rendered feature or meaning function displayed by the client 17 device includes estimating at least one location of at least one rendered 18 feature or function that is hidden 19 from display by the client device” 20 21 B. Considering Indefiniteness at Claim Construction 22 For purposes of this particular Markman order, the Court first considers the 23 appropriateness of deciding questions of indefiniteness at this stage. Markman, 517 U.S. 370, 384 24 (1996). Defendant argues that, under TVnGO Ltd. (BVI) v. LG Elecs. Inc., 861 F. App’x 453, 457 25 (Fed. Cir. 2021), consideration of indefiniteness at this stage is appropriate. Sunstone rightly 26 points out that TVnGO is non-precedential. Sunstone also attempts to distinguish the facts of 27 TVnGO. However, courts in this District have opted to consider challenges to definiteness at 1 2014 WL 1569544, at *13 (N.D. Cal. Apr. 18, 2014) (“the Federal Circuit has made clear that 2 indefiniteness is a legal question that district courts may decide prior to trial”) (internal quotation 3 omitted); Prolifiq Software Inc. v. Veeva Sys. Inc., No. C 13-03644 SI, 2014 WL 3870016, at *8 4 (N.D. Cal. Aug. 6, 2014) (finding the term “differently versioned” indefinite and the claims 5 containing it invalid); See Zoho Corp. v. Sentius Int'l, LLC, No. 4:19-CV-0001-YGR, 2020 WL 6 3128910, at *16 (N.D. Cal. June 12, 2020) (finding “compiling the source material image” 7 indefinite at Markman hearing) (internal quotations omitted); VTT Tech. Rsch. Ctr. of Finland Ltd. 8 v. SiTime Corp., No. 4:19-CV-1174-YGR, 2020 WL 4193374, at *13 (N.D. Cal. July 21, 2020), 9 aff'd, 849 F. App'x 928 (Fed. Cir. 2021) (finding the term “drive or sense means” indefinite). 10 Sunstone’s authorities to the contrary are unpersuasive. First, Lifescan Scotland is 11 distinguishable because construction of the disputed claim terms here can be resolved with only 12 the specification. See Lifescan Scotland, Ltd. v. Shasta Techs., LLC, No. 11-CV-04494-WHO, 13 2014 WL 11206411, at *3 (N.D. Cal. Nov. 10, 2014) (specifically reasoning that where expert 14 testimony is relevant, delaying the indefiniteness determination is appropriate). Moreover, the 15 Lifescan court distinguished its situation from the one in Prolifiq Software, where the court found 16 that an indefiniteness determination was not “premature” without expert testimony because the 17 term itself could be understood only subjectively. Id. Intergraph Hardware involved a term to 18 which section 112, paragraph 6 applied, where the parties disagreed regarding the function recited 19 in the claim. Intergraph Hardware Techs. Co. v. Toshiba Corp., 508 F. Supp. 2d 752, 773 n.3 20 (N.D. Cal. 2007) (declining to consider indefiniteness at the Markman stage). That is not the case 21 here, and the court there did not provide reasoning for its refusal to consider indefiniteness at that 22 stage. While courts do frequently defer invalidity determinations until after claim construction, 23 the Federal Circuit has not precluded such determinations. See DuraSystems Barriers Inc. v. Van- 24 Packer Co., No. 1:19-cv-01388-SLD-JEH, 2021 WL 4037826, at *5 (C.D. Ill. Sept. 3, 2021). 25 Sunstone’s argument that a finding of indefiniteness should be postponed until after the 26 close of discovery would be obviated by the Court making only preliminary findings at this stage. 27 The other arguments Sunstone advances in favor of postponing a finding of indefiniteness are 1 Dkt. No. 124, (“Reply”) at 3.) Second, the IBM court’s constructions are not binding on this 2 Court. See Aircraft Tech. Publishers v. Avantext, Inc., No. C 07-4154 SBA, 2009 WL 3817944, at 3 *3 (N.D. Cal. Nov. 10, 2009) (“While uniformity of treatment of a given patent is important, one 4 district court is not bound to automatically accept the claim construction of another district court. 5 Rather, this Court has an independent obligation to construe the claims in dispute, and to render its 6 own independent claim construction.”) (internal citations and quotations omitted). 7 C. Disputed Terms in the ’870 Patent and ’682 Patent 8 For the readers’ convenience, the text of the independent claims of the ’870 containing the 9 term “transactional information” are contained in Attachment A hereto. 10 1. “transactional information” 11 Sunstone Construction F5 Construction Court’s 12 Construction 13 Plain and ordinary meaning Indefinite Indefinite With respect to the term “transactional information,” the parties dispute whether “hard 14 information” is a subset of “transactional information.” Sunstone, and its expert, argue that it is. 15 (See Ex. C to Pl.’s Initial Br. (“Medvidovic Decl.”), Dkt. 120-4 ¶ 49 (“Thus, a POSA would 16 understand from the specification that ‘hard information’ is a subset of ‘transactional 17 information[.]’”).) F5 replies that such an understanding would render the specification internally 18 inconsistent. (See Dkt. No. 123 (“Def. Resp. Br.”) at 5 (arguing that the specification suggests 19 “transactional information” is synonymous with “hard information” and the prosecution history 20 provides no clarity).) 21 This dispute is resolved by the intrinsic evidence. All agree that the term “information” is 22 well-understood. However, the effect of Sunstone’s position creates confusion as to the meaning 23 of “transactional information” relative to any other kind of “information.” Nothing set forth by 24 Sunstone’s expert, or in its other extrinsic evidence, can overcome a position that is inconsistent 25 with the specification. The specification itself does not provide clarity relative to Sunstone’s 26 position, that is, it does not explain how “transactional information” and “hard information” 27 1 Sunstone points to various parts of the specification that discuss information sent with an 2 “intent” or for a “purpose.” (See Dkt. No. 120 (“Pl. Initial Br.”), at 7.) Again, Sunstone does not 3 explain how or why the Court would incorporate the “business purpose” of information or the 4 “authentic intent” of the entity sending the information into the construction of this term. To that 5 end, Sunstone’s proposed alternative construction, “data to be transmitted between a server and a 6 client to achieve the purpose of the connection[,]” is equally unhelpful. (Id.) It is not obvious 7 why any information that is not essential to “achieving the purpose” of the connection would be 8 sent. Additionally, the effect of this position would result in an open-ended construction lacking 9 any discernible structure. Moreover, Sunstone’s attempt to distinguish “purposive” information 10 from any other type of information is simply too ambiguous to inform a POSA of the scope of this 11 term, i.e., what the bounds of this kind of information are. 12 However, F5’s contention that the shared specification of the asserted patents does not use 13 the term “transactional information” is not entirely correct. The term appears in the Abstract, as 14 well as in the claims themselves. Tellingly, Sunstone’s own expert opines that “‘hard 15 information’ is a subset of ‘transactional information,’” and that “[a] POSA would understand that 16 not all data sent between a client and server which is necessary to achieve the purpose of a 17 transaction would actually be displayed to a user.” (Medvidovic Decl. ¶ 49.) Regardless of 18 whether “transactional information” is the same as “hard information” or the two overlap in some 19 way, the specification does not clarify the bounds of the term. 20 Sunstone’s argument that “transactional information” is “information sent for some 21 purpose” is completely devoid of meaning. Processors do not have intent, and Sunstone points to 22 no cases showing application of a Court’s discernment regarding the user’s intent to the thing 23 executing or carrying out the claim itself. 24 While the parties have agreed on a construction of “hard information,” setting forth that 25 this known thing is a subset of a larger category does not define the contours of that larger 26 category. See Cap. Sec. Sys., Inc. v. NCR Corp., 725 F. App'x 952, 958 (Fed. Cir. 2018) (finding 27 the term “transactional operator” indefinite where it was unknown from the passage in the 1 microcomputer[], the keyboard[], and the display[], or a subset thereof”). Moreover, the 2 understanding that some information necessary to achieve a particular purpose need not be 3 displayed to a user of the device does no work to define what that non-displayed information is 4 either. Sunstone’s representations at oral argument do not eliminate the Court’s concerns. F5 5 argues that the specification makes apparent that “rendered information [] is displayed [] while the 6 un-rendered information [] is not displayed[.]” (’870 Patent at 22:9-11.) Thus, any attempt to 7 distinguish “transactional information” from “hard information” by the fact that the former need 8 not be displayed is refuted by the fact that the claims recite rendered transactional information. 9 (See, e.g., ’870 Patent at cl. 1 (“determining a prediction of a response message from the client 10 device based on i) the selected transactional information,” and “ii) how the client device is 11 configured to render the transactional information”).) While it is at least conceivable that 12 “transactional information” need not be displayed, if “hard information” is only “transactional 13 information” that is displayed, and all asserted claims recite “transactional information” that is 14 rendered and displayed, it is not discernible how this differs from “hard information.” F5 argues 15 that, based on the specification, a POSA would in fact understand “hard information” and 16 “transactional information” to be the same, premised on the idea that “text, data, pictures, and/or 17 images” pretty well capture the term “information.” (F5 Resp. Br. at 6 (quoting ’870 Patent at 18 6:21-24).) F5 makes a compelling case that, at the very least, a POSA would not understand the 19 difference between “hard information” and “transactional information.” 20 Both sides discuss claim differentiation, but this doctrine does not save Sunstone. Neither 21 party makes very compelling claim differentiation arguments. F5 makes claim differentiation 22 arguments only in i) arguing that different terms must “have different meanings[]” (see id. at 5) 23 and ii) arguing against Sunstone’s argument that claim differentiation does not itself render the 24 claims invalid where the specification provides support for the disputed terms (see Pl. Initial Br. at 25 9; Def. Resp. Br. at 8). While F5’s argument is valid, it rests on the premise that the 26 specification’s suggestion that “hard information” is synonymous with “transactional information” 27 establishes the truth of that suggestion. 1 data, pictures, and/or images” is ambiguous, but the Court cannot conclude more from this 2 ambiguity. Sunstone’s argument that, even if claim differentiation rendered the scope of different 3 claims identical, the specification controls, does not help its case either because the specification 4 does not unambiguously define the disputed term here. 5 In terms of the file history, Sunstone’s argument is more persuasive. F5 is incorrect that 6 the file history adds to the confusion surrounding the term “transactional information,” but it does 7 not delineate the bounds of the term either. The file history provides:

8 The server determines a prediction that the user will only see the ‘banana’ data field next to text requesting a password and will not see 9 the hidden ‘password’ data field (one example of predicted response information based on how the client device renders the transaction 10 information). The server also predicts that the user will not enter data into the hidden ‘password’ data field but will enter data into the 11 visible ‘banana’ data field (an example of predicted response information associated with the transactional information that is 12 expected to be provided by a user of the client device). 13 (Dkt. No. 120013, Ex. L to Pl. Initial Br. at -0000464-0000465.) F5 and its expert assert that a 14 POSA would conclude “that a data field is transactional information[.]” Resp. Br. at 10 (citing 15 Dkt. No. 120-5, Ex. D to Pl. Initial Br. (“Jakobsson Decl.”) ¶ 47.) However, the file history does 16 not support that argument. Rather, as Sunstone asserts, the file history supports the idea that it is 17 reasonable to infer that a “data field” can relate to “transactional information” or “presentation 18 information.” Ultimately, and again, the file history provides no clarity regarding the outer 19 bounds of these terms. Nothing about a “data field” being able to relate to either of these two 20 terms would solidify a POSA’s understanding of what “transactional information” is. 21 Similarly, Sunstone’s authorities in favor of a given structure satisfying more than one 22 claim limitation are inapposite where the scope of the claim limitation itself is unknown. 23 Moreover, while the reasoning in Powell v. Home Depot U.S.A., Inc., depended on claims being 24 construed in such a way that they required the same structure, that disposition was about 25 infringement. 663 F.3d 1221, 1232 (Fed. Cir. 2011). As such, it is not relevant that a “data field” 26 can have aspects or elements related to various kinds of information. 27 2. “presentation information” Sunstone Construction F5 Construction Court’s 1 Construction 2 Plain and ordinary meaning Indefinite Indefinite The parties dispute the construction of “presentation information.” Sunstone argues that 3 presentation information is a set of information that includes the subset of “soft information.” (Pl. 4 Initial Br. at 11-12 (quoting ’870 Patent at 6:43-45; ’682 Patent at 6:57-58) (supplied emphasis 5 omitted).) The parties agreed that “soft information” is “presentation information describing how 6 hard information is to be displayed by a client device.” (Id. at 12; Def. Resp. Br. at 16.) 7 Furthermore, the parties agreed, the same week as the hearing, that “hard information” is 8 “transactional text and/or data displayed by a client device.” (Joint Claim Construction and Pre- 9 Hearing Statement at 2.) 10 The parties make largely similar arguments regarding “presentation information” as they 11 do for “transactional information.”2 12 F5 argues that the specification implies that “soft information” is a subset of “presentation 13 information” without defining “presentation information” itself. (Def. Resp. Br. at 12.) If true, 14 this would render the bounds of the term ill-defined. That said, if the Court were to accept 15 Sunstone’s alternative construction, the term would be no more readily understood. Sunstone sets 16 forth the alternative construction “information specifying how transactional information is to be 17 displayed” (Pl. Initial Br. at 11), but the Court has already found that “transactional information” 18 is indefinite. Defining the term “presentation information” by another indefinite term is not 19 helpful here. F5 is, furthermore, correct that Sunstone’s alternative construction would make 20 some of the claims circular. 21 F5’s authorities are generally on point. In Harris Corp., the court rejected the patentee’s 22 proposed construction because it would have rendered the asserted claim circular. 114 F.3d 1149, 23 1152 (Fed. Cir. 1997). The claims in Synchronoss Techs., Inc. v. Dropbox, Inc., “require[d] an 24 impossibility—that the digital media file contain a directory of digital media files.” 987 F.3d 25 1358, 1367 (Fed. Cir. 2021). In Trs. Of Columbia Univ. v. Symantec Corp., the court found claims 26 27 1 indefinite where they required extracting particular instructions from something that did not 2 contain those instructions—an impossibility which the court likened to “extracting orange juice 3 from apples[.]” 811 F.3d 1359, 1367 (Fed. Cir. 2016) (internal quotations omitted). 4 F5 makes argument concerning the alleged inconsistency between what “presentation 5 information” is and the reality that some claims containing this term also specify that 6 “presentation information includes at least one of protocol information, formatting information, 7 positional information, rendering information, style information, transmission encoding 8 information . . . .” (Def. Resp. Br. at 14 (quoting ’870 Patent at cl. 1; ’682 Patent at cls. 1, 6, 8, 10, 9 12, 16) (supplied emphasis omitted).) The problem, according to F5, is that these types of 10 information do not do what Sunstone argues “presentation information” does. As we know, 11 however, “presentation information” is a broad category including subsets of information, so there 12 is nothing internally inconsistent about “presentation information” including types of information 13 that do not do what “presentation information” as a whole does. If a Swiss Army Knife both cuts 14 and files, the file only files, but the Knife as a whole still cuts and files. 15 F5 makes the same file history arguments regarding “presentation information,” and they 16 are equally uncompelling here. (Def. Resp. Br. at 15-16.) Nevertheless, the file history also 17 would not aid a POSA in discerning the bounds of the term. In Masco Corp. v. U.S., the court 18 found that the patentee’s amendment inserting the word “drive” distinguished pushing from 19 pulling such that the patentee’s attempt to include pulling actions in “drive” was inconsistent. 303 20 F.3d 1316, 1325 (Fed. Cir. 2002). In Cap. Sec. Sys. v. NCR Corp., 725 F. App’x 952, 959 (Fed. 21 Cir. 2018), the court affirmed the district court’s finding that the term “transactional operator” was 22 indefinite where the patentee set forth an interpretation that was arbitrary and generally 23 unsupported by the specification, from which it was not transparent what the term encompassed. 24 F5 points to nothing showing the patentee disavowed scope, such as in Masco, by giving an 25 example where a server could label “data field,” and this example does not demonstrate that labels 26 are necessarily presentation information. Nevertheless, as in Cap. Sec., “presentation 27 information,” like “transactional information,” is generally unsupported by the specification, and it 1 Sunstone’s claim differentiation arguments on reply illustrate why the argument supports 2 neither side. (See Reply at 6-9.) The doctrine of claim differentiation is guided by mere “common 3 sense[.]” Seachange Int'l, Inc. v. C-COR, Inc., 413 F.3d 1361, 1368 (Fed. Cir. 2005) (internal 4 citations and quotations omitted). Different terms in different claims indicate different things. 5 This presumption is not ironclad, but F5’s argument against the presumption rests on a premise 6 that is not established. Nevertheless, this is far from F5’s only indefiniteness argument.3 7 Sunstone’s reliance on Process Control Corp. v. HydReclaim Corp. on reply is also 8 inapposite because there the court was stating that the claim defined the term, not that terms are 9 automatically defined because they appear in the claims. 190 F.3d 1350 (Fed. Cir. 1999). The 10 proposition for which Sunstone cites Netcraft Corp. v. eBay, Inc., 549 F.3d 1394, 1400 n.1 (Fed. 11 Cir. 2004), that a court may accept circular or redundant constructions, is dicta. 549 F.3d 1394, 12 1400 n.1 (Fed. Cir. 2008). 13 If the Court declines to adopt Sunstone’s proffered plain and ordinary meaning, then 14 “presentation information” is also indefinite based on Sunstone’s proposed alternative 15 construction of “information specifying how transactional information is to be displayed.” 16 Sunstone points to nothing in the specification that would clarify to a POSA what 17 “presentation information” is. The file history does not enlighten. As such, the Court finds that 18 the intrinsic evidence does not support Sunstone’s proffered constructions, and the term 19 “presentation information” is indefinite. 20 3. “estimating a label of the presentation information” 21 Sunstone Construction F5 Construction Court’s 22 Construction 23 Plain and ordinary meaning Indefinite Indefinite Estimating a label of an indefinite term is itself indefinite. Because the Court has analyzed 24 the term “presentation information” and found it to be indefinite, “estimating a label of the 25 26 3 The Court acknowledges that, “the subjective intent of the inventor when [s]he used a 27 particular term is of little or no probative weight in determining the scope of a claim.” 1 presentation information” is also indefinite. 2 D. Disputed Terms in the ’870 Patent 3 1. “soft information” 4 Sunstone Construction F5 Construction Court’s 5 Construction 6 “information describing how hard “information describing how Indefinite information is to be displayed by a hard information is to be 7 client device” displayed by a client device” 8 The parties agree that “soft information” rises or falls with “presentation information.” 9 Because “presentation information” is indefinite, the Court finds that “soft information” is also 10 indefinite. 11 2. “estimating a utilization of a codeword set” 12 Sunstone Construction F5 Construction Court’s 13 Construction Plain and ordinary meaning Indefinite Indefinite 14 The patentee introduces numerous verbs in connection with the explanation of this term. 15 Notwithstanding that problem, there is nothing implying that a “codeword set” is anything other 16 than a type of “hard information.” If “hard information” is a subset of “transactional 17 information,” which is itself indefinite, then this term is also indefinite. 18 // 19 // 20 // 21 // 22 // 23 // 24 // 25 // 26 // 27 1 IV. CONCLUSION Based on the foregoing, the Court provides the following claim constructions: 2 3 4 “estimating a label of the presentation Indefinite information”

6 “estimating a utilization of a codeword set” 7 This terminates Docket Number 120. IT Is SO ORDERED.

9 Dated: 3/30/2023 10 NNE GONZALEZ ROGERS 11 ITED STATES DISTRICT JUDGE

it

4 18 19 20 21 22 23 24 25 26 27 28

APPENDIX

5 ATTACHMENT A

3 || Independent claim 1 of the ’870 recites: 4 1.4 method comprising: selecting transactional information to transmit from a 5 server to acommunicatively coupled client device based on a request from the client device; : 6 selecting presentation information corresponding to the transactional information to transmit from the server to 7 the client device, the presentation information specify- ing how the transactional information 1s to be displayed; 8 transmitting at least one message including the presenta- 10 tion and transactional information from the server to the 9 client device: determining a prediction of a response message from the 10 client device based on 1) the selected transactional infor- mation, i1) bow the chent device is configured to render | 11 the transactional information specified by the presenta- tion information, and iii) predicted response information 3 12 associated with the transactional information that is expected to be provided by a user of the client device; 413 receiving the response message from the client device; and: tesponsive to information in the response message not matching the prediction, providing an indication there is S a malicious application affecting communications 3 15 between the server and the client device, wherein the prediction is further determined based at 25 a 16 least in part by at least one of: (a) estimating locations of rendered features and func- 8 tions as displayed by the client device, 5 (b) estimating locations of rendered page geometry of

Z 18 the features and functions, : (c) estimating relative locations between text, input 19 boxes, buttons, and advertisements as displayed by the client device. 20 (d) estimating a label of the presentation information, (€) estimating a utilization of a codeword set based on | 21 the presentation information and transactional infor- mation, and 22 (f) estimating a utilization of a codeword set based on actions taken by at least one of the user and the client 23 device. 24 || (Italics supplied.) 25 26 27 28

1 Independent claim 39 of the ’870 recites: 2 39. A method comprising: receiving, in a security server from a transaction server, 3 transactional information to transmit to a client device based on a transaction with the client device: 4 receiving, in the security server from the transaction server, presentation information corresponding to the fransac- 5 tional information: modifying, via the security server, at least some of the 6 presentation information: transmitting, via the security server, the modified presen- 7 tation information and transactional information to the client device: 8 determining, via the security server, an acceptable response based on i) the modified presentation informa- 9 tion and the transactional information, 11) how the client device configured to render the transactional informa- 10 tion, and i) predicted response information associated with the fransactional information that is expected to be 11 provided by a user of the client device; and responsive to information in a response message from the 12 chent device not matching the acceptable response, pro- viding an indication there is a malicious application 13 affecting communications between the transaction server and the client device, wherein the acceptable response is further determined based at least in part by at least one of: 15 (a) estimating locations of rendered features and func- tions as displayed by the client device, a 16 (b) estimating locations of rendered page geometry of the features and functions, 17 (c) estimating relative locations between text, input boxes, buttons, and advertisements as displayed by 2 18 the client device. (d) estimating a label of the presentation information, 19 (e) estimating a utilization of a codeword set based on the presentation information and fransactienal infor- 20 mation, and (£) estimating a utilization of a codeword set based on 21 actions taken by at least one of the user and the client device. 22 (Italics supplied.) 23 24 25 26 27 28

ATTACHMENT B

2 3 Independent claim 1 of the ’682 recites: 4 5 1. A method comprising: selecting, via a processor, transactional information to 6 transmit from a server to a communicatively coupled client device based on a request from the client device; 7 selecting, via the processor, presentation information cor- 5 responding to the transactional information to transmit 8 from the server to the client device, the presentation information specifying how the transactional informa- 9 fion is to be displayed; transmitting, via the processor, at least ome message 10 including the presentation and transactional informa- fion from the server to the client device; 1 determining, via the processor, a prediction of a response message from the client device based on i) the selected fransactional information, u) how the client device is 12 configured to render the transactional information 5 B specified by the presentation information, and iii) expected response information associated with the v 14 transactional information that is expected to be pro- © vided by a user of the client device; 2 15 receiving, in the processor, the response message from the client device; and a 16 responsive to information in the respomse message mot matching the prediction, providing, via the processor, an 17 indication there is a malicious application affecting communications between the server and the client Z 18 device. wherein the prediction is further determined by the 19 processor based at least in part by estimating at least one location of at least one rendered feature or 20 function as displayed by the client device, wherein the presentation information includes at least 21 one of protocol information, formatting information, positional information, rendering information, style 22 information, transmission encoding information, information describing how different layers ofa style 23 sheet are to be rendered by the client device, or information changing a definition of a function in a 24 code library at the client device, and wherein the transactional information includes at least 25 one of text, data, pictorial information, image infor- mation, information requested by the server to per- 26 form a service for the client device, authentication information, refinement information on a type of service requested by the client device, financial information, or data management information. 28 || Ctalics supplied.)

1 Independent claim 6 of the ’682 recites: 2 6. A method comprising: 3 selecting, via a processor, transactional infermation to transmit from a server to a communicatively coupled 4 client device based on a request from the client device; selecting, via the processor, presentation information cor- 5 responding to the fransactonal information to transmit from the server to the client device, the presentation 6 information specifying how the transactional informa- tien is to be displayed; 7 transmitting, via the processor, at least one message including the presentation and transactional informa- 8 fion from the server to the client device: determining, via the processor, a prediction of a response 9 message from the client device based on i) the selected transactional information, ii) how the client device is 10 configured to render the transactional informafion specified by the presentation information, amd iii) expected response information associated with the 11 transactional information that is expected to be pro- vided by a user of the client device; 12 13 receiving, in the processor, the response message from the = client device; and 5 14 responsive to information in the response message not matching the prediction, providing, via the processor, B45 an indication there is a malicious application affecting 5 communications between the server and the client 16 device, a wherein the prediction is further determined by the 7 processor based at least in part by estimating at least one location of a rendered page geometry of at least u 18 one feature or function. wherein the presentation information includes at least 19 one of protocol information, formatting information, positional information, rendering information, style 0 information, transmission encoding information, information describing how different layers of a style 1 sheet are to be rendered by the client device, or information changing a definition of a function in a 0 code library at the client device, and wherein the transactional information includes at least one of text, data, pictorial information, image infor- mation, information requested by the server to per- form a service for the client device, authentication 24 information, refinement information on a type of 25 service requested by the client device, financial 25 information, or data management information. 26 (Italics supplied.) 27 28

1 Independent claim 8 of the ’682 recites: 8. A method comprising: 2 selecting, via a processor, transactional information to transmit from a server to a communicatively coupled 3 client device based on a request from the client device; selecting, via the processor, presentation information cor- 4) 4 responding to the fransactional information to transmit from the server to the client device, the presentation 5 information specifying how the transactional informa- fion is to be displayed; 6 transmitting, via the processor, at least ome message 45 including the presentation and transactional informa- 7 fon from the server to the client device: determining, via the processor, a prediction of a response g message from the client device based on i) the selected transactional information, ii) how the client device is 30 9 configured to render the transactional information specified by the presentation information, and iii) expected response information associated with the 10 transactional information that is expected to be pro- vided by auser ofthe client device; 11 receiving. in the processor, the response message from the client device: and 12 responsive to information in the response message not matching the prediction, providing, via the proces- 13 s0r, am indication there isa malicious application affecting communications between the server and the v 14 client device, wherein the prediction is further determined by the 3 15 processor based at least in part by estimating relative locations between text, input boxes, but- 65 16 tons, and advertisements as displayed by the client wherein the presentation information includes at least . . . 2 17 one of protocol information, formatting information, positional information, rendering 18 information, style information, transmission encoding information, information describing how 19 different layers of a style sheet are to be rendered by the client device, or information changing a 20 definition of a function in a code library at the client device, and 71 wherein the transactional information includes at least one of text, data, pictorial information, image 22 information, information requested by the server to perform a service for the client device, authen- 23 fication information, refinement information on a type of service requested by the client device, 24 financial information, or data management infor- mation. 25 (Italics supplied.) 26 27 28

1 Independent claim 10 of the ’682 recites: 10. A method comprising: 2 selecting, via a processor, transactional information to transmit from a server to a communicatively coupled 3 client device based on a request from the client device; selecting, via the processor, presentation information cor- 4 responding to the transactional information to transmit from the server to the client device, the presentation 5 information specifying how the transactional informa- tien is to be displayed: 6 transmitting, via the processor, at least one message including the presentation and transactional tnforma- 7 fen from the server to the client device: determining, via the processor, a prediction of a response g message from the client device based on 1) the selected transactional information, ii) how the client device is configured to render the transactional information 9 specified by the presentation information, and iii) expected response information associated with the 10 transactional information that is expected to be pro- vided by a user of the client device; 11 receiving, in the processor, the response message from the client device: and a 12 responsive to information in the response message not matching the prediction, providing, via the processor, an 13 indication there is a malicious application affecting communications between the server and the client O 14 device, wherein the prediction is further determined by the 3 15 processor based at least in part by estimating a label of the presentation information, a 16 wherein the presentation information includes at least one of protocol information. formatting information. 17 positional information, rendering information, style information, transmission encoding information, 18 information describing how different layers ofa style sheet are to be rendered by the client device, or 19 information changing a definition of a function in a code library at the client device, and 20 wherein the transactional information includes at least one of text, data, pictorial information, image infor- 21 mation, information requested by the server to per- 22 form a service for the client device, authentication information, refinement information on a type of 23 service requested by the client device, financial information, or data management information. 24 25 (Italics supplied.) 26 27 28

1 Independent claim 21 of the ’682 recites: 21. An apparatus comprising: 2 security processor, and a memory including instructions, which when executed, 3 cause the security processor configured to: select presentation information corresponding to transac- 4 fonal information received from a server; select a variation of the presentation information; 5 combine the selected variation of the presentation and transactional information into the at least ome message; 6 transmit the at least one message to a client device; determine a prediction ofa response message based on i) 7 the selected variation of the presentation information, ii) how the client device is configured to render the 8 transactional information, and iit) expected response information associated with the transactional informa- fion that is expected to be provided by a user of the 9 client device; and responsive to information in a response message from the 10 client device not matching the acceptable response, provide an indication there is a malicious application 11 affecting communications between the server and the client device. a 12 wherein the prediction is further determined based at least in part by estimating at least one location of at 413 least one rendered feature or function as displayed by the client device, JA wherein the presentation information includes at least S one of protocol information, formatting information, 3 15 positional information, rendering information, style information, transmission encoding information, a 16 information describing how different layers of a style sheet are to be rendered by the client device, or 45 information changing a definition of a function in a code library at the client device, and 18 wherein the transactional information includes at least one of text, data, pictorial information, image imfor- 19 mation, information requested by the server to per- form a service for the client device, authentication 20 information, refinement information on a type of service requested by the client device, financial 71 information, or data management information. 22 (Italics supplied.) 23 24 25 26 27 28

1 Independent claim 25 of the 682 recites: 25. An apparatus comprising: 2 a security processor, and a memory including instructions, which when executed, 3 cause the security processor to: 4 select presentation information corresponding to fransac- fenal information received from a server; 5 select a variation of the presentation information; combine the selected variation of the presentation and 6 transactional information into the at least one message; transmit the at least ome message to a client device; 7 determine a prediction ofa response message based on i) the selected variation of the presentation information, 8 ii) how the client device is configured to render the transactional information, and ui) expected response 9 information associated with the transactional informia- tien that is expected to be provided by a user of the client device; and 10 responsive to information in a response message from the client device not matching the acceptable response, 11 provide an indication there is a malicious application affecting communications between the server and the 12 client device, wherein the prediction is further determined based at 13 least in part by estimating at least one location of a tendered page geometry of at least one feature or function, wherein the presentation information includes at least 15 one of protocol information, formatting information, positional information, rendering information, style a 16 information, transmission encoding information, information describing how different layers ofa style sheet are to be rendered by the client device, or information changing a definition of a function in a 18 code library at the client device, and wherein the transactional information includes at least one of text, data, pictorial information, image infor- 19 mation, information requested by the server to per- form a service for the client device. authentication 20 information, refinement information on a type of service requested by the client device, financial 21 information, or data management information. 22 (Italics supplied.) 23 24 25 26 27 28

1 Independent claim 28 of the ’682 recites: 28. An apparatus comprising: 2 a security processor, and a memory including instructions, which when executed, 3 cause the security processor to: select presentation information corresponding to transac- 4 fional information received from a server; select a variation of the presentation information; 5 combine the selected variation of the presentation and transactional information into the at least one message: 6 transmit the at least one message to a client device; determine a prediction of aresponse message based on i) 7 the selected variation of the presentation information, ii) how the client device is configured to render the g transactional information, and ii) expected response information associated with the transactional informa- 9 fien that is expected to be provided by a user of the client device; and 10 responsive to information in response message from the client device not matching the acceptable response, provide an indication there is a malicious application 11 affecting communications between the server and the client device, a wherein the prediction is further determined based at least in part by estimating relative locations between 13 at least one of text, input boxes, buttons, or adver- tisements as displayed by the client device, 14 wherein the presentation information includes at least 35 S one of protocol information, formatting information, 15 positional information, rendering information, style information, transmission encoding information, 16 information describing how different layers of a style sheet are to be rendered by the client device, or 40 47 information changing a definition of a function in a code library at the client device, and 18 wherein the transactional information includes at least one of text, data, pictorial information, image infor- 1 mation, information requested by the server to per- 45 9 form a service for the client device, authentication information, refinement information on a type of 20 service requested by the client device, financial information, or data management information. Italics supplied. ( pplied.) 23 24 25 26 27 28

1 Independent claim 30 of the ’682 recites: 30..An apparatus comprising: 2 asecurity processor, and a memory including instructions, which when executed, 3 cause the security processor to: 4 select presentation information corresponding to fransac- tional information received from a server: select a variation of the presentation information; 5 combine the selected variation of the presentation and transactional information into the at least one 6 message; transmit the at least one message to a client device; determine a prediction of a response message 7 based on i) the selected variation of the presentation information, 8 ii) how the chent device is configured to render the transactional information, and ui) expected response 9 information associated with the transactional informa- tien that is expected to be provided by a user of the 10 client device; and responsive to information in a response message from the 11 client device not matching the acceptable response, provide an indication there is a malicious application 3 12 affecting communications between the server and the client device, 13 wherein the prediction is further determined based at least in part by estimating a label of the presentation 5 14 information, wherein the presentation information includes at least 15 one of protocol information, formatting information, positional information, rendering information, style information, transmission encoding information, 16 information describing how different layers ofa style sheet are to be rendered by the client device. or information changing a definition of a function in a code library at the client device, and Z 18 wherein the transactional information includes at least one of text, data, pictorial information, image infor- 19 mation, information requested by the server to per- form a service for the client device, authentication 20 information, refinement information on a type of service requested by the client device, financial 1 information, or data management information. 22 (Italics supplied.) 23 24 25 26 27 28