Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 1 of 15 PageID #: 3429
`
`IN THE UNITED STATES DISTRICT COURT
`FOR THE EASTERN DISTRICT OF TEXAS
`MARSHALL DIVISION
`
`
`
`BRIGHT DATA LTD.
`
`Plaintiff,
`
`
`
`
`
`
`
`v.
`
`NETNUT LTD.
`
`
`
`
`
`
`
`Case No. 2:21-cv-00225-JRG-RSP
`
`
`
`
`
`Defendant.
`
`
`
`BRIGHT DATA’S REPLY CLAIM CONSTRUCTION BRIEF
`(LOCAL PATENT RULE 4-5(c))
`
`
`
`
`
`Data Co Exhibit 1104
`Data Co v. Bright Data
`IPR2022-00135
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 2 of 15 PageID #: 3430
`
`I.
`
`II.
`
`
`
`
`TABLE OF CONTENTS
`
`DISPUTED TERMS FOR CLAIM CONSTRUCTION ............................................... 1
`A. Client / Client Device (’319, ’510, ’713, ’852 and ’346 Patents) .................................... 1
`B. First Server (’319, ’713 and ’852 Patents) ....................................................................... 3
`C. Server / Second Server (’319, ’510, ’713, ’852 and ’346 Patents) .................................. 4
`D. Hypertext Transfer Protocol (HTTP) / HTTP Request / Hypertext Transfer Protocol
`Secure (HTTPS) / HTTPS Request (’319, ’510, ’713, ’852 and/or ’346 Patents) ......... 4
`E. From the [first/web] server over the Internet in response to the sending (’319 Patent) .. 6
`F. Geographical Location Terms (’713, ’852 and ’346 Patents) .......................................... 7
`G. Receiving Over the Internet in Response to the Sending, From the Second Server Via a
`First Client Device, the Part of, or the Whole of, the First Content (’713 and ’852
`Patents) ........................................................................................................................... 7
`H. Not Indefinite: “Geographical Location” (’713, ’852 and ’346 Patents) ......................... 9
`I. Not Indefinite: “anonymously fetching” (’346 Patents) ................................................ 10
`J. Not Indefinite: “wherein the content is identified over the Internet using a distinct
`URL” (’346 Patents) ..................................................................................................... 10
`CONCLUSION ............................................................................................................... 10
`
`
`
`
`
`
`
`i
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 3 of 15 PageID #: 3431
`
`
`
`
`
`Cases
`
`
`
`TABLE OF AUTHORITIES
`
`Acceleration Bay LLC v. Elec. Arts Inc., Civil Action No. 1:16-cv-00454-RGA, 2019 U.S. Dist.
`LEXIS 51483 (D. Del. March 27, 2019) ..................................................................................... 6
`
`BASF Corp. v. Johnson Matthey Inc., 875 F.3d 1360 (Fed. Cir. 2017) ........................................ 10
`
`Medgraph, Inc. v. Medtronic, Inc., 843 F.3d 942 (Fed. Cir. 2016) ................................................ 7
`
`ii
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 4 of 15 PageID #: 3432
`
`Defendant repeatedly ignores the clear language of the claims, specification, patent
`
`prosecution history and previous guidance from this Court in seeking constructions that improperly
`
`incorporate specific standards and otherwise seek to rewrite the claims. In addition to other
`
`issues1, Defendant seeks to reduce the recited architecture of the claims to cause any computer
`
`intermediary in a computer (cid:316) computer (cid:316) computer pathway to be both a client device and a
`
`server. At the same time, Defendants also seek to repeatedly assert indefiniteness for claim terms
`
`by disregarding the clear language of the claims.
`
`
`
`I.
`
`DISPUTED TERMS FOR CLAIM CONSTRUCTION
`A.
`
`Client / Client Device (’319, ’510, ’713, ’852 and ’346 Patents)
`
`Bright Data’s proposed construction for “client device” is defined in the patent
`
`specification of the Patents-in-Suit: “In the network 50, files are stored on computers of
`
`consumers, referred to herein as client devices 60.” Ex. A at 2:44-46. Ignoring the clear
`
`distinctions between client devices and servers that were made in the common specification and
`
`patent prosecution history, Defendant does not dispute that its proposed constructions of these
`
`terms would cause any computer intermediary in a generic computer (cid:316) computer (cid:316)(cid:3)computer
`
`pathway to satisfy both the requirements of a client device and server in an improper attempt to
`
`broaden these claim terms so as to be interchangeable.
`
`This contradicts the Court’s guidance in the Supp. C.C. Order in Teso, where the Court
`
`stated, “It is not that Defendants seek to ‘(cid:85)(cid:72)(cid:71)(cid:88)(cid:70)(cid:62)(cid:72)(cid:64)(cid:3)(cid:87)(cid:75)(cid:72)(cid:3)(cid:85)(cid:72)(cid:70)(cid:76)(cid:87)(cid:72)(cid:71)(cid:3)(cid:86)(cid:72)(cid:85)(cid:89)(cid:72)(cid:85)(cid:3)(cid:316)(cid:3)(cid:70)(cid:79)(cid:76)(cid:72)(cid:81)(cid:87)(cid:3)(cid:71)(cid:72)(cid:89)(cid:76)(cid:70)(cid:72)(cid:3)(cid:316)(cid:3)(cid:90)(cid:72)(cid:69)(cid:3)(cid:86)(cid:72)(cid:85)(cid:89)(cid:72)(cid:85)
`
`(cid:68)(cid:85)(cid:70)(cid:75)(cid:76)(cid:87)(cid:72)(cid:70)(cid:87)(cid:88)(cid:85)(cid:72)(cid:3) (cid:17)(cid:3) (cid:17)(cid:3) (cid:17)(cid:3) (cid:68)(cid:81)(cid:71)(cid:3) (cid:87)(cid:75)(cid:72)(cid:3) (cid:85)(cid:72)(cid:70)(cid:76)(cid:87)(cid:72)(cid:71)(cid:3) (cid:70)(cid:79)(cid:76)(cid:72)(cid:81)(cid:87)(cid:3) (cid:71)(cid:72)(cid:89)(cid:76)(cid:70)(cid:72)(cid:3) (cid:316)(cid:3) (cid:86)(cid:72)(cid:85)(cid:89)(cid:72)(cid:85)(cid:3) (cid:316)(cid:3) (cid:90)(cid:72)(cid:69)(cid:3) (cid:86)(cid:72)(cid:85)(cid:89)(cid:72)(cid:85)(cid:3) (cid:68)(cid:85)(cid:70)(cid:75)(cid:76)(cid:87)(cid:72)(cid:70)(cid:87)(cid:88)(cid:85)(cid:72)(cid:3) (cid:17)(cid:3) (cid:17)(cid:3) (cid:17)(cid:3) (cid:68)(cid:86)(cid:3) (cid:68)(cid:81)
`
`
`1 Unlike NetNut, Bright Data’s level of ordinary skill in the art, based on Dr. Williams’ declaration,
`is consistent with the Teso CC Order. Ex. H at 8. In contrast, NetNut seeks to introduce overly
`specific and narrow requirements to improperly tie such a POSA to specific protocols and RFCs.
`Defendant’s proposed level of ordinary skill in the art should be rejected.
`
`
`1
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 5 of 15 PageID #: 3433
`
`(cid:76)(cid:81)(cid:71)(cid:76)(cid:86)(cid:87)(cid:76)(cid:81)(cid:74)(cid:88)(cid:76)(cid:86)(cid:75)(cid:68)(cid:69)(cid:79)(cid:72)(cid:3)(cid:70)(cid:82)(cid:80)(cid:83)(cid:88)(cid:87)(cid:72)(cid:85)(cid:3)(cid:316)(cid:3)(cid:70)(cid:82)(cid:80)(cid:83)(cid:88)(cid:87)(cid:72)(cid:85)(cid:3)(cid:316)(cid:3)(cid:70)(cid:82)(cid:80)(cid:83)(cid:88)(cid:87)(cid:72)(cid:85)(cid:3)(cid:68)(cid:85)(cid:70)(cid:75)(cid:76)(cid:87)(cid:72)(cid:70)(cid:87)(cid:88)(cid:85)(cid:72)’ as Plaintiffs argue.” Ex. I at
`
`10. Here, Defendant asks the Court to modify its previous construction (and Bright Data’s
`
`alternative construction) for “client device” of “communication device that is operating in the role
`
`of a client” to delete “communication device” in favor of a generic “device,” despite the patent
`
`specification describing the communication network as shown for example in Fig. 3 as
`
`distinguishing “communication device(s)” comprising the functionality of a client, peer, or agent
`
`from servers. Ex. A at 4:41-5:10.
`
`Similarly, Defendant attempts to improperly incorporate the definitions of RFC 2616
`
`regarding a “client” and “server” to improperly read such definitions into the claim constructions
`
`of “client device” and “server.” The common specification references but in no way limits the
`
`client device or server in reference to any RFC or protocol. Ex. A at 16:12-28.2 Defendant
`
`mischaracterizes this reference in an improper attempt to erase the above distinctions in the
`
`disclosure of the Patents-in-Suit. Resp. at 7-8 and 9-10. Ignoring the specification, NetNut
`
`attempts to improperly incorporate the RFC 2616 descriptions of a “client” and “server” as
`
`programs to improperly construe the “client device[s]” and “server[s]” of the communication
`
`network of the common specification as interchangeable devices. Unlike RFC 2616, the patent
`
`specification distinguishes “communications devices” (including client devices) from servers. The
`
`specification also provides for proxy servers that both make requests and send content, but
`
`Defendant’s proposal that any device that makes requests is a client would inappropriately cause
`
`these servers to meet the “client” term, where the patent specification never includes a proxy server
`
`
`2 The Patent Owner was fully aware that he could recite specific protocols in the claims, as was
`done for example in dependent claim 15 of the ’319 Patent, which determined the validity of the
`received first content “according to, or based on, IETF RFC 2616.” However, no such protocol
`was incorporated for defining client devices or servers.
`
`2
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 6 of 15 PageID #: 3434
`
`as a client, and instead only distinguishes servers from clients. Defendant’s attempt to impose the
`
`RFC 2616 as providing definitions of “client” and “server” is not supported by the specification,
`
`is in fact contracted by the use of the terms in the specification, and constitutes an improper attempt
`
`to rewrite the novel use of client devices as proxies out of the claims. It also ignores the
`
`prosecution history that definitively limits the use of the terms “client device” and “server” as
`
`different from each other. See e.g. Ex. J, at 4-5.
`
`Similarly, Defendant mischaracterizes Bright Data’s position during claim construction in
`
`the Teso Action to take a modified exemplary figure out of context. Bright Data did not argue that
`
`a client or agent is a server. Ex. Q, Teso Action, Dkt. 145 at 2. Defendant similarly
`
`mischaracterizes Dr. Williams’ deposition testimony. Ex. R at 89: 15-18 (Q: “Can a personal
`
`computer or workstation also have installed on its software that is configured to perform server
`
`tasks?” A: “Yes”). Dr. Williams’ testimony was consistent with the disclosure of the common
`
`specification that the “communication device may serve in the role as a client, peer, or agent,
`
`depending upon requirements of the network” as supported by the specification’s disclosure. Ex.
`
`A at 4:41-53; see also id. at Fig. 6 and 9:13-36. Dr. Williams did not provide an opinion regarding
`
`a server consumer computer.
`
`Consistent with the claim language, the definition provided by the specification and the
`
`detailed discussion therein, a “client device” should be construed to mean “consumer computer,”
`
`or in the alternative “communication device that is operating in the role of a client.”
`
`B.
`
`First Server (’319, ’713 and ’852 Patents)
`
`Defendant does not dispute that the first server is a web server. Resp. at 8. Thus, it would
`
`be helpful to construe the “first server” of the ’319, ’713 and ’852 Patents as a “web server,”
`
`consistent with the other Asserted Patents.
`
`3
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 7 of 15 PageID #: 3435
`
`C.
`
`Server / Second Server (’319, ’510, ’713, ’852 and ’346 Patents)
`
`For the same reasons provided above as to “client device,” Defendant’s proposed
`
`construction of “server” and “second server,” should similarly be rejected. As above, Defendant
`
`seeks to change the Court’s previous constructions by replacing the word “server” with the generic
`
`“device” in order to treat all intermediary computers in a communication pathway as both “client
`
`devices” and “servers” without any consideration of their configuration. Resp. at 9-10. As
`
`described above, the disclosure of the common specification distinguishes client devices and
`
`servers and further discloses how a communication device can be configured to operate in the role
`
`of a client, agent, and peer. Defendant ignores the intrinsic evidence and the Court’s guidance
`
`regarding the ‘reduc[tion of(cid:64)(cid:3)(cid:87)(cid:75)(cid:72)(cid:3)(cid:85)(cid:72)(cid:70)(cid:76)(cid:87)(cid:72)(cid:71)(cid:3)(cid:86)(cid:72)(cid:85)(cid:89)(cid:72)(cid:85)(cid:3)(cid:316)(cid:3)(cid:70)(cid:79)(cid:76)(cid:72)(cid:81)(cid:87)(cid:3)(cid:71)(cid:72)(cid:89)(cid:76)(cid:70)(cid:72)(cid:3)(cid:316)(cid:3)(cid:90)(cid:72)(cid:69)(cid:3)(cid:86)(cid:72)(cid:85)(cid:89)(cid:72)(cid:85) architecture . . . and
`
`(cid:87)(cid:75)(cid:72)(cid:3)(cid:85)(cid:72)(cid:70)(cid:76)(cid:87)(cid:72)(cid:71)(cid:3)(cid:70)(cid:79)(cid:76)(cid:72)(cid:81)(cid:87)(cid:3)(cid:71)(cid:72)(cid:89)(cid:76)(cid:70)(cid:72)(cid:3)(cid:316)(cid:3)(cid:86)(cid:72)(cid:85)(cid:89)(cid:72)(cid:85)(cid:3)(cid:316)(cid:3)(cid:90)(cid:72)(cid:69)(cid:3)(cid:86)(cid:72)(cid:85)(cid:89)(cid:72)(cid:85)(cid:3)(cid:68)(cid:85)(cid:70)(cid:75)(cid:76)(cid:87)(cid:72)(cid:70)(cid:87)(cid:88)(cid:85)(cid:72)(cid:3)(cid:17)(cid:3)(cid:17)(cid:3)(cid:17)(cid:3)(cid:68)(cid:86)(cid:3)(cid:68)(cid:81) indistinguishable computer
`
`(cid:316)(cid:3)(cid:70)(cid:82)(cid:80)(cid:83)(cid:88)(cid:87)(cid:72)(cid:85)(cid:3)(cid:316)(cid:3)(cid:70)(cid:82)(cid:80)(cid:83)(cid:88)(cid:87)(cid:72)(cid:85)(cid:3)(cid:68)(cid:85)(cid:70)(cid:75)(cid:76)(cid:87)(cid:72)(cid:70)(cid:87)(cid:88)(cid:85)(cid:72)’.” Ex. I at 10. Instead, by incorporating the RFC 2616
`
`description of “client” and “server,” Defendant seeks to impermissibly treat all intermediary
`
`computers in a (cid:70)(cid:82)(cid:80)(cid:83)(cid:88)(cid:87)(cid:72)(cid:85)(cid:3)(cid:316)(cid:3)computer (cid:316)(cid:3)(cid:70)(cid:82)(cid:80)(cid:83)(cid:88)(cid:87)(cid:72)(cid:85)(cid:3)(cid:83)(cid:68)(cid:87)(cid:75)(cid:90)(cid:68)(cid:92)(cid:3)as a client device and server. Resp.
`
`at 9-10. Such an approach is inconsistent with the intrinsic evidence and the Court’s guidance.
`
`Ex. A at 4:41-5:10; Ex. I at 10. Defendant’s proposed construction should be rejected.
`
`D.
`
`Hypertext Transfer Protocol (HTTP) / HTTP Request / Hypertext Transfer
`Protocol Secure (HTTPS) / HTTPS Request (’319, ’510, ’713, ’852 and/or
`’346 Patents)
`
`As opined by Dr. Williams, “A POSA would understand these terms consistent with their
`
`plain and ordinary meaning” (Ex. F (cid:68)(cid:87)(cid:3) (cid:4161)(cid:3) (cid:22)(cid:20)) and Defendant concedes that “a POSITA would
`
`understand that they have the conventional usage as known in the art” (Resp. at 11). However,
`
`4
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 8 of 15 PageID #: 3436
`
`instead of adopting the plain and ordinary meaning of the above HTTP and HTTPS terms,3
`
`Defendant seeks to incorporate limitations from specific RFC protocols that are not recited in the
`
`claims in order to improperly narrow the scope of the claims. Resp. at 16. As discussed above,
`
`RFC 2616 is referenced in the common specification, but the Asserted Patent claims do not limit
`
`these terms to any RFC or protocol, including with regard to the formatting of requests or
`
`encryption. Ex. A at 16:12-28. Defendant’s attempts to incorporate specific standards in the claim
`
`terms is improper. The patentee knew how to limit claims to specific protocols as shown in
`
`dependent claim 15 of the ’319 Patent (see footnote 1 above) but did not do so here with regard to
`
`HTTP and HTTPS in the Asserted Patent claims.
`
`The Asserted Patent claims recite Hypertext Transfer Protocol (HTTP) and/or Hypertext
`
`Transfer Protocol Secure (HTTPS) and associated requests. To the extent that the Asserted Patent
`
`claims recite both HTTP and HTTPS, the claims broadly capture both terms (i.e., claim 1 of ’346
`
`Patent recites “sending … HTTP or HTTPS requests for the URLs….”). Ex. E at 19:27-29. In
`
`discussing the specification disclosure of HTTP servers (Ex. A at 4:62-5:7), Dr. Williams opined
`
`that “[a] typical HTTP server as known to a POSA in 2009 would have included HTTPS servers.”
`
`Ex. F at (cid:4161) 31. Defendant attempts to create a false dichotomy by asserting that “HTTP does not
`
`provide any encryption,” but Defendant does not dispute that HTTP does not prohibit encryption
`
`and ignore that HTTPS is an HTTP (HyperText Transfer) protocol that includes encryption. As
`
`explained by Dr. Williams, “[a] POSA would have understood HTTPS to be a secure form of
`
`HTTP” and “[a] POSA would not understand the recited HTTP to expressly exclude the secure
`
`version of HTTP known as HTTPS” and Ex. F (cid:68)(cid:87)(cid:3)(cid:4161)(cid:3)(cid:22)(cid:20). Defendant is attempting to add negative
`
`
`3 To the extent that Defendant alleges lack of written description support as part of its improper
`motion for summary judgment on grounds of anticipation (Dkt. 96), Bright Data has addressed
`those arguments in its response to that motion (Dkt. 113).
`
`5
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 9 of 15 PageID #: 3437
`
`claim limitations to improperly exclude HTTP Secure from HTTP. Defendant relies heavily on
`
`its own expert to argue that the Court should incorporate specific RFP standards while disregarding
`
`the language of the claims and the intrinsic evidence regarding client devices, servers and HTTP.
`
`Defendant mischaracterizes Dr. Williams’s testimony to imply a lack of familiarity with HTTPS.
`
`Having provided extensive technical deposition testimony related to HTTP and transport layer
`
`security (“TLS”), Dr. Williams testified that he “certainly used [the TLS protocol, but] don’t recall
`
`whether I actually implemented it or not” and clarified that he has “implemented other secure
`
`protocols.” see e.g., Ex. R at 129:24-130:6; see also e.g. 114:8-119:4; 124:15-21; 128:1-129:22.
`
`Defendant improperly asserts that Dr. Williams’ testimony is unreliable without identifying a
`
`single question that he was unable to answer with regard to functionality of HTTP, HTTP over
`
`TLS or HTTP over SSL.
`
`E.
`
`From the [first/web] server over the Internet in response to the sending (’319
`Patent)
`
`All recited claim steps are performed by the first client device—none are performed by the
`
`first server/web server. Acceleration Bay is inapposite as that case found a patent comprising the
`
`step of “a fully connected portal computer, which in turn sends an edge connection request” to
`
`be non-infringing where the portal computer was located outside the United States. Acceleration
`
`Bay LLC v. Elec. Arts Inc., Civil Action No. 1:16-cv-00454-RGA, 2019 U.S. Dist. LEXIS 51483,
`
`at *14–16 (D. Del. March 27, 2019). No such act or response is recited in these claims. Defendant
`
`and Defendant’s expert mischaracterizes the recited elements of the claims. Resp. at 17. For
`
`example, in claim 1 of the ’319 Patent, the recited element of the “first client device … receiving,
`
`the first content from the first server … in response to the sending of the first content identifier”
`
`specifically refers to the preceding element of the “first client device … sending, to the first server
`
`… a Hypertext Transfer Protocol (HTTP) request that comprises the first content identifier.”
`
`6
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 10 of 15 PageID #: 3438
`
`Similarly, Defendant and Dr. Claffy also misrepresent the prosecution history. 4 Defendant’s
`
`attempt to add unrecited steps to be performed by the first server or web server is completely
`
`improper and should be rejected.
`
`F.
`
`Geographical Location Terms (’713, ’852 and ’346 Patents)
`
`Each of these terms should be construed as plain and ordinary meaning. Defendant
`
`inexplicably seeks to improperly insert new vague limitations that would invite a subsequent O2
`
`Micro challenge to ascertain what would be meant by “a geographical location distinct from the
`
`HTTP or HTTPS requests, not something from which the geographical location is derived.”5 The
`
`claims recite no such additional limitation, and these proposed constructions should be rejected.
`
`G.
`
`Receiving Over the Internet in Response to the Sending, From the Second
`Server Via a First Client Device, the Part of, or the Whole of, the First Content
`(’713 and ’852 Patents)
`
`This term should be construed as
`
`having its plain and ordinary meaning,
`
`consistent with Dr. Williams’ declaration.
`
`Ex. F at 35. Defendant does not analyze this
`
`term in the context of the ’713 and ’852
`
`
`4 Bright Data overcame an office action based on the Fang reference stating “the claim explicitly
`recites that the receiving of the first content ‘from the first server over the Internet in response to
`the sending of the first content identifier’ (emphasis added). The Action and the Fang reference
`are silent regarding any such action in response to the sending of the first content identifier.” Ex.
`J, BDNET-0000310. Thus, Dr. Claffy’s unsustantiated opinion that “[a] POSITA would
`understand that the “action” referred to is the “action” by the “first server” is clearly contradicted
`by the actual language of the claim and cited prosecution history. Ex. L at (cid:4161)(cid:3)(cid:24)(cid:27)(cid:17)
`5 Medgraph is also inapposite, as there is no dispute regarding the meaning of “and” vs. “or.”
`Medgraph, Inc. v. Medtronic, Inc., 843 F.3d 942, 949 (Fed. Cir. 2016) (holding that “and” can
`mean “or” when the specification so requires, but otherwise has its plain and ordinary meaning).
`Rather, Defendant appears to rewrite the claims to require specific formatting of the “geographical
`location,” which is not required in the claims.
`
`7
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 11 of 15 PageID #: 3439
`
`Patent claims, which clearly describe a requesting client device (cid:316)(cid:3)second server (cid:316)(cid:3)first client
`
`device (cid:316)(cid:3)first server architecture as described in the opening brief and shown in the annotated
`
`figure 3 to the right. Dkt. 106 at 4.
`
`Instead, Defendant is attempting to rewrite the claim to require the requesting client device
`
`to be a “peer device” and to prohibit the requesting client device from receiving the first content
`
`from the first server. To do this, Defendant has
`
`modified the embodiment in Figure 3 to replace
`
`the agent communication device 122 with a
`
`second server and call peer 112 a first client
`
`device as shown in Defendant’s annotated figure
`
`3 to the right. Resp. at 21. Defendant provides no
`
`basis for replacing agent 122, which is described
`
`in the patent specification as a “communication
`
`device” with a server. Resp. at 21. Having replaced the communication device with a server,
`
`Defendant then asserts that its modified Figure 3 shows no “client device” between “requesting
`
`client device and the second server (agent 122).” Similarly, based on Defendant’s modification of
`
`Figure 3, Defendant also asserts that there is no “client device” between “second server (agent
`
`122) and the ‘first server’/’web server’.” However, the removed “agent 122” is a communication
`
`device that can operate as a client, agent, or peer. Ex. A at 4:41-53. Consequently, the purported
`
`lack of a “client device” between the client device 102 and web server 152 is completely the result
`
`of Defendant modifying Figure 3 to remove the agent communication device. In addition,
`
`Defendant’s proposed architecture seeks to remove the first client device from the communication
`
`pathway between the requesting client device first server and second server.
`
`8
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 12 of 15 PageID #: 3440
`
`Defendant’s proposed architecture is clearly in error as inconsistent with the claim
`
`language, which in context recites “receiving over the Internet in response to the sending, from
`
`the second server via a first client device, the part of, or the whole of, the first content.” The first
`
`content must be received from the second (web) server through the first client device (agent),
`
`which is consistent with the claims.6 Defendant’s proposed construction is inconsistent with the
`
`term “via” as the requesting client device’s only communication appears to be with the requesting
`
`client device under Defendant’s architecture. Defendant’s arguments regarding the dependent
`
`claims are no better as each of the dependent claims are consistent with the independent claims
`
`and architecture of the Asserted Patents. This attempt to rewrite the claims to move the first client
`
`device outside the communication pathway is improper and should be rejected.
`
`H.
`
`Not Indefinite: “Geographical Location” (’713, ’852 and ’346 Patents)
`
`Dr. Williams provided his opinion that “a POSA would understand these terms consistent
`
`with their plain and ordinary meaning” and that these terms are not indefinite. Ex. F (cid:68)(cid:87)(cid:3)(cid:4161)(cid:4161) 34 and
`
`48. This opinion is supported by intrinsic evidence and the prosecution history. Dkt. 106 at 27-
`
`28. Defendant’s argument that the independent claims do not recite a use of the “geographical
`
`location” does not render the term indefinite, as a POSA would still understand the scope of
`
`“geographical location.” Defendants are wrong to the extent that they assert indefiniteness based
`
`on the breadth of the claims. “[B]readth is not indefiniteness.” BASF Corp. v. Johnson Matthey
`
`
`6 Defendant contorts itself in order to modify Figure 3 into its proposed architecture. First,
`Defendant asserts that the communication device that is agent 122, which is in the pathway
`between the requesting client device and web server must be a server, when in fact agent and other
`communication devices are contrasted from servers in the specification. Second, Defendant asserts
`that the communication device that peer 112 is itself a “first client device,” despite peer 112 merely
`responding to requests from the requesting client device without sending any requests. Resp. at
`21-23. Defendant’s inconsistent positions undermine both its positions regarding the “client
`device”/”server” distinction as well as its proposed construction for this claim term.
`
`9
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 13 of 15 PageID #: 3441
`
`Inc., 875 F.3d 1360, 1367 (Fed. Cir. 2017). In addition, Defendant itself concedes that a POSA
`
`would understand the meaning of “geographical location” when it proposed plain and ordinary
`
`meaning for three other terms comprising the same “geographical location” as addressed above.
`
`This term should not be found indefinite.
`
`I.
`
`Not Indefinite: “anonymously fetching” (’346 Patents)
`
`Dr. Williams provided his opinion that this term should be construed with its plain and
`
`ordinary meaning, which is consistent with the prosecution history of the ’346 Patent, which
`
`clearly indicates anonymity for the user or requesting client device. Defendant fails to address the
`
`prosecution history cited by Dr. Williams and the term should not be found indefinite.
`
`J.
`
`Not Indefinite: “wherein the content is identified over the Internet using a
`distinct URL” (’346 Patents)
`
`As above, Defendant fails to address Dr. Williams’ declaration and the supporting intrinsic
`
`evidence on which his opinion relies. As opined by Dr. Williams “a POSA would understand that
`
`both the content and parts of the content may each have a distinct URL.” Ex. F at (cid:4161) 57. For the
`
`reasons provided above, the Court should not find this term indefinite.
`
`II.
`
`CONCLUSION
`
`For the foregoing reasons, Plaintiff respectfully requests that the Court enter its proposed
`
`constructions as set forth above, and find that none of the claims is indefinite.
`
`
`
`Dated: March 16, 2022
`
`Respectfully submitted,
`
`
`
`By: /s/ Ronald Wielkopolski__
`
`
`
`Elizabeth L. DeRieux
`State Bar No. 05770585
`Capshaw DeRieux, LLP
`
`10
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 14 of 15 PageID #: 3442
`
`114 E. Commerce Ave.
`Gladewater, TX 75647
`Telephone: 903-845-5770
`ccapshaw@capshawlaw.com
`ederieux@capshawlaw.com
`
`Mark Mann
`Gregory Blake Thompson
`Mann | Tindel | Thompson
`300 West Main
`Henderson, TX 75652
`Telephone: 903-657-8540
`mark@themannfirm.com
`blake@themannfirm.com
`
`Ronald Wielkopolski
`Thomas Dunham
`Colby Davis
`Michael Woods
`RuyakCherian LLP
`1901 L St. NW, Suite 700
`Washington, DC 20036
`ronw@ruyakcherian.com
`tomd@ruyakcherian.com
`colbyd@ruyakcherian.com
`michaelw@ruyackherian.com
`
`Korula T. Cherian
`Robert Harkins
`RuyakCherian LLP
`1936 University Ave, Ste. 350
`Berkeley, CA 94704
`sunnyc@ruyakcherian.com
`bobh@ruyakcherian.com
`
`Attorneys for Plaintiff
`Bright Data Ltd.
`
`11
`
`
`
`
`
`
`
`
`
`

`

`Case 2:21-cv-00225-JRG-RSP Document 118 Filed 03/16/22 Page 15 of 15 PageID #: 3443
`
`
`
`CERTIFICATE OF SERVICE
`
`I hereby certify that all counsel of record who are deemed to have consented to electronic service are
`
`being served this 16th day of March 2022, with a copy of this document via CM/ECF.
`
`/s/ Ronald Wielkopolski
`
`12
`
`