Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 1 of 22 PageID #: 3602
`
`IN THE UNITED STATES DISTRICT COURT
`FOR THE DISTRICT OF DELAWARE
`
`CITRIX SYSTEMS, INC.,
`
`Plaintiff,
`
`v.
`
`AVI NETWORKS, INC.,
`
`Defendant.
`
`C.A. No. 17-1843-LPS
`
`JURY TRIAL DEMANDED
`
`CITRIX’S ANSWERING CLAIM CONSTRUCTION BRIEF
`
`Douglas E. McCann (#3852)
`Robert M. Oakes (#5217)
`FISH & RICHARDSON P.C.
`222 Delaware Avenue, 17th Floor,
`P.O. Box 1114
`Wilmington, DE 19801
`Telephone: (302) 652-5070
`dmccann@fr.com; oakes@fr.com
`
`Ruffin B. Cordell
`Indranil Mukerji
`Laura C. Whitworth
`FISH & RICHARDSON P.C.
`1000 Maine Avenue SW, Suite 1000
`Washington, D.C. 20024
`Telephone: (202) 783-5070
`cordell@fr.com; mukerji@fr.com;
`whitworth@fr.com
`
`Adam J. Kessel
`FISH & RICHARDSON P.C.
`One Marina Park Drive
`Boston, MA 02210-1878
`Telephone: 617-542-5070
`kessel@fr.com
`
`Dated: April 30, 2019
`
`Katherine Reardon
`FISH & RICHARDSON P.C.
`601 Lexington Avenue, 52nd Floor
`New York, NY 10022-4611
`Telephone: 212-765-5070
`reardon@fr.com
`
`John-Paul Fryckman
`FISH & RICHARDSON P.C.
`12390 El Camino Real
`San Diego, CA 92130
`Telephone: 858-678-5070
`fryckman@fr.com
`
`Benjamin K. Thompson
`FISH & RICHARDSON P.C.
`1180 Peachtree Street NE
`21st Floor
`Atlanta, GA 30309
`Telephone: (404) 892-5005
`BThompson@fr.com
`
`ATTORNEYS FOR PLAINTIFF
`CITRIX SYSTEMS, INC
`
`1
`
`CITRIX 2008
`Avi Networks v. Citrix Systems
`IPR2019-00844
`IPR2019-00845
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 2 of 22 PageID #: 3603
`
`
`
`
`
`
`
`
`
`TABLE OF CONTENTS
`
` 
`
`INTRODUCTION .............................................................................................................. 1 
`“REQUEST” AND “RESPONSE” TERMS ...................................................................... 2 
` 
`A.  Avi fails to show “response” and “request” are limited to the “application layer” ............ 3 
`
`B.  Avi fails to show “response” and “request” must include “a header and a payload” ......... 5 
`
`THE “TRANSPORT LAYER CONNECTION” TERM ................................................... 7 
` 
`A.  Avi fails to justify a negative limitation and ignores critical intrinsic evidence
`contradicting its proposal ............................................................................................................ 7 
`
`B.  Avi’s mischaracterizations of file histories ....................................................................... 11 
`
`  The ’978 file history ...................................................................................................... 11 
`(a) 
`The Roberts Reference .......................................................................................... 11 
`(b) 
`The Batra Reference ............................................................................................. 14 
`  The ’493 file history ...................................................................................................... 15 
`CONCLUSION ................................................................................................................. 18 
`
` 
`
`
`
`
`
`i
`
`2
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 3 of 22 PageID #: 3604
`
`
`
`Cases
`
`TABLE OF AUTHORITIES
`
`
`
`Page(s)
`
`In re Abbott Diabetes Care Inc.,
`696 F.3d 1142 (Fed. Cir. 2012)..............................................................................................3, 9
`
`ActiveVideo Networks, Inc. v. Verizon Comm’n, Inc.,
`694 F.3d 1312 (Fed. Cir. 2012)..................................................................................................2
`
`GE Lighting Solutions, LLC v. AgiLight, Inc.,
`750 F.3d 1304 (Fed. Cir. 2014)..................................................................................................3
`
`Inpro II Licensing, S.A.R.L. v. T-Mobile,
`450 F.3d 1350 (Fed. Cir. 2006)..................................................................................................9
`
`O2 Micro Int’l Ltd. v. Beyond Innovation Tech. Co., Ltd.,
`521 F.3d 1351 (Fed. Cir. 2008)..................................................................................................2
`
`Omega Eng’g, Inc., v. Raytek Corp.,
`334 F.3d 1314 (Fed. Cir. 2003)..................................................................................................3
`
`On-Line Techs. v. Bodenseewerk Perkin-Elmer GmBH,
`386 F.3d 1133 (Fed Cir. 2004).............................................................................................8, 10
`
`SciMed Life Sys., Inc. v. Advanced Cardiovascular Sys., Inc.,
`242 F.3d 1337 (Fed. Cir. 2001)..................................................................................................9
`
`Unwired Planet, LLC v. Square, Inc.,
`No. 3:13-cv-00579-RCJ-WGC, 2014 WL 4966033 (D. Nev. Oct. 3, 2014) .............................2
`
`
`
`ii
`
`3
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 4 of 22 PageID #: 3605
`
`
`
`INTRODUCTION
`
`Plaintiff Citrix Systems, Inc. (“Citrix”) hereby responds to Defendant Avi Network’s
`
`(“Avi”) Opening Brief. Avi’s brief, which lacks any expert support1, and proposes transparently
`
`results-oriented constructions designed to manufacture a non-infringement defense based on a
`
`purported negative limitation of the asserted claims. Specifically, Avi contends that the asserted
`
`claims prohibit the intermediary device from interacting with application layer messages it routes
`
`between clients and servers—presumably because Avi’s accused product does interact with those
`
`messages. Moreover, Avi’s brief fails to acknowledge, much less attempt to reconcile,
`
`inconsistencies between its arguments here and those it put forward in its IPR petitions. These
`
`inconsistencies further reveal Avi’s improper approach to Markman proceedings.
`
`Avi’s proposals should be rejected because they lack any basis in the claim language,
`
`specifications, or file histories. Avi’s marquee evidence to support its construction of “transport
`
`layer connection,” namely a statement that “no application layer interaction is required,” (1)
`
`describes features of a distinct invention related to connection multiplexing in a different patent
`
`application that does not claim priority to or from the Asserted Patents; (2) says only that
`
`application layer interaction is not “required” for connection multiplexing, not that application
`
`layer interaction is prohibited; and (3) would lead to a construction that excludes a preferred
`
`embodiment where the intermediary device plainly interacts with and modifies application layer
`
`information to support efficient connection reuse—intrinsic evidence as to which Avi is
`
`completely silent in its opening brief.
`
`
`1 Avi recently revealed that it intends to file an expert declaration with its responsive brief. To
`the extent Avi relies on expert testimony that it should have disclosed in its Opening Brief, Citrix
`reserves the right to seek leave to address that testimony.
`
`
`
`4
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 5 of 22 PageID #: 3606
`
`
`
` “REQUEST” AND “RESPONSE” TERMS
`
`The claim construction arguments relating to “request” and “response” are closely related
`
`and are thus discussed collectively below.
`
`As an initial matter, Avi’s brief lacks any support to show that “request” and “response”
`
`require construction in the first place. In its IPR petitions, Avi did not contend these terms
`
`required construction, and offers no explanation for why the situation is different here. See D.I.
`
`104, Ex. J (’493 IPR Petition) at 7; id., Ex. K (’120 IPR Petition) at 7. Avi thus ignores the
`
`threshold requirement to justify construction and proceeds directly to contending that these terms
`
`should “include two fundamental features that a skilled artisan would recognize are in the
`
`claimed [terms],” namely “application layer” and “both a header and a payload.” D.I. 102 at 13.
`
`The mere fact that a skilled artisan would recognize that a term has a particular feature
`
`(according to Avi) is not in and of itself sufficient to require construction. The Court is under no
`
`obligation to construe a term just because a party requests it. O2 Micro Int’l Ltd. v. Beyond
`
`Innovation Tech. Co., Ltd., 521 F.3d 1351, 1362 (Fed. Cir. 2008) (“[D]istrict courts are not (and
`
`should not be) required to construe every limitation present in a patent’s asserted claims.”); see
`
`also ActiveVideo Networks, Inc. v. Verizon Comm’n, Inc., 694 F.3d 1312, 1326 (Fed. Cir. 2012)
`
`(finding that the district court did not err under O2 Micro in concluding that “superimposing”
`
`claim terms “have plain meanings that do not require additional construction”); Unwired Planet,
`
`LLC v. Square, Inc., No. 3:13-cv-00579-RCJ-WGC, 2014 WL 4966033, at *2 (D. Nev. Oct. 3,
`
`2014) (citing O2 Micro for the proposition that “a district court is not obligated to construe terms
`
`with ordinary meanings, lest trial courts be inundated with requests to parse the meaning of every
`
`word in the asserted claims”).
`
`2
`
`5
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 6 of 22 PageID #: 3607
`
`A.
`
`Avi fails to show “response” and “request” are
`limited to the “application layer”
`
`“Response” and “request” should be given their ordinary and customary meaning.
`
`Notably, Avi does not offer any evidence that the patentee acted as his own lexicographer or
`
`disavowed claim scope in the specification or during prosecution with respect to either of these
`
`terms. Instead, Avi argues that consistent use of a term in the specification implies that the term
`
`should be construed accordingly. Avi relies on a single, inapt case—Abbott—to attempt to
`
`overturn the “heavy presumption that claim terms carry their full ordinary and customary
`
`meaning.” Omega Eng’g, Inc., v. Raytek Corp., 334 F.3d 1314, 1323-25 (Fed. Cir. 2003). The
`
`Abbott court determined that the term “electrochemical sensor” excluded external connection
`
`cables or wires based on the specification’s explicit disparagement of their use. See In re Abbott
`
`Diabetes Care Inc., 696 F.3d 1142, 1149-50 (Fed. Cir. 2012). Unlike the party seeking a narrow
`
`construction with a negative limitation in Abbott, Avi points to no evidence in the common
`
`specification that disparages any type of message, nor does any such evidence exist. Rather, the
`
`common specification provides examples of “request” and “response” messages, including the
`
`GET method request of HTTP, which are communicated utilizing a transport layer connection.
`
`The GET method request and its corresponding HTTP response message are merely examples of
`
`message types that may be used in the preferred embodiments. These examples do not rise
`
`anywhere near the required level of “lexicography” or “disavowal” that would limit the “request”
`
`and “response” terms only to application layer messages. GE Lighting Solutions, LLC v.
`
`AgiLight, Inc., 750 F.3d 1304, 1309 (Fed. Cir. 2014) (“To act as its own lexicographer, a
`
`patentee must clearly set forth a definition of the disputed claim term, and clearly express an
`
`intent to define the term. Similarly, disavowal requires that the specification [or prosecution
`
`3
`
`6
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 7 of 22 PageID #: 3608
`
`history] make[ ] clear that the invention does not include a particular feature.”) (internal
`
`quotations and citations omitted).
`
`To be clear, Citrix does not contend that “request” and “response” exclude application
`
`layer messages—these messages are clearly within the scope of those terms, as shown by the
`
`examples from the specification referenced above. The plain and ordinary meaning of the terms,
`
`the common specification, and the claims of the Asserted Patents all illustrate that the “request”
`
`and “response” are communicated utilizing a transport layer connection and thus, according to
`
`the usual principles of computer networking (see D.I. 103 (Citrix’s Opening Brief) at 2-4), the
`
`“request” and “response” must be at a higher layer of the network stack than the transport layer,
`
`such as an application layer.2 However, Avi erroneously assumes that this “higher layer” must
`
`only be the application layer. See D.I. 102 at 14. In the well-known OSI layering model, there are
`
`additional layers between the application layer and the transport layer, including the session and
`
`presentation layers, each of which can have its own messages. See D.I. 104 (Jones Decl.) at
`
`¶¶ 32-42. There is no need to graft an additional “application layer” limitation to the construction
`
`of these terms, particularly where another claim term, namely “application data,” specifically
`
`relates to the application layer.3
`
`
`2 Avi’s statement that the patentee referred to the “entire packet more broadly” as a TCP
`“segment,” (D.I. 102 at 14) is not in tension with Citrix’s position. A TCP segment is a transport-
`layer concept. (See, e.g., ’493 patent at 5:55-56.) The parties agree that the ordinary meaning of
`“request” and “response” in this art is something that occurs at a layer of the network stack
`above the transport layer. Citrix disagrees with Avi to the extent it seeks to limit these terms to
`only one layer (the application layer) rather than simply any layer above the transport layer over
`which these messages are transmitted.
`3 Related U.S. Patent 7,801,978 similarly recites “application layer data” in both independent and
`dependent claims. (See, e.g., D.I. 104, Ex. I (’978 patent) at claims 1, 6-9.) This shows that when
`the inventors intended to impose an “application layer” requirement, they did so explicitly.
`
`4
`
`7
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 8 of 22 PageID #: 3609
`
`B.
`
`Avi fails to show “response” and “request” must
`include “a header and a payload”
`
`Avi’s argument that the “request” and “response” terms each must consist of a header and
`
`a payload should be rejected for several reasons. First, Avi again fails to provide any reasons
`
`why these terms require construction. Second, Avi offers no evidence that a request must have a
`
`payload, and did not address the evidence to the contrary provided in Citrix’s Opening Brief. See
`
`D.I. 103 at 12-14, 16. In fact, Avi failed to point clearly to any specific item in an exemplary
`
`request message, such as the GET method type message, that it deems to be the “payload.” Avi
`
`mentions a resource’s path name (e.g., /sales/forecast.html) in the GET method request message
`
`but does not explicitly state that it is the payload. See D.I. 102 at 15. A person of ordinary skill in
`
`the art would understand that the resource’s path name (part of a standard GET method request)
`
`is not part of the payload.4 See Jones Supp. Decl. at ¶¶ 6-8; see also D.I. 104 (Jones Decl.) at
`
`¶¶ 30, 50. Indeed, a GET method message under the standard has no payload (also understood
`
`and referred to as a “message body” or “entity body”). Id. The same textbook Avi relies on its
`
`brief confirms precisely this point: “The entity body [(i.e., payload)] is not used with the GET
`
`method.” See D.I. 102-1, Ex. 3 (Kurose-Ross Textbook Excerpts) at 81 (emphasis added). This
`
`point is also supported by Dr. Jones’s testimony that a GET method message does not have to
`
`include a payload (see Jones Supp. Decl. at ¶¶ 6-8; see also D.I. 104 at ¶¶ 30, 50), and
`
`accordingly, Avi’s construction that requires a “request” to include a payload is incorrect as a
`
`technical matter.
`
`
`4 Indeed, Avi’s brief further confuses the separate concepts of “header” and a “payload” by
`suggesting that the header is part of the payload. See D.I. 102 at 4 (“The HTTP protocol always
`includes additional information added to its payload in the form of a header—i.e., additional
`bits of information appended to the body—to ensure proper interpretation of information”)
`(emphasis added). Not only is the header not “added to” the payload, but, contrary to Avi’s
`erroneous assertion, HTTP requests often have no payload, as shown above by Avi’s own
`evidence.
`
`5
`
`8
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 9 of 22 PageID #: 3610
`
`Further, as explained in Citrix’s Opening Brief, some applications within the scope of the
`
`invention provide request and response messages that have neither headers nor payloads by
`
`definition—e.g., FTP, a common protocol for transferring files online. See D.I. 104 (Jones Decl.)
`
`at ¶ 42 see also ’493 patent at 5:35-37. Avi’s brief is silent on these applications as well.
`
`Finally, Avi failed to provide any support that both terms should be construed with the
`
`closed-group “consisting” language it proposes, which arguably would exclude from the claim
`
`any “request” or “response” including anything more than a header and a payload. This, too, is
`
`inconsistent with the technology at issue. For example, a common additional element such as a
`
`checksum, which provides error detection as part of a request or response message, could be
`
`excluded by Avi’s construction because the checksum is often separate from the header and the
`
`payload.5 The checksum is generated based on the content of the header, payload, or both. See
`
`Jones Supp. Decl. at ¶¶ 9-10. Avi’s overly narrow construction fails to account for these
`
`technical details that are apparent from the same extrinsic evidence it relies on in its brief.
`
`In sum, Avi’s construction imposes unnecessary and incorrect limitations on the
`
`construction of these terms. Avi’s construction lacks support from the claim language,
`
`specifications, or file histories of the ’493 and ’120 patents, and thus should be rejected. These
`
`terms should be given their plain and ordinary meaning, and as such, no further construction is
`
`required.
`
`
`5 HTTP messages can include additional elements beyond a header or a payload, such as an
`“empty line” (containing an additional carriage return and line feed symbols) that acts to signal
`the end of the HTTP header, and if an HTTP (or payload) body is present, to signal the start of
`the HTTP body (or payload). See D.I. 102-1, Ex. 3 (Kurose-Ross Textbook Excerpts) at 81; see
`also Jones Supp. Decl. at ¶11. This too is inconsistent with a close-ended construction.
`
`6
`
`9
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 10 of 22 PageID #: 3611
`
` THE “TRANSPORT LAYER CONNECTION” TERM
`A.
`
`Avi fails to justify a negative limitation and ignores critical intrinsic
`evidence contradicting its proposal
`
`Avi contends that the “transport layer connection” term means “connection at the
`
`transport layer between two devices such that there is no application layer connection between
`
`those two devices” (emphasis added). In arguing its construction, Avi reveals that it seeks to
`
`impose a complete prohibition against an intermediary device modifying or otherwise interacting
`
`with the request and response messages at the application layer. See D.I. 102 at 16 (“The
`
`specification … limit[s] the present invention to an intermediate device that does not interact
`
`with the application layer. Avi’s construction thus embodies this requirement in the term
`
`‘transport layer connection,’ …”). Avi’s negative limitation, which to Avi means a complete
`
`prohibition against any application layer interaction, should be rejected.
`
`Avi’s brief is silent on the most relevant intrinsic evidence on this point, the common
`
`specification’s disclosure of a preferred embodiment featuring a keep-alive injection at the
`
`application layer. As the specification explains, a keep-alive injection occurs where the claimed
`
`intermediary device inserts a “keep-alive” command into the forwarded application-layer
`
`request. See, e.g., ’493 patent at 9:18-19 (“interface unit 202 inserts “Connection: Keep-Alive”
`
`into the GET packet.”); and 9:48-52 (“To address the addition of the "Connection: Keep Alive"
`
`header…”); see also D.I. 104 (Jones Decl.) at ¶ 60. Further, this detail of a preferred embodiment
`
`was specifically claimed in the priority application of the ’493 and ’120 patents. See, e.g., D.I.
`
`104, Ex. I (’978 patent) at claim 10 (“inserting, by the interface unit, information in the first
`
`request of the first client to indicate to the server to keep a transport layer connection open”),
`
`thus showing that the patentee did not intend to use the term “transport layer connection” in a
`
`special way that excluded any interaction by the intermediary device at higher layers of the
`
`7
`
`10
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 11 of 22 PageID #: 3612
`
`network stack such as the application layer. In sum, the specification unambiguously discloses an
`
`embodiment where an application-layer request is modified, i.e., an application-layer interaction,
`
`by the intermediary device. Avi’s own constructions would require that a “request” must be an
`
`“application layer message,” and Citrix agrees that “application layer messages” are within the
`
`scope of a “request,” even if the term is not limited as such. Accordingly, injecting a “keep-
`
`alive” into the “request” before forwarding to the server must be an application layer interaction.
`
`For this reason alone, Avi’s construction excluding such interaction is improper because it reads
`
`out a preferred embodiment. See On-Line Techs. v. Bodenseewerk Perkin-Elmer GmBH, 386
`
`F.3d 1133, 1138 (Fed. Cir. 2004) (a construction that “excludes a preferred embodiment from the
`
`scope of the claim is rarely, if ever, correct”).
`
`Next, Avi mischaracterizes the common specification of the Asserted Patents. Avi
`
`contends that the Asserted Patents are about a “novel translation technique” and cites to a
`
`disclosure in the specification that states “[a] significant advantage of this technique is that no
`
`application layer interaction is required.” D.I. 102 at 17-18 (citing to the ’120 patent at 6:31-33
`
`and 6:38-40). Even if this disclosure supported Avi’s argument—which it does not—Avi omits
`
`critical context that shows the language at issue does not even concern the claimed invention.
`
`The entire paragraph is reproduced below:
`
`However, in order to seamlessly splice the client and server connections, a novel
`translation technique was described in detail in the commonly-owned, U.S.
`patent application Ser. No. 09/188,709, filed Nov. 10, 1998, entitled, “Internet
`Client-Server Multiplexer,” referred to herein as “connection multiplexing”
`According to this technique, a packet is translated by modifying its sequence
`number and acknowledgment number at the TCP protocol level. A significant
`advantage of this technique is that no application layer interaction is required.
`
`
`’120 patent at 6:23-32 (emphasis added). This “novel translation technique” and its “significant
`
`advantage” are about a distinct invention related to connection multiplexing in a different patent
`
`8
`
`11
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 12 of 22 PageID #: 3613
`
`application that does not claim priority to or from the Asserted Patents. Avi’s misattribution of
`
`this “significant advantage” to the claims of the Asserted Patents should thus be disregarded.
`
`Avi’s cited caselaw fails to support Avi’s demand that this Court depart from the plain
`
`and ordinary meaning of “transport layer connection.” The Abbott court determined that the
`
`specification of the asserted patent required a departure from the plain and ordinary meaning of a
`
`term because the specification disparaged elements of a proposed construction, only disclosed
`
`embodiments excluding the proposed construction, and was inconsistent with the proposed
`
`construction. See Abbott, 696 F.3d at 1149–50. Similarly, the Federal Circuit in SciMed Life
`
`Systems was persuaded to depart from the plain and ordinary meaning of the term “lumen” based
`
`on the disclosure of a coaxial lumen for “all embodiments of the present invention contemplated
`
`and disclosed” in the asserted patent, i.e., “the specification makes clear that the invention does
`
`not include a particular feature.” SciMed Life Sys., Inc. v. Advanced Cardiovascular Sys., Inc.,
`
`242 F.3d 1337, 1341-45 (Fed. Cir. 2001) (emphasis added). Likewise, the Inpro court was
`
`persuaded to adopt a narrow construction of “host interface” where the only embodiments
`
`disclosed in the specification required a particular type of bus and connection. See Inpro II
`
`Licensing, S.A.R.L. v. T-Mobile, 450 F.3d 1350 (Fed. Cir. 2006).
`
`Avi’s reliance on these cases is misplaced and its argument that there is “consistent
`
`disclosure” to support its construction is mistaken and misleading. As noted above, Avi’s relied-
`
`upon isolated quote of “[a] significant advantage of this technique is that no application layer
`
`interaction is required” is directed to a feature of a distinct invention described in a different
`
`patent application outside of the priority chain of the Asserted Patents and is thus far from the
`
`9
`
`12
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 13 of 22 PageID #: 3614
`
`“consistent disclosure” that Avi claims.6 Moreover, as noted in Citrix’s Opening Brief, even
`
`were this single sentence describing the claimed invention—which it is not—the mere fact that
`
`something is not required does not translate into a conclusion that that thing is prohibited. For
`
`example, the statement “no training is required to use a computer” does not mean “training is
`
`prohibited for using a computer.”
`
`Further, there is no disparagement of the application layer that might support Avi’s
`
`proposal. In fact, the ’493 and ’120 patent specifications disclose the keep-alive injection
`
`embodiment, as explained above, where there is explicit application layer interaction by the
`
`intermediary device. Thus, Avi’s construction would exclude a preferred embodiment described
`
`in the specification. That approach is strongly disfavored. See On-Line Techs., 386 F.3d at 1138.
`
`Finally, a prohibition against application layer interaction is unrelated to the benefits, purposes,
`
`or functioning of the claimed invention, which relates to making transport layer connections
`
`available for reuse faster. See D.I. 104 (Jones Decl.) at ¶¶ 43-46. There is no reason faster
`
`connection reuse depends on or requires a prohibition on application layer interaction, and Avi
`
`has not purported to show that it does. For any of these independent reasons, Avi’s proposed
`
`construction should be rejected.
`
`
`6 Indeed, Avi takes inconsistent positions between its Opening Brief before this Court and in its
`IPR petitions. For example, Avi’s statement to the PTAB that “transport layer connection…could
`alternatively be construed more broadly to include any connection that includes a transport layer
`connection, even if there are higher layer connections between the devices” constitutes a tacit
`admission that there is no “consistent disclosure” of transport layer connections excluding the
`application layer or other higher layer connections. D.I. 104, Ex. J (’493 IPR Petition) at 22; id.
`Ex. K, (’120 IPR Petition) at 20. Notably, Avi made no attempt in its Opening Brief to reconcile
`this statement to the PTAB with its assertions here, as it failed to even disclose this inconsistent
`position to the Court. See generally D.I. 102 at 16-20.
`
`10
`
`13
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 14 of 22 PageID #: 3615
`
`B.
`
`Avi’s mischaracterizations of file histories
`
`Avi’s reliance on the file history of a related patent as well as one of the Asserted Patents
`
`provides no support for its proposed negative claim limitation. Citrix addresses each of these two
`
`file histories in order.
`
`
`
`The ’978 file history
`(a)
`
`The Roberts Reference
`
`Avi’s prosecution history evidence from U.S. Patent 7,801,978 (“the ’978 patent”) does
`
`not support Avi’s proposed negative limitation. Avi cites to the applicant’s comments
`
`distinguishing U.S. Patent 6,295,551 to Roberts (“Roberts”), and a claim amendment adding
`
`“transport layer” in front of the term “connection.” D.I. 102 at 18-20 (citing to Applicant’s Nov.
`
`22, 2005 Amendment and Remarks in the ’978 patent’s file history). Neither of these excerpts
`
`provides any support for Avi’s contention that the applicants intended to give the term “transport
`
`layer connection” a special meaning that excludes application layer interaction.
`
`Applicants often make claim amendments, arguments, or both to traverse rejections based
`
`on a patent examiner’s broadest reasonable interpretation of claim terms. That is precisely what
`
`happened during prosecution of the ’978 patent when the applicant clarified that a generic
`
`network such as the Internet could not be the claimed intermediary device (or “interface unit,” as
`
`used in the then-pending claims), and that connections to such a generic network in this broadest
`
`sense were not the sort of connections subject to reuse according to the claimed invention.
`
`Nothing in this file history re-defined “transport layer” to exclude interaction with higher layers
`
`such as the application layer or exclude application layer “connections” between devices.
`
`Specifically, the examiner of the ’978 patent application identified a network (referred to
`
`as network 16 and depicted as a cloud) in FIGS. 1 and 6 of Roberts as the claimed “interface
`
`unit,” and noted the “connections” between the network and devices such as computers and
`
`11
`
`14
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 15 of 22 PageID #: 3616
`
`servers. Jones Supp. Decl., Ex. L (’978 patent file history), Final Office Action dated August 22,
`
`2005 at 6-8; see also id. at 7 (“In Figure 1, it should be obvious that there is a connection
`
`between the first client [computer] and the network and there is a second connection between the
`
`network and the server”). Roberts disclosed that “network 16 is the Internet.” Jones Supp. Decl.,
`
`Ex. N (Roberts) at 7:5:
`
`
`
`Id. at Fig. 1. The examiner rejected the then-pending claims on the basis that “it should be
`
`obvious to one of ordinary skill in the art that network 16 [i.e., the Internet as disclosed by
`
`Roberts] is the interface unit as claimed.” Jones Supp. Decl., Ex. L, Final Office Action dated
`
`August 22, 2005 at 7. The examiner thus broadly interpreted the then-recited term “interface
`
`unit” to read on a generic network, such as the Internet.
`
`To clarify and refute the examiner’s interpretation of the then-pending claims, the
`
`applicant added “transport layer” before “connection” to make clear that the claimed connections
`
`that would be reused were not simply connections in the broadest sense to or from a generic
`
`network, such as the Internet, acting as an intermediary, but rather were transport layer
`
`connections. Jones Supp. Decl., Ex. L, Applicant’s Amendment and Remarks dated Nov. 22,
`
`2005. Based on the new claim language, the applicant explained that “Roberts does not disclose
`
`opening a first transport layer connection between a first client and an interface unit, opening a
`
`second transport layer connection between the interface unit and a server, and allowing the first
`
`12
`
`15
`
`

`

`Case 1:17-cv-01843-LPS Document 116 Filed 04/30/19 Page 16 of 22 PageID #: 3617
`
`client to access information on the server via the second [transport layer] connection.” Id. at 5.
`
`The applicant further argued: “Roberts neither discloses, teaches nor suggests anything other
`
`than establishment of a traditional network connection, which has only a single transport layer
`
`connection. As such, Roberts does not provide access to a server by a client via two transport
`
`layer connections as in the claimed invention.” Id. (emphasis in original).
`
`The addition of “transport layer” to specify the type of connections required does not
`
`support an exclusion of any application layer “connection” between devices or support a
`
`prohibition on any application layer “interaction.” This is clear from the patent specification
`
`itself, where “a flowchart depicting the operation of the present invention” translates “message
`
`traffic is in the form of TCP/IP packets,” a protocol “suite [that] supports many applications,
`
`such as Telnet, File Transfer Protocol (FTP), e-mail, and HTTP.” ’493 patent at 5:30-41. The
`
`specification further states that “the concepts of the present invention apply equally well to other
`
`TCP/IP applications.” Id. The specification thus exp