ESN LLC v. Cisco Systems, Inc. et al

Filing 78

Plaintiff ESN, LLC's Reply Brief on Claim Construction filed by ESN LLC. (Attachments: # 1 Exhibit F, # 2 Exhibit G, # 3 Exhibit H, # 4 Exhibit I, # 5 Exhibit J, # 6 Exhibit K, # 7 Exhibit L, # 8 Exhibit M, # 9 Exhibit N, # 10 Exhibit O)(McAndrews, Peter)

ESN LLC v. Cisco Systems, Inc. et al

Doc. 78

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

PLAINTIFF ESN, LLC'S REPLY BRIEF ON CLAIM CONSTRUCTION

Dockets.Justia.com

TABLE OF CONTENTS I. II. III. INTRODUCTION .....................................................................................................................1 CISCO MISREPRESENTS THE BACKGROUND AND TECHNOLOGY OF THE `519 PATENT ....................................................................................................................................1 CONSTRUCTION OF THE DISPUTED CLAIM TERMS AND PHRASES .........................3 A. B. C. D. E. F. G. H. I. J. K. L. M. IV. V. "network device" ...........................................................................................................3 "telephone line interface" ..............................................................................................4 "computer data interface" ..............................................................................................4 "SIP" ..............................................................................................................................5 "SIP agents" ...................................................................................................................6 "SIP user agent".............................................................................................................8 "the instructions causing the network device to provide a SIP user agent to represent a non-SIP telephone that uses the telephone line interface" ..........................8 "SIP proxy server" .........................................................................................................9 "SIP proxy server that mediates all SIP communications over the broadband network interface involving the non-SIP telephone"...................................................10 "system management platform"...................................................................................12 "shared packet network" ..............................................................................................12 "route telephone calls in a peer-to-peer fashion over the shared packet network"......13 "SIP proxy server for devices using the telephone line interface and for devices using the computer data interface" ..............................................................................14

CISCO'S EXPERT DECLARATION SHOULD BE STRICKEN.........................................14 CONCLUSION........................................................................................................................15

i

TABLE OF AUTHORITIES Page(s) Cases ACTV, Inc. v. Walt Disney Co., 326 F.3d 1082 (Fed. Cir. 2003)............................................................................................... 10 British Telecomms. PLC v. Prodigy Commc'ns Corp., 189 F. Supp. 2d 101 (S.D.N.Y. 2002)..................................................................................... 11 Exxon Research & Eng'g Co. v. United States, 265 F.3d 1371 (Fed. Cir. 2001)................................................................................................. 7 Halliburton Energy Servs. Inc. v. M-I LLC, 514 F.3d 1244 (Fed. Cir. 2008)................................................................................................. 7 Invitrogen Corp. v. Biocrest Mfg. L.P., 424 F.3d 1374 (Fed. Cir. 2005)................................................................................................. 7 NTP, Inc. v. Research in Motion, Ltd., 418 F.3d 1282 (Fed. Cir. 2005)............................................................................................... 14 Warner-Jenkins Co. v. Hilton Davis Chemical Co., 520 U.S. 17 (1997).................................................................................................................. 11 Statutes 35 U.S.C. § 282............................................................................................................................... 6

ii

I.

INTRODUCTION Plaintiff ESN, LLC ("ESN") submits this Reply Brief in support of its proposed claim

construction of the asserted claims of U.S. Patent No. 7,283,519 ("the `519 Patent") (ESN Ex. A.).1 ESN's proposed claim constructions are supported by the intrinsic evidence and relevant extrinsic evidence. The claim constructions proposed by the Defendants, Cisco Systems, Inc. and Cisco-Linksys, LLC (collectively, "Cisco"), violate established rules of claim construction ­ in an apparent effort to re-define the claims to support its non-infringement defenses in this case. Cisco's proposed constructions, inter alia, (1) selectively rely on or ignore the intrinsic evidence of the intended meaning and scope of certain claim terms; (2) improperly attempt to require the jury to perform claim construction; (3) improperly attempt to resolve the factual issue of infringement; and (4) rely on extrinsic expert opinions that were not previously disclosed in violation of the Local Patent Rules and this Court's Docket Control Order. For the reasons further discussed below, the Court should reject Cisco's proposed constructions and adopt those proposed by ESN. II. CISCO MISREPRESENTS THE BACKGROUND AND TECHNOLOGY OF THE `519 PATENT Cisco's discussion of the background of the inventions of the `519 Patent is misleading. Cisco uses the term "intelligent" in the broadest, generic sense in order to be able to claim that prior art telecommunications systems employed SIP in a manner that placed "intelligent" devices at the edge of the network on a customer's premise. However, this ignores the very specific meaning of the term "intelligent" as used in the `519 Patent to describe a premise-based device that has a SIP proxy server to perform call control. (See ESN Ex. A at 11:55-59 ("Intelligent participation refers to the ability of a connectivity element to operate both as [a] SIP network signaling endpoint and as a call control agent capable [of] complex call control operations.").)

Exhibits A-E of ESN's Opening Claim Construction Brief ("ESN Br.") will be cited as ESN Ex. A - E. Exhibits to this Reply Brief will begin at ESN Ex. F. Exhibits A-Q of Defendant's Opposition Brief On Claim Construction ("Opp'n Br.") will be cited as Cisco Ex. A - Q.

1

1

Indeed, the very reference2 cited by Cisco to support its argument that prior art SIP systems did not need centralized intelligence, states that "[a] SIP architecture requires a proxy server to route calls to other entities ...." (Cisco Ex. E.) Cisco has not pointed to any prior art that placed a SIP proxy server in a customer premise-based device to mediate (i.e., perform intelligent call control for) SIP communications as disclosed and claimed in the `519 Patent. Cisco grossly overstates the significance of non-imperative3 implementation details of RFC 2543. First, Cisco mischaracterizes RFC 2543 as the "first SIP standard document" (Opp'n Br. 2), a "standards document" (Opp'n Br. 2 n.1), an "industry standard" (Opp'n Br. 13 n.5), and "the SIP standard" (Opp'n Br. 18.) In its short explanation of the standards process, Cisco implies that such a document goes directly from "Internet-Draft" to an "IETF standard." (Opp'n Br. 2 n.1.) This is not true. The truth is that after an Internet-Draft becomes a standards track RFC, it goes through three stages: "Proposed Standard," then "Draft Standard", and then finally "Standard." (ESN Ex. F, RFC 2026 ­ The Internet Standards Process ­ Revision 3 (Oct. 1996), at p. 11.) RFC 2543 never went beyond a "Proposed Standard." (See ESN Ex. G, Proposed Standards, http://www.rfc-editor.org/categories/rfc-proposed.html (last visited May 1, 2009) (showing RFC 2543 was a "Proposed Standard" when updated by RFC 3261, currently only a "Proposed Standard.").) The RFCs themselves reiterate this reality time and time again. RFC 1796 states: It is regrettably a well spread misconception that publication as an RFC provides 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 . . . (ESN Ex. H, RFC 1796 ­ Not All RFCs are Standards (Apr. 1995), at p. 1; see also ESN Ex. F at p.8 ("It is important to remember . . . that not all standards track documents reach the level of

2

It should be noted that this reference, which Cisco relies on to describe the purported state of the prior art, is dated October 2004 ­ over two years after the `519 Patent was filed. The term "imperative" is a term of art in RFC's used to indicate the importance of a particular requirement using terms such as "MUST," "SHOULD," "MUST NOT," etc. For a more detailed discussion of "imperatives" see infra, Section III.H. (See also ESN Ex. L, RFC 2119 at p.2; ESN Ex. J, RFC 4677 at 35-36.)

3

2

Internet Standard.").) The FAQ section of the RFC Editor website attempts to make the warning clear: 3. Are all RFCs Internet standards documents? In a word, "NO!". ... This is important to understand, because unscrupulous marketeers and a careless trade press sometimes falsely suggest that every RFC represents a standard, or that all standards have equal weight. The relationship among Internet technical specifications is often complex. (ESN Ex. I, RFC Frequently Asked Questions, http://www.rfc-editor.org/rfcfaq.html#allstds (last visited May 1, 2009) (emphasis added).) While an RFC is in the "Proposed Standard" stage, it is expected that implementations may not be perfectly compliant with every detail of the "Proposed Standard," particularly where the detail is not stated as an "imperative" for purposes of interoperability. (ESN Ex. J, RFC 4677 ­ The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force (Sep. 2006), at p. 34-36.) In fact, the RFCs command that "[i]mplementors should treat Proposed Standards as immature specifications." (ESN Ex. F at p. 13.) Cisco even references the "SIP Forum" and "SIP interoperability events" which would serve to resolve differences in implementations. (Opp'n Br. 3; Cisco Ex. A.) Mr. Girard attempted to accurately describe this to Cisco's counsel during his deposition when he described RFC 2543 as "guidelines," "guardrails," and a "document[] in progress." (Cisco Ex. I at 153:8-9, 153:15-21, 267:17.) III. CONSTRUCTION OF THE DISPUTED CLAIM TERMS AND PHRASES A. "network device" Cisco's Construction A single piece of equipment that transmits and receives data over the broadband network.

ESN's Construction A "network device" is a collection of hardware and software, connected to a network, which together make up a single logical node on the network.

Cisco's arguments regarding this term actually support ESN's proposed claim construction, which allows the "network device" to be comprised of multiple physical enclosures

3

or a single physical enclosure (as required only by dependent claim 12). Indeed, Cisco plainly admits that "a Network Device that includes several hardware subcomponents may be in multiple physical enclosures if a manufacturer chooses to construct the device in that manner." (Opp'n Br. 8.) Cisco further acknowledges that a telephone is made up of multiple physical enclosures ­ a telephone handset and base station ­ but would still be considered a single device. (Id.) In view of these concessions, Cisco cannot maintain its proposed construction that limits a "network device" to "a single piece of equipment."4 B. "telephone line interface" Cisco's Construction Hardware subcomponent of the network device that is used to connect telephone stations that do not support IP protocols.

ESN's Construction A "telephone line interface" is a hardware subcomponent that provides a physical interface for connecting non-IP telephones (telephones that do not natively support IP network signaling) to the network device. A "telephone line interface" converts device-level telephone signals to/from digitally encoded audio streams and digitally encoded device states (e.g., off-hook, onhook, and dialed digits.)

The parties agree that the `519 Patent at 42:46-52 partially defines the term "telephone line interface," but Cisco's claim construction inexplicably ignores the definition provided when this term is first introduced in the `519 Patent at 23:4-8. This passage states that: The TELEPHONE LINE INTERFACE [1.9] converts device-level telephone signals (e.g. POTS telephone signals) to/from digitally encoded audio streams and digitally encoded device states (e.g. off-hook, on-hook, DTMF digits)." (ESN Ex. A at 23:4-8.) Only ESN's construction comports with this definition. C. "computer data interface" Cisco's Construction Hardware subcomponent of the network device that is used to connect one or more terminal devices to support bidirectional IP data

ESN's Construction A "computer data interface" is a hardware subcomponent of the network device that is used to connect one or more computer
4

To the extent Cisco seeks to argue at this stage that a "single piece of equipment" may be contained in multiple enclosures, then use this construction to limit the claim to a single enclosure later, it should clearly be precluded.

4

workstations to allow bidirectional IP data paths used for common data transport to/from the one or more computer workstations.

communication between the network device and the terminal devices.

While the parties are close to agreement on the construction of "computer data interface" based on the `519 Patent at 41:16-23, Cisco's construction includes an erroneous interpretation of the definition provided for "computer workstation." While ESN agrees with Cisco that, as described in the `519 Patent at 59:51-59, the "computer workstations" connected to the "computer data interface" are not limited to desktop personal computers, this does not mean that any type of terminal device is encompassed by this term. Rather, the cited portion of the `519 Patent (59:51-59) merely acknowledges that other types of computers capable of communicating IP data, e.g., laptops, handhelds, etc. may be connected to the "computer data interface." Moreover, the claim recites a "computer data interface," not a "terminal" interface. D. "SIP" Cisco's Construction Session Initiation Protocol as set forth in IETF RFC 2543.

ESN's Construction The term SIP is shorthand for Session Initiation Protocol, which is a communications protocol for creating, modifying and terminating sessions with one or more participants. These sessions may include Internet telephone calls, Internet multimedia conferences, and other types of multimedia distribution.

Cisco asks the Court to incorporate a 154-page Proposed Standard into each construction using "SIP." As stated above, Cisco has attempted to mislead the Court by referring to RFC 2543 as if it was a final "industry standard." See supra, Section II. In light of the fact that RFC 2543 is not, and was not, an "industry standard," Cisco's case law is inapplicable. (See Opp'n Br. n.5 (citing all cases in which Courts have adopted actual standards into claim constructions).) As a Proposed Standard, RFC 2543 is a relevant piece of extrinsic evidence, but it would be highly improper to require every implementation detail to be met perfectly. Dr. Burger states that one must build in accordance with RFC 2543 to achieve compliance and interoperability. While Cisco contends that one would need to follow every

5

requirement to build an "RFC 2543 compliant" implementation, one would not need to do this to achieve interoperability or to practice "SIP." As this RFC was a Proposed Standard, one of ordinary skill would understand that interoperability was of the utmost importance, but if a transparent implementation detail could be improved upon, there would be no harm in making such an improvement because it would serve the fundamental goals of the RFC, which literally means "Request For Comment." This is addressed in further detail infra in Section III.H. Further, Cisco argues against a straw man in its criticisms of ESN's construction. First, Cisco contends that ESN's construction would read on competing protocols such as H.323. (Opp'n Br. 14-15.) However, ESN's construction of "SIP" specifies that it is "Session Initiation Protocol," which precludes other protocols. Second, Cisco claims that ESN is attempting to read its claims on future versions of SIP. (Opp'n Br. 15-16.) ESN is not attempting to read its claims on any future version of SIP; rather, it is Cisco's products that are accused of infringement. If the accused products operate in compliance with a later drafted Proposed Standard, this is irrelevant to whether the accused products still practice the inventions claimed in the `519 Patent. In fact, it is Cisco who is trying to incorporate future versions of SIP into its constructions. (See Opp'n Br. 21-22 (using RFC 3261 to construe "SIP Proxy Server" as not including a B2BUA).) Contrary to Cisco's contentions, ESN is not ignoring RFC 2543 and attempting to read its claims on competing protocols. Instead, ESN's construction is plainly incorporating the fact that as the RFCs point out, industry practice would be to substantially comply with this Proposed Standard, paying particular attention to the imperatives which promote interoperability. E. "SIP agents" Cisco's Construction This term is indefinite. It is neither used nor defined in the specification. It does not have an ordinary meaning, and it is not a term of art that is discernable to one of ordinary skill in the art.

ESN's Construction A SIP agent is a software entity that provides a SIP function and acts on behalf of a person, thing or other software entity. A SIP user agent and a SIP proxy server are examples of SIP agents.

Cisco argues that the term "SIP agents" is indefinite without ever acknowledging the high 6

burden they face. The claims of the `519 Patent are presumed valid. See 35 U.S.C. § 282. Invalidating a claim for indefiniteness requires "an exacting standard." Halliburton Energy Servs. Inc. v. M-I LLC, 514 F.3d 1244, 1249 (Fed. Cir. 2008). Claims are only indefinite if they are "insolubly ambiguous, and no narrowing construction can properly be adopted." Exxon Research & Eng'g Co. v. United States, 265 F.3d 1371, 1375 (Fed. Cir. 2001). "Even if it is a formidable task to understand a claim, and the result not unanimously accepted, as long as the boundaries of a claim may be understood it is `sufficiently clear to avoid invalidity [for] indefiniteness.'" Invitrogen Corp. v. Biocrest Mfg. L.P., 424 F.3d 1374, 1383 (Fed. Cir. 2005), citing Exxon, 265 F.3d at 1375. Discerning the boundaries of the term "SIP agents" can hardly be described even as a formidable task, much less a task that leads to insoluble ambiguity. One does not need to go any further than the plain language of the claim to determine the meaning of the term "SIP agents." The usage of the term SIP agent in claim 9 comports to the letter with the classic definition of "agent." (See ESN Br. at 11-12.) The term "agent" refers to "an entity acting on behalf of another" (ESN Ex. D, Newton's Telecom Dictionary at p. 445) and the plain reading of the claim indicates that the term "SIP agents" is used as a superset to introduce the members "SIP user agent" and "SIP proxy server" found in the claim elements immediately following the term "SIP agents." A SIP user agent and a SIP proxy server are both SIP functional entities that act on behalf of another, i.e., the SIP user agent "represent[s] a non-SIP telephone" (as expressly stated in claim 9) and a SIP proxy server is "[a]n intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients." (ESN Ex. A at 62:40-42.) In the context of the claim, the term "SIP agents" is hardly insolubly ambiguous ­ it could not be clearer. Cisco acknowledges that "the starting point in any claim construction analysis is the words of the claims themselves" (Opp'n Br. 6), yet does not acknowledge the rest of the claim
5

Cisco's criticism of the definition of "agent" found in Newton's Telecom Dictionary is not only based on the false premise that all of the terminology in the `519 Patent is SIP specific, but it also demonstrates that Cisco has no shame in altering its position 180 degrees. Cisco cited Newton's Telecom Dictionary as an authoritative source of extrinsic evidence in its L.R. 4-2 Preliminary Claim Constructions and Extrinsic Evidence. (ESN Ex. O.)

7

itself when construing this term. F. "SIP user agent" Cisco's Construction An application that contains both a user agent client and user agent server that operates in accordance with IETF RFC 2543.

ESN's Construction A "SIP user agent" is a SIP network signaling endpoint.

As a Proposed Standard, RFC 2543 is a relevant piece of extrinsic evidence, but would be highly improper to incorporate, with its countless limitations, into a claim construction. See supra, Section II. The fundamental requirement of a "SIP user agent" as recognized by the `519 Patent is that it is a SIP network signaling endpoint. (See ESN Ex. A at 14:2-7 (referring to a "SIP user agent" as a "SIP network signaling endpoint"); ESN Ex. C at 8-9 (referring to a "user agent" as an "Internet endpoint").) Again, as in the "SIP" construction, ESN's construction of this term reflects the fact that the industry would understand that a "SIP user agent" should substantially comply with RFC 2543 noting any imperative details that promote interoperability. G. "the instructions causing the network device to provide a SIP user agent to represent a non-SIP telephone that uses the telephone line interface" Cisco's Construction Software in the network device provides each telephone station attached to the telephone line interface with a SIP user agent to perform all the required SIP signaling in accordance with IETF RFC 2543.

ESN's Construction The instructions cause the network device to provide a "SIP user agent" (a "SIP user agent" is a SIP network signaling endpoint) for the purpose of representing a non-IP telephone that is attached to the network device through the telephone line interface. Because the non-IP telephone is not natively capable of direct participation in SIP communications, it relies on the SIP user agent (provided by the network device) to participate in SIP communications on its behalf, thereby enabling the nonSIP telephone to indirectly participate in SIP communications.

Cisco does not appear to generally disagree with ESN's construction of this element because its arguments regarding this element are limited to advocating the inclusion of the loaded phrase "to perform all the required SIP signaling in accordance with IETF RFC 2543." ESN disagrees with the inclusion of this phrase because, as explained in Sections III.D, III.F and

8

III.H of this Reply Brief, one of skill in the art would understand that SIP devices and systems would only be expected to substantially comply with RFC 2543. H. "SIP proxy server" Cisco's Construction An intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other SIP clients in accordance with IETF RFC 2543.

ESN's Construction A "SIP proxy server" is an intermediary program that acts as both a server and a client for the purpose of making SIP requests on behalf of other SIP clients such as a SIP user agent. SIP requests are serviced internally or by passing them on, possibly after translation, to other servers. A SIP proxy interprets, and, if necessary, rewrites a SIP request message before forwarding it.

The `519 Patent references RFC 2543, but it does not contain any language rising to the level of incorporating all of its limitations into the patent specification. While the `519 Patent explicitly borrows the fundamental definition of "SIP proxy server" from RFC 2543, it does not explicitly incorporate all implementation details of the Proposed Standard. (ESN Ex. A at 62:3845.) Cisco's arguments regarding "SIP proxy server" once again attempt to misconstrue the Internet Standard Process and overreach in characterizing non-essential implementation details of RFC 2543. In his declaration on this topic, Dr. Burger attempts to pull a fast one when he states that "[o]ne of the most important rules that a SIP proxy server must follow is that when forwarding a SIP request message from a SIP user agent, the proxy server must copy the To, From, Call-ID, and Contact tags exactly as it received from the SIP user agent." (Burger Decl. ¶ 23.) RFC 2543 actually states "[t]he To, From, Call-ID, and Contact tags are copied exactly from the original request." (ESN Ex. K at p. 98.) Dr. Burger's quiet insertion of the word "must" is both critically important and blatantly wrong. When drafting an RFC, the author should use "imperatives" (e.g., "MUST") only where a requirement is "actually required for interoperation." (ESN Ex. L, RFC 2119 ­ Key words for use in RFCs to Indicate Requirement Levels (Mar. 1997), at p. 2, ¶6; see also ESN Ex. J, at p. 35-36 (explaining to ensure

9

interoperability the author must be clear in its use of imperatives such as "MUST").) Dr. Burger inserts a "must" into a part of the RFC where one does not exist; in the realm of RFCs this is a vitally important distinction, as the author at the time would have known the significance of choosing to include or omit such an imperative. Yet, shockingly, Dr. Burger also finds the nerve to opine (without support) that this statement is "[o]ne of the most important rules" in the RFC. Cisco's construction and argument are a transparent and premature attempt to argue noninfringement (both literally and under the Doctrine of Equivalents), which at this stage of the litigation is improper. The sources Cisco relies on (Cisco Exs. N-P) post-date the filing date of the `519 Patent, and are irrelevant to claim construction. Further, consideration of RFC 3261 for the term "Back-to-Back User Agent" ("B2BUA"), which appears for the first time in RFC 3261, and "SIP proxy server" is particularly improper because it does not reflect common usage of the term "SIP proxy server" and "B2BUA" but rather seeks to define or redefine them. See ACTV, Inc. v. Walt Disney Co., 326 F.3d 1082, 1090 (Fed. Cir. 2003) (declining to rely on an RFC as extrinsic evidence for claim construction because it does "not reflect common usage" but instead "select[s] language to be used in the future"). As acknowledged by Dr. Burger (Burger Decl. ¶ 26), what is currently called a B2BUA may function in a manner that is similar to a SIP proxy server. For example, while RFC 2543 describes a "stateful" SIP proxy server as "a virtual UAS/UAC," RFC 3261 describes a "B2BUA" as "a concatenation of a UAC and UAS." (ESN Ex. K at p. 98; ESN Ex. M, at p. 20.) Therefore, any construction that would preclude a finding of infringement, either literally or under the Doctrine of Equivalents, of a B2BUA that is substantially compliant with the requirements of a SIP proxy server in RFC 2543 would be improper. I. "SIP proxy server that mediates all SIP communications over the broadband network interface involving the non-SIP telephone" Cisco's Construction "SIP" and "SIP Proxy Server" as construed above.

ESN's Construction The instructions cause the network device to implement a SIP proxy server that acts as an intermediary for SIP

10

communications between a SIP user agent representing a non-SIP telephone attached to the telephone line interface and a remote SIP endpoint (e.g., telephone) accessible by way of routing SIP communications over the broadband network interface. The requirement that the "SIP proxy server mediate all SIP communications over the broadband network interface involving the non-SIP telephone" means that the SIP proxy server must control SIP telephone call sessions involving the non-SIP telephone by (1) making SIP signaling events available to a telephone call control function and (2) translating E.164 numbers into IP addresses (as required to establish SIP call sessions).

"Broadband network interface" and "non-SIP telephone" construed according to the parties' agreement. "Mediates" means acts as an intermediary. Ordinary meaning for the remainder of the phrase.

Cisco's construction, under the guise of relying on the "ordinary meaning for the remainder of the phrase," reads out the particular and expressly claimed function of the SIP proxy server ­ "mediat[ing] all SIP communications over the broadband network interface involving the non-SIP telephone." Cisco advocates merely telling the jury that "`[m]ediates' means acts as an intermediary."6 Cisco's construction is improper for a number of reasons. Cisco's construction improperly takes the term "mediates" out of the context of the claim's specific recitations of what is being mediated. Cisco's construction also renders the term "mediates" surplusage. Both parties' constructions of the term SIP proxy server recognize that the fundamental definition of SIP proxy server is "[a]n intermediary program that acts as both a server and a client." (See supra Section III.H.) The term "mediates" should not be interpreted as merely a redundant statement of this intermediary role. See Warner-Jenkins Co. v. Hilton Davis Chem. Co., 520 U.S. 17, 29 (1997) ("Each element contained in a patent claim is deemed material to defining the scope of the patented invention ...."); British Telecomms. PLC v. Prodigy Commc'ns Corp., 189 F. Supp. 2d 101, 113 (S.D.N.Y. 2002) ("No claim language may be interpreted as mere surplusage."). Additionally, Cisco's construction does not take into account that the patentee has acted as his own lexicographer with respect to this claim language. As explained in ESN's opening

6

It should be noted that while Cisco criticizes the use of dictionaries outside of the technical field of the `519 Patent for other elements of the claims, Cisco relies on a general English language dictionary for this definition.

11

claim construction brief, the `519 Patent equates the ability to mediate with the ability to perform call control. (ESN Br. 21-24.) Cisco's rebuttal appears to rely only on the fact that the discussion of mediation and call control do not appear in a "definitions" section of the `519 Patent. However, the law simply does not require a patentee to label terms "definitions" in order to act as his own lexicographer. Cisco's construction should be rejected. J. "system management platform" Cisco's Construction Platform, installed in a carrier central office or equivalent, that provides provisioning, configuration, management and active monitoring of network devices.

ESN's Construction A "system management platform" is deployed in the shared packet network. The system management platform generally does not participate in voice communications with the network devices, but provides a supporting, administrative role, including collecting call log data from the network devices.

While the "system management platform" of a preferred embodiment may be capable of additional functions, the only function required by the language of claim 16 (via claim 13) is "collecting call log data from a plurality of network devices." Cisco's construction, which additionally requires "provisioning, configuration, management and active monitoring" is unsupported by the claim. Cisco's requirement that the "system management platform" be "deployed in a carrier central office, or central office equivalent" is also not supported by the claim language. The claim only requires "locating a system management platform in a shared packet network." K. "shared packet network" Cisco's Construction Packet network owned and operated by a telecommunications carrier that is shared by a public subscriber base.

ESN's Construction A "shared packet network" uses packet switching (in contrast to circuit switching) to communicate data (for example, text, sound or video data). Packet switching is a network communications method that splits data into smaller bundles of data, called packets, that are then routed over a network that is shared with other data traffic. Each packet is labeled with its intended destination and a sequence number to allow the packets to be

12

reassembled in the proper order when they reach their destination. The Internet is an example of a shared packet network. Cisco's construction relies on faulty logic. Cisco's argument is that, because an IP carrier network is a shared packet network, all shared packet networks are IP carrier networks. This is simply not true. It is true, however, that "packet switched networks are shared networks." (ESN Ex. D, Newton's at 627.) Thus, the word "shared" in the claim term "shared packet network" is not superfluous, as urged by Cisco; rather, it merely serves to emphasize that the network recited in the claim is a packet switched network. L. "route telephone calls in a peer-to-peer fashion over the shared packet network" Cisco's Construction Route each telephone call without requiring assistance from the network beyond IP connectivity over the carrier packet network.

ESN's Construction Routing calls in a peer-to-peer fashion means that a network device may route calls to another network device reachable through the shared packet network without requiring any intermediary call control agent between the two network devices.

Cisco's proposed construction is incorrect for two primary reasons. First, by including the term "each," it quietly tries to slip in the unsupported requirement that all calls are routed in a peer-to-peer fashion.7 But the claim does not say "each" or "all" calls are routed in a peer-topeer fashion and the preferred embodiment does not operate that way. (See, e.g., ESN Ex. A at 22:2-14 (stating "communications ... is [sic, are] for the most part peer-to-peer" and discussing exceptions).) Second, Cisco, citing the `519 Patent at 18:55-59, recognizes that peer-to-peer call routing involves "call signaling ... performed without requiring stateful elements of the shared IP network above the IP infrastructure" (Opp'n Br. at 28-29), but Cisco's construction leaves out any reference to stateful elements for call signaling. ESN's construction recognizes that a stateful element for call signaling ­ "an intermediary call control agent" ­ is not required when

This requirement is intended to have the same effect as Cisco's improper requirement that the next claim element, the "SIP proxy server," always act as the "default" SIP proxy server.

7

13

calls are routed in a peer-to-peer fashion. M. "SIP proxy server for devices using the telephone line interface and for devices using the computer data interface" Cisco's Construction Default SIP proxy server that is used by the SIP user agents representing telephone stations and SIP user agents representing computer workstations to participate in SIP network signaling operations that involve carrier-owned SIP network signaling endpoints.

ESN's Construction The instructions cause the network device to implement a SIP proxy server that acts as an intermediary for SIP communications to/from a SIP user agent representing a non-SIP telephone attached to the telephone line interface and SIP devices connected to the network device through the computer data interface.

Cisco argues that the "SIP proxy server" recited in the claim is the "default" SIP proxy server for all devices attached to the network device. Cisco improperly relies exclusively on a discussion of a preferred embodiment, not on any language in the claim itself.8 The claim certainly does not include such a requirement; rather, the claim merely requires "instructions to act as an SIP proxy server for ...." This requirement is met whether or not the SIP proxy server is the "default" proxy server for attached devices. IV. CISCO'S EXPERT DECLARATION SHOULD BE STRICKEN In support of its claim construction, Cisco submitted extrinsic evidence in the form of a declaration from its retained expert witness, Dr. Burger, that includes opinions and analyses that were not previously disclosed in the Joint Claim Construction and Prehearing Statement materials as required by P.R. 4-3(d). Cisco was obligated to provide "a summary of each opinion to be offered in sufficient detail to permit a meaningful deposition of that expert." Cisco's summary of Dr. Burger's opinions consisted of little more than a recitation of the various sections in RFC 2543 regarding SIP. (ESN Ex. N.) The summary of Dr. Burger's opinions

The Federal Circuit requires a textual "hook" in the claim language in order to draw in limitations of the specification. NTP, Inc. v. Research in Motion, Ltd., 418 F.3d 1282, 1310 (Fed. Cir. 2005) (requiring a textual "hook" in the claim language in order to read in a limitation and stating that "a party wishing to use statements in the written description to confine or otherwise affect a patent's scope must, at the very least, point to a term or terms in the claim with which to draw in those statements.")

8

14

merely 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. (Id. at 3.) Dr. Burger's summary also concluded, that one of ordinary skill would not know what "SIP agents" means because it is not defined in RFC 2543. (Id. at 3-4.) Based upon the limited scope and conclusory nature of Cisco's P.R. 4-3 summary, there was no way for ESN to take a meaningful deposition of Dr. Burger. Dr. Burger' new declaration goes far beyond Cisco's P.R. 3-4(d) summary. For example, Dr. Burger's declaration devotes several paragraphs to the alleged differences between a SIP proxy server and a B2BUA. The term B2BUA was never mentioned in the P.R. 3-4(d)

summary. Additionally, Dr. Burger now opines that a particular detail of RFC 2543 § 12.3.1 regarding the copying of certain "tags" is "one of the most important rules that a SIP proxy server must follow." (Burger Decl. ¶ 23.) In addition to being entirely unsupported in fact, this statement presents a completely new and previously undisclosed opinion. Because Dr. Burger's declaration introduces opinions that were not disclosed in the P.R. 3-4 summary, it should be stricken from the record. Furthermore, to the extent the Court allows live expert testimony at the claim construction hearing, Dr. Burger's testimony should be limited to the opinions expressed in Cisco's P.R. 3-4(d) summary. V. CONCLUSION ESN respectfully requests that the Court adopt ESN's proposed claim constructions.

15

Respectfully submitted, FOR PLAINTIFF, ESN, LLC: Date: May 1, 2009 _/s/ Peter J. McAndrews_________________ George P. McAndrews Thomas J. Wimbiscus Peter J. McAndrews Gerald C. Willis Paul W. McAndrews Heather A. Bjella Matthew N. Allison McAndrews, Held & Malloy, Ltd. 500 W. Madison Street, 34th Floor Chicago, Illinois 60661 Telephone [phone] Facsimile [phone] [e-mail] Eric M. Albritton Lead Attorney Texas State Bar No. 00790215 ALBRITTON LAW FIRM P.O. Box 2649 Longview, Texas 75606 Telephone [phone] Facsimile [phone] [e-mail] T. John Ward Jr. Texas State Bar No. 00794818 Ward & Smith Law Firm 111 W. Tyler St. Longview, Texas 75601 Telephone [phone] Facsimile [phone] [e-mail]

16

CERTIFICATE OF SERVICE I hereby certify that on the date this proof of service is signed below, I served the foregoing: PLAINTIFF ESN, LLC'S REPLY BRIEF ON CLAIM CONSTRUCTION by email and via the Court's Electronic Filing System to: Charles K. Verhoeven Quinn Emanuel Urquhart Oliver & Hedges, LLP 50 California St., 22nd Floor San Francisco, CA 94111 [e-mail] Victoria F. Maroulis Quinn Emanuel Urquhart Oliver & Hedges, LLP 555 Twin Dolphin Dr., Suite 560 Redwood Shores, CA 94065 [e-mail] Michael E. Jones Potter Minton 110 N. College Suite 500 Tyler, TX 75702 [e-mail]

Date: May 1, 2009 /s/ Holly K. Mack Litigation Paralegal McAndrews, Held & Malloy, Ltd.

17