ESN LLC v. Cisco Systems, Inc. et al

Filing 83

CLAIM CONSTRUCTION SUR-REPLY BRIEF filed by Cisco Systems, Inc., Cisco-Linksys LLC. (Attachments: # 1 Exhibit R, # 2 Exhibit S, # 3 Exhibit T, # 4 Exhibit U)(Smith, Kevin)

ESN LLC v. Cisco Systems, Inc. et al

Doc. 83

IN THE UNITED STATES DISTRICT COURT FOR THE EASTERN DISTRICT OF TEXAS TEXARKANA DIVISION

ESN, LLC, Plaintiff, v. CISCO SYSTEMS, INC., and CISCO-LINKSYS, LLC, Defendants.

) ) ) ) ) ) ) ) ) ) )

Civil Action No. 5:08-cv-20-DF JURY TRIAL DEMANDED

DEFENDANTS' SUR-REPLY ON CLAIM CONSTRUCTION

Dockets.Justia.com

Defendants Cisco-Systems, Inc. and Cisco-Linksys, LLC (collectively "Cisco") submit this sur-reply in support of their proposed constructions of the asserted claims and in opposition to ESN's request to strike the declaration of Dr. Eric Burger. This sur-reply is necessary to address ESN's request to strike and arguments raised for the first time in its reply brief. I. THERE ARE NO GROUNDS FOR EXCLUDING DR. BURGER'S DECLARATION AND TESTIMONY. In its reply, ESN urges this Court to strike the expert declaration of Dr. Eric Burger and limit his testimony at the claim construction hearing. ESN contends that Dr. Burger's opinions were not disclosed as required by Patent Local Rule 4-3(d) because Cisco's disclosure merely recited various sections in RFC 2543 and stated that "SIP," "SIP user agent," and "SIP proxy server" would be understood by those of ordinary skill in the art in accordance with RFC 2543. (ESN's Reply at 14-15.) This is a mischaracterization of the three-and-one half page summary of Dr. Burger's anticipated testimony Cisco served in its Rule 4-3(d) disclosure. (ESN Ex. N.) Cisco's Rule 4-3(d) disclosure states that Dr. Burger will testify to the following, each of which are covered in his declaration: (1) one of ordinary skill in the art would understand SIP to mean "Session Initiation Protocol as set forth in IETF 2543" (Burger Decl. ¶¶ 11-13; ESN Ex. N at 3); (2) the definitions of SIP network elements contained in RFC 2543's definitions section, which provides a brief description of the roles of a SIP user agent and a SIP proxy server, are not sufficient for one of ordinary skill in the art to understand their functionality (Burger Decl. ¶¶ 14, 17, 19, 20; ESN Ex. N at 3); (3) one of ordinary skill in the art must consult the rest of the document to determine the expected behavior and protocols used by each network element (Burger Decl. ¶¶ 15-17 & 20-21; ESN Ex. N at 3); and (4) the permissible behavior of a SIP user agent is elaborated in Section 11, and the permissible behavior of a SIP proxy server is elaborated in Section 12.3 of the document (Burger Decl. ¶¶ 17, 22-26; ESN Ex. N at 3). ESN contends Dr. Burger's opinion that, in a SIP Proxy Server, "the To, From, Call-ID, and Contact tags are copied exactly from the original request" was not disclosed in the summary even though Cisco's Rule 4-3(d) disclosure clearly states that he would testify that a SIP proxy

1

server must operate in accordance with RFC 2543 § 12.3, and this quotation comes directly from the identified section. Dr. Burger further explains that this limitation is what distinguishes a SIP Proxy Server from a "Back-to-Back User Agent." ESN was on notice that Cisco considered the copying of certain message tags exactly as they are received to be a SIP Proxy Server requirement.1 ESN was also on notice of Cisco's intent to rely on Dr. Burger's testimony to establish how one of ordinary skill in the art would understand "SIP Proxy Server." ESN had ample time to depose Dr. Burger regarding his opinions but chose not to do so. Rather than questioning and challenging Dr. Burger's opinions on the merits, ESN is asking this Court to simply strike them.2 Because Cisco's Rule 4-3(d) disclosure contains "a summary of each opinion to be offered in sufficient detail to permit a meaningful deposition of" Dr. Burger, ESN's request should be denied. II. ESN MISSTATES THE IETF STANDARDS PROCESS. ESN accuses Cisco of "mischaracterizing" RFC 2543 as an industry standard. (ESN's Reply at 2.) ESN asserts that a Proposed Standard approved by the Internet Engineering Steering Group ("IESG") that is published as a Request For Comment is not an IETF standard, and therefore implicitly it cannot be accepted by persons of skill in the art as an industry standard. ESN's argument is both factually incorrect and irrelevant to the parties' claim construction dispute. See Ex. R at 2 (email from Cisco to ESN regarding Cisco's proposed construction of SIP proxy server, stating: "SIP Proxy Server - An intermediary program that acts as both a server and a client. . . . The forwarded SIP request message contains exactly the same `To,' `From,' `Call-ID' and `Contact' tags as the original SIP request received by the SIP proxy server. Note: the last line of this proposed construction is from para. 12.3.1 (page 98) of RFC 2543)."). ESN's motion to strike Dr. Burger's declaration should also be denied because it does not comply with Local Rule CV-7(a). That Rule states: "All motions, unless made during a hearing or trial, shall be in writing, filed as a separate document, conform the to the requirements of Local Rules CV-5 and CV-10, and shall be accompanied by a separate proposed order for the judge's signature." (emphasis added). ESN did not file its motion to strike as a separate document; it raised the issue in a reply brief on claim construction. Nor did it file a proposed order on the issue.
2 1

2

A.

RFC 2543 Was an Industry Standard at the Time of the Application for the `519 Patent.

ESN's argument that an IETF "Proposed Standard" is not recognized as a standard is based on incomplete and misleading quotations from RFC 1796. When the quoted passages are read in context they in fact refute ESN's arguments and unequivocally establish that IETF recognizes Proposed Standards, such as RFC 2543, as standards. The IETF places each Requests For Comment in one of four categories: Informational, Experimental, Standards Track, or Historic. The "Standards Track" category includes Proposed Standards (such as RFC 2543), Draft Standards, and Internet Standards: It is regrettably well spread misconception that publication as an RFC provide some level of recognition. It does not, or at least not any more than the publication in a regular journal. In fact, each RFC has a status, relative to its relation with the Internet standardization process: Informational, Experimental, or Standards Track (Proposed Standard, Draft Standard, Internet Standard), or Historic. This status is reproduced on the first page of the RFC itself . . . . (ESN Ex. H. (emphasis added).) RFC 1796, the document on which ESN relies, expressly explains that not all RFCs are considered "standards." Specifically, Requests For Comment in the Informational, Experimental, and Historic categories are not on the Standards Track and are not, therefore, considered standards. Indeed, the very passage that ESN quotes in its brief explains as much except that ESN deliberately omits the crucial second paragraph, which explains that only the Informational and Experimental RFCs do not constitute standards:

(ESN Ex. I.)

3

By contrast with the Informational and Experimental RFCs, "Proposed Standards," like RFC 2543, are considered standards by the IETF. Request For Comment 4677, "The Tao of IETF," makes this clear: There are six kinds of RFCs: [p]roposed standards, [d]raft standards, Internet standards (sometimes called "full standards"), informational documents, experimental protocols, historical documents. Only the first three (proposed, draft, and full) are standards within IETF. .... The procedure for creating and advancing a standard is described in [BCP 9]. After an Internet Draft has been sufficiently discussed and there is rough consensus that what it says would be useful standard, it is presented to the IESG for consideration. .... If the IESG approves the [Internet] draft to become an Internet standard, they ask the RFC Editor to publish it as a Proposed Standard. After it has been a Proposed Standard for at least six months, the RFC's author . . . can ask for it to become a Draft Standard. .... Don't be surprised if a particular standard doesn't progress from Proposed to Draft. In fact, most of the standards in common use are Proposed Standards and never move forward. This is because no one took the time to try to get them to Draft, or some of the normative references in the standard are still at Proposed Standard, or it may be that everyone found more important things to do. (Ex. S at 30-35 (emphasis added).) RFC 4677 therefore explicitly states that Proposed Standards are "standards within the IETF." By 2001, RFC 2543 was not only considered a standard by the IETF, it had been well accepted as an industry standard by the VoIP community.3 The significance of SIP at the relevant time is best articulated by Vint Cerf,4 who proclaimed: "SIP is probably the third great protocol of the Internet, after TCP/IP and HTTP." (Ex. U at xvii.) ESN contention that RFC See Ex. T at 124 ("Since its approval in early 1999 as an official standard, the Session Initiation Protocol (SIP) has gained tremendous market acceptance for signaling communications services on the Internet."). Vint Cerf, the person most often called "the father of the Internet" has been well recognized for the contributions he has made to the development of the Internet, including the National Medal of Technology and the Presidential Medal of Freedom. (See http://en.wikipedia.org/wiki/Vint_Cerf.)
4 3

4

2543 did not define a standard is, therefore, incorrect. B. ESN's Argument that RFC 2543 Is Not a "Standard" Is Irrelevant.

ESN's argument that RFC 2543 is not a "standard" is, in any event, a red herring. As stated in Cisco's opening brief, the `519 Patent and its prosecution history define the claim term "SIP" as the protocol disclosed in RFC 2543. The Patent's definition is not contingent on whether or not RFC 2543 is a "standard." ESN, nevertheless, contends that determining whether RFC 2543 is a "standard" or not is necessary to distinguish the cases cited by Cisco where courts have construed claim terms to require compliance with an industry standard. (See ESN Reply at 5 & Cisco's Opening Brief at 13 n.5.) Cisco cited these cases to refute ESN's position that construing a claim term to require compliance with an extrinsic document somehow "require[d] the jury to perform certain claim construction duties." (ESN's Claim Construction Brief at 29-30.) ESN now argues that these cases are inapposite because RFC 2543 is not a "standard." ESN provides no reasoning or caselaw that would suggest that a claim term can only be construed in light of documents that are industry standards. Where, as in this case, a patent's specification and prosecution history specifically define a claim term in light of an extrinsic document, that term should be construed in light of that document whether or not it is a standard. ESN's unsupported, unreasoned position to the contrary should be rejected. CONCLUSION Cisco respectfully request that the Court adopt its construction of the disputed claim terms and deny ESN's request to strike the Burger Declaration. Dated: May 8, 2009 Respectfully submitted, /s/ Kevin A. Smith

5

POTTER MINTON A Professional Corporation MICHAEL JONES Tex. Bar No. 10929400 [e-mail] 110 N. College, Suite 500 (75702) P.O. Box 359 Tyler, Texas 75710 Telephone: [phone] Facsimile: [phone] QUINN EMANUEL URQUHART OLIVER & HEDGES, LLP CHARLES K. VERHOEVEN LEAD COUNSEL Cal. Bar No. 170151 [e-mail] KEVIN A. SMITH Cal. Bar No. 250814 [e-mail] MATTHEW D. CANNON Cal. Bar No. 252666 [e-mail] 50 California St., 22nd Floor San Francisco, California 94111 Telephone: [phone] Facsimile: [phone] VICTORIA F. MAROULIS Cal. Bar No. 202603 [e-mail] SAYURI K. SHARPER Cal. Bar No. 232331 [e-mail] 555 Twin Dolphin Dr., Suite 560 Redwood Shores, California 94065 Telephone: [phone] Facsimile: [phone] Attorneys for Defendants Cisco Systems, Inc. and Cisco-Linksys, LLC

6

CERTIFICATE OF SERVICE I hereby certify that on the date this proof of service is signed below, I served the foregoing: DEFENDANTS' SUR-REPLY ON CLAIM CONSTRUCTION by email and via the Court's Electronic Filing System to George P. McAndrews [e-mail] Thomas J. Wimbiscus [e-mail] Peter J. McAndrews [e-mail] Gerald C. Willis [e-mail] Paul W. McAndrews [e-mail] Matthew N. Allison [e-mail] Holly Mack [e-mail] Eric M. Albritton [e-mail] T. John Ward [e-mail] Date: May 8, 2009 /s/ Kevin A. Smith

7