ESN LLC v. Cisco Systems, Inc. et al

Filing 68

Plaintiff ESN, LLC's Opening Claim Construction Brief filed by ESN LLC. (Attachments: # 1 Exhibit A - Part 1, # 2 Exhibit A - Part 2, # 3 Exhibit B, # 4 Exhibit C, # 5 Exhibit D, # 6 Exhibit E)(McAndrews, Peter)

Download PDF
ESN LLC v. Cisco Systems, Inc. et al Doc. 68 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 OPENING CLAIM CONSTRUCTION BRIEF Dockets.Justia.com TABLE OF CONTENTS I. II. III. INTRODUCTION ................................................................................................................ 1 BACKGROUND OF THE TECHNOLOGY......................................................................... 1 LAW..................................................................................................................................... 5 A. B. IV. A. B. C. D. E. F. G. H. I. J. K. L. M. V. VI. General Claim Construction Principles ...................................................................... 5 Claim Differentiation................................................................................................. 5 "network device" ....................................................................................................... 6 "telephone line interface" .......................................................................................... 8 "computer data interface" .......................................................................................... 9 "SIP" ......................................................................................................................... 9 "SIP agents" ............................................................................................................ 11 "SIP user agent" ...................................................................................................... 12 "the instructions causing the network device to provide a SIP user agent to represent a non-SIP telephone that uses the telephone line interface" ....................... 15 "SIP proxy server"................................................................................................... 16 "SIP proxy server that mediates all SIP communications over the broadband network interface involving the non-SIP telephone" ................................................ 21 "system management platform" ............................................................................... 24 "shared packet network".......................................................................................... 25 "route telephone calls in a peer-to-peer fashion over the shared packet network" ..... 27 "SIP proxy server for devices using the telephone line interface and for devices using the computer data interface" ........................................................................... 28 CONTRUCTION OF THE DISPUTED CLAIM TERMS AND PHRASES.......................... 6 CISCO'S PROPOSED CLAIM CONSTRUCTIONS .......................................................... 29 CONCLUSION................................................................................................................... 30 i TABLE OF AUTHORITIES Page(s) Cases Caterpillar Tractor Co. v. Berco, S.P.A. Etc., 714 F.2d 1110 (Fed. Cir. 1983) ............................................................................................. 6 Free Motion Fitness, Inc. v. Cybex Int'l, 423 F.3d 1343 (Fed. Cir. 2005). .................................................................................... 5, 6, 7 Liebel-Flarsheim Co. v. Medrad, Inc., 358 F.3d 898 (Fed. Cir. 2004) ............................................................................................... 6 Markman v. Westview Instruments, Inc., 52 F.3d 967 (Fed. Cir. 1995) (en banc), aff'd, 517 U.S. 370 (1996) ....................................... 5 Nazomi Communs., Inc. v. Arm Holdings, PLC 403 F.3d 1364 (Fed. Cir. 2005) ............................................................................................ 5 Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) ............................................................................................. 5 Sport Squeeze, Inc. v. Pro-Innovative Concepts, Inc., 1999 U.S. Dist. LEXIS 16681*8 (S.D. Ca. 1999)....................................................................................................... 6 Uniroyal, Inc. v. Rudkin-Wiley Corp., 837 F.2d 1044, 1055 (Fed. Cir. 1988) .............................. 6 ii I. INTRODUCTION Pursuant to the Court's Docket Control Order of May 22, 2008, Plaintiff ESN, LLC ("ESN") submits this brief in support of its proposed claim construction of the asserted claims of U.S. Patent No. 7,283,519 ("the `519 Patent") (attached as Ex. A). Four claims, claims 9, 10, 12 and 16 are asserted in this case. Claim 9 is an independent claim. Claims 10 and 12 depend from claim 9. Claim 16 is a dependent claim that depends from claim 13, however, claim 13 is not presently asserted. Therefore, as is proper under such circumstances, claim 16 has been rewritten in independent form to incorporate all of the limitations of claim 13. ESN has construed the `519 Patent claims in accordance with the meaning of the claim terms that is supported by, indeed in many instances expressly defined by, the intrinsic evidence, as well as extrinsic evidence that informs the interpretation of the claim terms. For the reasons further discussed below, the Court should adopt ESN's proposed constructions. II. BACKGROUND OF THE TECHNOLOGY1 The `519 Patent describes a novel device for the provision of telephony service over a packet-switched network, such as the Internet. The communication of digitized voice packets over the Internet in a manner that is intended to mimic a real-time telephone conversation is generally referred to as VoIP (Voice over Internet Protocol). VoIP is slowly taking hold and may one day displace the traditional PSTN (Public Switched Telephone Network) as the predominant means of enabling voice communications. Figure 1 of the `519 Patent is a general illustration of a PSTN network: 1 This section is supported by the background section of the `519 Patent. 1 A "Central Office Switch" (also known as a "Class 5 Switch") is shown in Figure 1. It includes four modules labeled Line, Call Processing, Trunk and Signaling. The LINE module functions include detecting on-hook/off-hook, applying dial tone and ringing tone, collecting dialed digits, and communicating internally with the call-processing module. The CALL PROCESSING module analyzes the digits collected by the LINE module, and asks the SIGNALING module to perform appropriate actions. The SIGNALING module interfaces with the SS#7 TRANSPORT NETWORK for the purpose of setting up a bearer channel between the calling and the called CENTRAL OFFICE SWITCHES. (Ex. A, `519 Patent at 2:28-37.) The only equipment that is located on a customer's premise in Figure 1 is a POTS (Plain Old Telephone Service) telephone. The telephone is connected over a wire (e.g., copper wire) to a remote Central Office Switch located centrally to a group of customers (for example, the population of a town). The POTS phones rely on the Central Office Switch to set up calls between phones located on different customer premises. If a call is being made to a phone connected to a different Central Office Switch, additional layers of network 2 signaling are required to connect one Central Office Switch to another. At the time of the inventions of the `519 Patent there existed (and still today there exist) differing views on the best way to provide VoIP telephone services as a replacement for the PSTN. A number of these approaches were referred to as the Next Generation Network (NGN): In recent years [prior to the application for the `519 Patent], attempts to transform the legacy Public Switched Telephone Network (PSTN) to exploit the potential of the Internet has led to approaches that are loosely referred to as the Next Generation Network (NGN). It was believed that such approaches would lead to converged networks. . . . [T]he converged approach of the NGN seeks to eliminate the need to have separate networks for different media. It exploits the principles of "openness" and leverages the standard protocols of IP networks to carry not only data but also other media such as voice and video. (Ex. A, `519 Patent at 1:38-53). Figure 2 of the `519 Patent is a general illustration of a NGN. 3 In Figure 2, the customer premises now include equipment, referred to as a Residential or Media Gateway, with the capability of converting analog phone signals from a POTS phone into digitized voice packets suitable for transmission over a packet-switched network such as the Internet. However, this network still relies on equipment centrally deployed within the network infrastructure (referred to as Media Gateway Controllers) to set up telephone calls between phones on different premises. This network provided for phones that were only reachable through the PSTN by deploying a Trunking Gateway (again, centrally deployed) to connect the NGN to the PSTN. A number of different signaling protocols had been proposed for telephone communications in the NGN, including MGCP (Media Gateway Control Protocol), H.323 and SIP (Session Initiation Protocol) among others. While each of these proposed protocols had their own perceived set of advantages, they all shared a theme that was common to the PSTN: critical systems necessary to set up and control telephone calls ­ capabilities referred to as "network intelligence" ­ remained centrally deployed in the network. Because the NGN was a natural evolution from the PSTN, it was conceived at the outset to realize similar economies of scale, large-scale uniformity of service, and a similar degree of centralized management capability As will be discussed further herein with respect to the proper construction of the disputed claim terms and phrases, the inventions disclosed and claimed in the `519 Patent provided a revolutionary new way to provide VoIP telephony services without requiring intelligent call setup and control equipment to be centrally deployed in the network infrastructure. 4 III. LAW A. General Claim Construction Principles Claim construction is a matter of law. See Markman v. Westview Instruments, Inc., 52 F.3d 967, 979 (Fed. Cir. 1995) (en banc), aff'd, 517 U.S. 370 (1996). The words of a claim "are generally given their ordinary and customary meaning." Phillips v. AWH Corp., 415 F.3d 1303, 1312 (Fed. Cir. 2005) (en banc). This is "the meaning that the term would have to a person of ordinary skill in the art in question at the time of the invention." Id. at 1313. The sources used to derive this meaning "include the words of the claims themselves, the remainder of the specification, the prosecution history, and extrinsic evidence concerning relevant scientific principles, the meaning of technical terms, and the state of the art." Id. at 1314. The person of ordinary skill is "deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification." Id. at 1313. The specification, as intrinsic evidence, "is the single best guide to the meaning of a disputed term." Id. at 1315. "Even when guidance is not provided in explicit definitional format, the specification may define claim terms by implication such that the meaning may be found in or ascertained by a reading of the patent documents." Id. at 1321. The prosecution history is also intrinsic evidence, and should be considered when in evidence. Id. at 1317. B. Claim Differentiation "The doctrine of claim differentiation creates a presumption that each claim in a patent has a different scope." Free Motion Fitness, Inc. v. Cybex Int'l, 423 F.3d 1343, 1351 (Fed. Cir. 2005). "The concept of claim differentiation normally means that limitations stated in dependent claims are not to be read into the independent claim from which they depend." Nazomi Communs., Inc. v. Arm Holdings, PLC, 403 F.3d 1364, 1370 (Fed. Cir. 2005); Liebel-Flarsheim 5 Co. v. Medrad, Inc., 358 F.3d 898, 910 (Fed. Cir. 2004); see also Free Motion Fitness, 423 F.3d at 1351 ("Here, dependent claims limiting the claim to a single cable confirm that the independent claims may encompass more than one cable."). "The doctrine may also be used to interpret an independent claim in light of another independent claim." Sport Squeeze, Inc. v. ProInnovative Concepts, Inc., 1999 U.S. Dist. LEXIS 16681*8 (S.D. Cal. 1999) (citing Uniroyal, Inc. v. Rudkin-Wiley Corp., 837 F.2d 1044, 1055 (Fed. Cir. 1988)); Caterpillar Tractor Co. v. Berco, S.P.A. Etc., 714 F.2d 1110, 1116 (Fed. Cir. 1983). IV. CONTRUCTION OF THE DISPUTED CLAIM TERMS AND PHRASES A. "network device" ESN's Proposed Construction Disputed Claim Term or Phrase A network device comprising: (claims 9, 10, 12 and 16) 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. The preamble of independent claim 9 recites a "network device comprising." The preamble is then followed by a number of elements reciting software and hardware modules that together provide unique benefits when deployed at a single location (or node) on a data communications network. The `519 Patent, in describing a preferred embodiment, states: The EDGE SWITCH is an ESN [Edge Switched Network] connectivity element whose principal function is to support the delivery of voice, video (multimedia) and data services - multi-service delivery - to the subscriber premise through a shared IP [Internet Protocol] data path. It aggregates several functions together into a single, cost-effective device that is deployed by the carrier as a premisebased network element. (Ex. A, `519 Patent at 11:65 ­ 12:4.) Thus, several functions are aggregated together into the network element so that it can provide voice and data services to a customer premise. 6 The `519 Patent states that the network device may be "constructed according to a variety of form factors as required to accommodate voice, video, and data termination requirements at the subscriber premise." (Ex. A, `519 Patent at 37:37-39.) The particular form-factor is based upon considerations such as the capacity of the broadband network to which the network device is connected and the number of telephones to be connected to the network device. Form-Factor Considerations The EDGE SWITCH [1] can be constructed to support any number of formfactors, depending upon the transmission capacity of the BROADBAND ACCESS NETWORK [6.1] and the number of TELEPHONE STATIONS [3] and SET-TOP BOXES [4] the designer believes is appropriate for a single instance of an EDGE SWITCH [1]. (Ex. A, `519 Patent at 21:8-14.) While the hardware and software modules that make up the network element will always be located on the same customer premise and will communicate with the broadband access network as a single node, it is not a requirement of the `519 Patent (nor claim 9 and claim 16) that the network device will always be contained within a single physical enclosure. Indeed, dependent claim 12 requires that the network device be contained within a single physical enclosure. Any requirement that all of the elements of the network devices of claim 9 and claim 16 be contained in a single enclosure would be contrary to the doctrine of claim differentiation. See, e.g., Free Motion Fitness, 423 F.3d at 1351 ("Here, dependent claims limiting the claim to a single cable confirm that the independent claims may encompass more than one cable.") Thus, dependent claim 12 confirms that claim 9 and claim 16 may encompass more than one enclosure. In accordance with the foregoing discussion and consistent with the intrinsic record, the proper construction of "network device" is: 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. 7 B. "telephone line interface" ESN's Proposed Construction Disputed Claim Term or Phrase a plurality of interfaces, including a telephone line interface and (claims 9 and 16) 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, on-hook, and dialed digits.) The claimed network device includes a "telephone line interface" for connecting one or more non-IP telephones to the network device and for providing the necessary signaling conversions to allow a non-IP telephone to participate in VoIP communications. particularly, the `519 Patent defines the telephone line interface as follows: TELEPHONE LINE INTERFACE [1.9] Hardware subcomponent of the EDGE SWITCH [1] integrated with external cabling interface that is used to connect TELEPHONE STATIONS [3]. TELEPHONE STATIONS [3] do not natively support SIP network signaling and as a result cannot present themselves to an IP network as SIP network signaling endpoints without assistance from the EDGE SWITCH [1]. (Ex. A, `519 Patent at 42:46-52.) In addition to providing a physical interface for the telephones: 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)." (Ex. A, `519 Patent at 23:4-8.) In accordance with the foregoing discussion and consistent with the intrinsic record, the proper construction of "telephone line interface" is: 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, on-hook, and dialed digits.) More 8 C. "computer data interface" ESN's Proposed Construction A "computer data interface" is a hardware subcomponent of the network device that is used to connect one or more computer workstations to allow bidirectional IP data paths used for common data transport to/from the one or more computer workstations. Disputed Claim Term or Phrase a computer data interface; (claims 9 and 16) The claimed network device includes a "computer data interface" for connecting computers to the network device to allow the computers to communicate IP data over the broadband network. The `519 Patent defines the computer data interface as follows: COMPUTER DATA INTERFACE [1.4] Hardware subcomponent of the EDGE SWITCH [1] integrated with external cabling interface used to plug in one or more COMPUTER WORKSTATIONS [5] to the EDGE SWITCH [1]. The COMPUTER DATA INTERFACE supports bidirectional IP data paths used for common data transport between the IP ROUTING MODULE [1.2] and the COMPUTER WORKSTATIONS [5]. (Ex. A, `519 Patent at 41:16-23.) In accordance with the foregoing discussion and consistent with the intrinsic record, the proper construction of "computer data interface" is: A "computer data interface" is a hardware subcomponent of the network device that is used to connect one or more computer workstations to allow bidirectional IP data paths used for common data transport to/from the one or more computer workstations. D. "SIP" ESN's Proposed Construction Disputed Claim Term or Phrase a machine-readable storage medium that stores processorexecutable instructions to provide SIP agents, (claims 9 and 16) 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. 9 SIP is an acronym for Session Initiation Protocol: The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. (Ex.B, RFC 2543 - SIP: Session Initiation Protocol (March 1999) at p.1; see also Ex. C, RFC 3261 - SIP: Session Initiation Protocol (June 2002) at p.1.) SIP was proposed in 1999 in a draft standards document referred to as an RFC or Request for Comment. The purpose of the RFC is to solicit commentary by industry experts so that the proposed SIP protocol can be improved and ultimately become a standard. (Ex. B, RFC 2543 at p.1 ("This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements.").) The draft standard proposed in 1999 for SIP was designated RFC 2543. Since 1999, the draft SIP standard has evolved based on industry commentary and experience. In June 2002, shortly after the application for the `519 Patent was filed, the draft SIP standard was re-designated as RFC 3261. (Ex. C, RFC 3261 at p.1.) While RFC 3261 includes certain modifications in the details of the proposed SIP standard, the fundamental building blocks of SIP and their respective functions remain substantially the same.2 2 The `519 Patent recognized that, because the RFC was a draft, the exact implementation details were subject to modification: This section contains definitions for major system elements, terms, and protocols referenced in this disclosure. The telecommunications industry contains a variety of views regarding exactly what comprises these elements; thus the definitions should not in all cases be considered absolute. Definitions annotated with numerical identifiers in brackets refer to system elements that are explicitly shown in figures. IETF 10 In accordance with the foregoing discussion and consistent with the intrinsic record and the extrinsic evidence, the proper construction of "SIP" is: 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. E. "SIP agents" ESN's Proposed 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. Disputed Claim Term or Phrase a machine-readable storage medium that stores processor-executable instructions to provide SIP agents, (claim 9) "The classic definition of an agent is an entity acting on behalf of another." (Ex. D, Newton's Telecom Dictionary, 16th Ed., at p. 44 (February 2000).) In the context of claim 9, the phrase "instructions to provide SIP agents" refers to the two software entities recited immediately thereafter in claim 9 that provide SIP functions on behalf of other entities. The claim element immediately following the term SIP agents recites "the instructions causing the network device to provide a SIP user agent to represent a non-SIP telephone that uses the telephone line interface." Thus, the SIP user agent acts as a SIP agent by providing a SIP function ­ a "SIP user agent" ­ that acts on behalf of a non-SIP telephone. The other of the SIP agents is found in the next element of claim 9, which recites "the instructions further causing the network device to implement a SIP proxy server that mediates Internet Engineering Task Force (IETF). The IETF is a standards body whose conventions mandate that a body of work is presented initially as an "Internet Draft" which either expires or is formally promulgated to a "Request for Comment" (RFC). Both the Internet Draft and RFC documents must comply with a content format convention. (Ex. A, `519 Patent at 37:5-18.) 11 all SIP communications over the broadband network interface involving the non-SIP telephone." As will be discussed in greater detail infra, the `519 Patent relies on the general definition of "SIP proxy server" found in the draft SIP standard, which 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." Thus, a SIP proxy server meets the classic definition of "agent" since it is a software program that acts "on behalf of other clients." The agency relationships are made explicit in claim 9 since the SIP proxy server is acting on behalf of the SIP user agent, which, in turn, is acting on behalf of the non-SIP telephone. In accordance with the foregoing discussion and consistent with the intrinsic record and the extrinsic evidence, the proper construction of "SIP" is: 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. F. "SIP user agent" ESN's Proposed Construction A "SIP user agent" is a SIP network signaling endpoint. Disputed Claim Term or Phrase the instructions causing the network device to provide a SIP user agent to represent a non-SIP telephone that uses the telephone line interface (claim 9) One of the fundamental building blocks of the SIP protocol is a "SIP user agent." The draft SIP standard defines a user agent (UA) as "[a]n application which contains both a user agent client and user agent server." (Ex. B, RFC 2543 at p.11.) When the SIP user agent is the "calling user agent," it implements a user agent client (UAC), which is "a client application that initiates the SIP request," such as an invitation to another user agent to initiate a telephone call session. (Id.) When a SIP user agent is the "called user agent," it implements a user agent server 12 (UAS), which is "a server application that contacts the user when a SIP request is received and that returns a response on behalf of the user. The response accepts, rejects or redirects the request." (Id.) A simple illustration of the roles of a SIP user agent are shown below. In this example, SIP User Agent A is acting on behalf of Al's non-SIP telephone and SIP User Agent B is implemented by Bob's SIP phone, which is natively capable of participating in SIP communications. When Al picks up his handset and dials Bob's phone number, SIP User Agent A attempts to initiate a session (telephone call) by sending an "invite" message to User Agent B. Thus, User Agent A is the "calling user agent" and is implementing the user agent client application. User Agent B is the "called user agent" and is implementing the user agent server application. User Agent B processes the "invite" message, causes Bob's SIP phone to ring and sends a "ringing" message to User Agent A to indicate that Bob's telephone is ringing. If Bob picks up his handset to answer, User Agent B sends an "OK" message to User Agent A. User Agent A then sends an "ACK" (acknowledgement) message to User Agent B to confirm 13 receipt of the "OK" message. Thereafter, a "media session" (the exchange of digitized voice data) has been set up and continues until one party terminates the call by hanging up. As can be seen from this example, where a non-SIP telephone (e.g., standard analog telephone) is involved in a call, the actual endpoint of the call that interacts with the human user is the non-SIP telephone itself. However, the `519 Patent discloses that "SIP User Agents are created to operate on behalf of TELEPHONE STATIONS [3] [e.g., non-SIP telephones] that are by themselves incapable of performing SIP network signaling operations." (`519 Patent at 31:41-44.) This means that the "SIP user agents" are the endpoint for any SIP protocol message signaling. Thus, "SIP user agent" refers to an endpoint from the perspective of the SIP protocol. The `519 Patent uses the term "SIP user agent" in this manner, e.g.: For example, if the calling party is a SIP network signaling endpoint (SIP User Agent) used by an EDGE SWITCH to represent a POTS telephone at the subscriber premise, the APPLICATION SERVER will receive the dialing number of the calling party (i.e. the dialing number assigned to the POTS telephone originating the call). (Ex. A, `519 Patent at 14:2-7, emphasis added.)3 In accordance with the foregoing discussion and consistent with the intrinsic record and the extrinsic evidence, the proper construction of "SIP user agent" is: 3 The draft SIP standard also refers to SIP user agents as SIP endpoints: There are many applications of the Internet that require the creation and management of a session, where a session is considered an exchange of data between an association of participants. The implementation of these applications is complicated by the practices of participants: users may move between endpoints, they may be addressable by multiple names, and they may communicate in several different media - sometimes simultaneously. Numerous protocols have been authored that carry various forms of real-time multimedia session data such as voice, video, or text messages. The Session Initiation Protocol (SIP) works in concert with these protocols by enabling Internet endpoints (called user agents) to discover one another and to agree on a characterization of a session they would like to share. (Ex. C, RFC 3261 at 8-9, emphasis added.) 14 A "SIP user agent" is a SIP network signaling endpoint. 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" ESN's Proposed Construction Disputed Claim Term or Phrase the instructions causing the network device to provide a SIP user agent to represent a non-SIP telephone that uses the telephone line interface (claim 9) 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 non-SIP telephone to indirectly participate in SIP communications. The terms "telephone line interface," "SIP" and "SIP user agent" have already been discussed supra. The remaining language of this claim element describes the role that the SIP user agent plays in the network device of claim 9. In particular, "the instructions caus[e] the network device to provide a SIP user agent to represent a non-SIP telephone that uses the telephone line interface." Thus, the network device allows non-SIP telephones, which are not natively capable of participating in SIP network signaling, to participate in call sessions set up using the SIP protocol. This role for the SIP user agent is discussed throughout the `519 Patent specification, e.g.: Internally within the EDGE SWITCH [1], TELEPHONE STATIONS [3] plugged into it are represented as SIP User Agent instances by the ABSTRACT CALL MODEL'S [1.20] Telephone Gateway function. These SIP User Agents are created to operate on behalf of TELEPHONE STATIONS [3] that are by themselves incapable of performing SIP network signaling operations. (Ex. A, `519 Patent at 31:37-44); and The EDGE SWITCH [1] represents each TELEPHONE STATION [3] internally as a SIP network signaling endpoint to the IP CARRIER NETWORK [6] by associating it with particular E.164 dialing number that is recognized by the SIP PROTOCOL STACK. The ABSTRACT CALL MODEL [1.20] supports a 15 telephone gateway function in which a SIP User Agent is used to perform SIP network signaling endpoint functions on behalf of each TELEPHONE STATION [3] plugged into the TELEPHONE LINE INTERFACE [1.9]. This SIP User Agent directs its SIP network signaling operations to the SIP PROTOCOL STACK, using it as its default SIP Proxy Server. (Ex. A, `519 Patent at 44:59 ­ 45:3.) In accordance with the foregoing discussion and consistent with the intrinsic record, the proper construction of "the instructions causing the network device to provide a SIP user agent to represent a non-SIP telephone that uses the telephone line interface" is: 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 non-SIP telephone to indirectly participate in SIP communications. H. "SIP proxy server" ESN's Proposed 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. Disputed Claim Term or Phrase the instructions further causing the network device to implement a SIP proxy server that mediates all SIP communications over the broadband network interface involving the nonSIP telephone. (claims 9 and 16) Another one of the fundamental building blocks of the SIP protocol is a "SIP proxy server." The `519 Patent expressly adopts the general definition of "SIP proxy server" as found in the draft SIP standard: According to IETF RFC 2543 on SIP: Session Initiation Protocol a SIP PROXY SERVER is defined as follows: "An intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced 16 internally or by passing them on, possibly after translation, to other servers. A proxy interprets, and, if necessary, rewrites a request message before forwarding it." (Ex. A, `519 Patent at 62:38-45.) The example call set-up between Al and Bob can be used here to generally illustrate the SIP proxy function. In this example, the SIP proxy server is acting as an intermediary by passing SIP messages sent from User Agent A to User Agent B. The SIP proxy server acts as a SIP user agent server by receiving and processing messages from User Agent A and acts as a SIP user agent client by making requests to User Agent B on behalf of User Agent A. The general intermediary function of the "SIP proxy server" recited in claims 9 and 16 is illustrated in Figure 7 of the `519 Patent (next page). 17 In Figure 7, the device labeled "A" is a native SIP signaling device (such as a SIP phone) and the phone labeled B is a non-SIP phone. The `519 Patent describes the general intermediary function of the SIP Proxy Server as follows: The SIP PROTOCOL STACK [1.16], functioning the same as any SIP Proxy Server, will forward SIP protocol messages between the near-end SIP network signaling endpoints (terminals A & B) through the IP CARRIER NETWORK [6] to and from the far-end SIP network signaling endpoints (terminals C & D) to which they are respectively connected. (Ex. A, `519 Patent at 49:12-24.) 18 The `519 Patent describes SIP proxy servers in two different roles. Figure 11 illustrates these two roles. The SIP Proxy Server designated with the reference number [12] is found in the traditional location ­ in the IP carrier network infrastructure. However, the `519 Patent also discloses that the network devices located on the subscriber/customer premises include a SIP proxy server. The SIP proxy server functionality of the network devices is provided by software running on the network device: SIP PROTOCOL STACK [1.16] Software subcomponent in the EDGE SWITCH [1] that implements support for the "SIP Proxy Server" functionality described further in this 19 disclosure (see SIP PROXY SERVER [12]) and in IETF RFC 2543 on SIP: Session Initiation Protocol (SIP). (Ex. A, `519 Patent at 44:46-51.) The `519 Patent clarifies that, while the SIP proxy server functionality supported by the stand-alone SIP Proxy Server [12] located in the IP carrier network and the SIP proxy server of the network device are essentially identical (i.e., they both meet the general definition of "SIP proxy server" recited in the `519 Patent at 62:38-45), they operate independently in support of different roles. SIP PROXY SERVER [12] This term refers specifically to a network-based implementation of a stand-alone SIP Proxy Server (or SIP Proxy Server cluster) and not to the SIP Proxy Server functionality supported by the SIP PROTOCOL STACK [1.16]. While the SIP Proxy Server functionality supported by both is essentially identical, they operate independently in support of different roles. (Ex. A, `519 Patent at 62:31-37.) The inclusion of a SIP proxy server within each subscriber/customer premise-based network device allows the network devices to provide critical SIP proxy services to each of the devices plugged into it without the need for the network-based SIP Proxy Server [12]. Because each EDGE SWITCH [1] contains its own SIP Proxy Server, the network's capacity to provide secure SIP Proxy services scales with the network itself. Each EDGE SWITCH [1] contains the computing resources necessary to provide SIP proxy services to all terminals plugged into it. (Ex. A, `519 Patent at 31:55 ­ 32:3.) In accordance with the foregoing discussion and consistent with the intrinsic record, the proper construction of "SIP proxy server" is: 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. 20 I. "SIP proxy server that mediates all SIP communications over the broadband network interface involving the non-SIP telephone" ESN's Proposed Construction The instructions cause the network device to implement a SIP proxy server that acts as an intermediary for SIP 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 nonSIP 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). Disputed Claim Term or Phrase the instructions further causing the network device to implement a SIP proxy server that mediates all SIP communications over the broadband network interface involving the non-SIP telephone. (claim 9) As explained in the previous section, the claimed "SIP proxy server" plays a particular role in providing support for devices attached to the network device. As claim 9 states, the instructions cause "the network device to implement a SIP proxy server that mediates all SIP communications over the broadband network interface involving the non-SIP telephone." This limitation distinguishes the SIP proxy server functionality from other types of SIP proxy servers that serve different roles.4 4 At the time of the inventions disclosed in the `519 Patent, those familiar with SIP recognized that SIP proxy servers provide only a general logical function (i.e., acting as an intermediary), so it is critical to understand the features built on top of the SIP proxy function and the role(s) played by the SIP proxy server. Jonathan Rosenberg, an author of the draft SIP protocol and current Cisco employee, provided a presentation on SIP that explained: · Proxy is just a SIP defined logical function o Not useful in and of itself o Critical piece is value add[ed] features built on top of SIP proxy function o Which features you need depends on roles (Ex. E, Jonathan Rosenberg, DynamicSoft ­ SIP Proxies, at p. 10 (January 24, 2001) (bullet outline is directly quoted from original).) 21 As an initial matter, it should be understood that the type of SIP communications addressed by this claim element are only those "involving the non-SIP telephone," which is referred to earlier in claim 9 as using (i.e., attached to) the telephone line interface and for which the network device provides a SIP user agent. This is further narrowed to SIP communications that take place "over the broadband network interface." In other words, the SIP communications take place between a SIP user agent representing a non-SIP telephone plugged into the network device on a first premise and a remote (off premise) SIP endpoint (e.g., telephone) accessible over the broadband network interface. The ability of the SIP proxy server of the `519 Patent to "mediate all SIP communications over the broadband network interface" allows SIP controlled VoIP calls to be made between two or more customer premises (each customer premise hosting an instance of the claimed network device) without the need for SIP proxy server call control services to be centrally-deployed within the IP network infrastructure. Prior to the inventions of the `519 Patent, "unintelligent" gateway devices were deployed on the customer premises. These unintelligent gateway devices relied on "intelligent," centrally-deployed network servers to control and distribute VoIP calls. The `519 Patent (with reference to Figure 2) explains that the prior art gateway devices were "unintelligent" because they were incapable of mediation without "centralized participation by the Media Gateway Controller" (i.e., a network-based server): RESIDENTIAL GATEWAYS are unintelligent in the sense that they require the MEDIA GATEWAY CONTROLLER to mediate all network signaling functions on their behalf. They cannot determine the broader network signaling context of the calling operations in which they participate. They are incapable of independently executing service logic that involves network signaling operations (e.g call redirection, multipoint call control, call supervision, multiple line appearances, etc.) without centralized participation by the MEDIA GATEWAY CONTROLLER. These factors impose substantial constraints on the variety of network services the NGN can deliver because each new service must 22 be tightly integrated with the MEDIA GATEWAY CONTROLLER in order to perform call control operations. (Ex. A, `519 Patent at 8:41-54.) This passage makes it clear that the `519 Patent equates the ability to mediate with the ability to perform call control. In prior art VoIP systems where SIP was used to set up phone calls, the unintelligent gateway devices included only SIP user agents and necessarily relied on centrally-deployed SIP proxy servers to mediate SIP communications (i.e., perform call control for calls) to remote SIP endpoints. The `519 Patent explains that the network device disclosed and claimed is intelligent because it includes both the ability to operate as a SIP network signaling endpoint (i.e., the claimed "SIP user agent") and the ability to perform call control (i.e., the claimed "SIP proxy server that mediates all SIP communications over the broadband network interface involving the non-SIP telephone"): 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. (Ex. A, `519 Patent at 11:55-59.) In addition to controlling SIP telephone call sessions, the SIP proxy server, in its role as an intermediary for all SIP communications over the broadband network interface involving a non-SIP telephone attached to the network device, translates E.164 numbers into IP addresses (as required to establish SIP call sessions): The SIP PROTOCOL STACK [1.16] runs on the CENTRAL PROCESSING UNIT [1.10] and is used by the ABSTRACT CALL MODEL [1.20] to support all SIP network signaling operations. Among other roles, it functions as the default SIP Proxy Server for all voice and video terminals plugged into the EDGE SWITCH [1], acting [as] an intermediary for all SIP network signaling operations between those terminal devices and those in the network with whom they are communicating. FIG. 11 depicts this role of the SIP PROTOCOL STACK [1.16] to the extent that the DES as a system functions as a distributed SIP Proxy Server, using the DNS SERVER [10] as a centralized database to translate E.164 dialing numbers into IP addresses (as required to establish SIP call sessions in the ESN. 23 (Ex A, `519 Patent at 24:24-38.)5 In accordance with the foregoing discussion and consistent with the intrinsic record, the proper construction of "SIP proxy server that mediates all SIP communications over the broadband network interface involving the non-SIP telephone" is: The instructions cause the network device to implement a SIP proxy server that acts as an intermediary for SIP 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). J. "system management platform" ESN's Proposed 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. Disputed Claim Term or Phrase locating a system management platform in a shared packet network, the system management platform collecting call log data from a plurality of network devices (claim 16) In addition to the network devices distributed in a network at the customer premises, the `519 Patent discloses the use of a "system management platform" that is installed in the central office or central office equivalent. (Ex. A, `519 Patent at 37:40-43.) The system management platform "does not directly participate in network service delivery at anytime, but provides only 5 An E.164 number is a standard telephone number, such as the 10 digit numbers used in the United States. The disclosed network device "represents each TELEPHONE STATION [3] internally as a SIP network signaling endpoint to the IP CARRIER NETWORK [6] by associating it with particular E.164 dialing number that is recognized by the SIP PROTOCOL STACK." (Ex. A, `519 Patent at 44:59-63.) 24 a supporting, administrative role" for the distributed network devices. (Ex. A, `519 Patent at 56:67 ­ 57:3.) While the "system management platform" of the preferred embodiment also may be capable of provisioning and configuring the network devices, claim 16 does not require these procedures to be performed. Rather, claim 16 only requires that the system management platform collect call log data from the network devices. In accordance with the foregoing discussion and consistent with the intrinsic record, the proper construction of "system management platform" is: 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. K. "shared packet network" ESN's Proposed 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 reassembled in the proper order when they reach their destination. The Internet is an example of a shared packet network. Disputed Claim Term or Phrase locating a system management platform in a shared packet network, the system management platform collecting call log data from a plurality of network devices (claim 16) The `519 Patent uses the term "shared packet network" according to its plain and generally accepted meaning to refer to any packet-switched network, such as the Internet, where digitized voice packets and other types of data packets are communicated over a common network. For example, the digitized voice packets associated with a particular phone call might be transmitted along with digitized voice packets for a different call or other types of data packets for, e.g., email, web browsing, etc. 25 Newton's Telecom Dictionary, 16th Ed. (February 2000) expressly states that "packet switched networks are shared networks" and provides a useful discussion of packet switching: Originally developed to support interactive communications between asynchronous computers for time-share applications, packet switched networks are shared networks, based on the assumption of varying levels of latency and, thereby yielding a high level of efficiency for digital data networking. Isochronous data such as realtime voice and video, on the other hand, are streamoriented and highly intolerant of latency. As a result, packet switched networks are considered to be inappropriate for such applications. Recent development of certain software and making use of complex compression algorithms, however, has introduced packetized voice and video to the corporate intranets and the Internet, which was the first public packet-switched data network and remains by far the most heavily used. Here is another way of explaining packet switching: There are two basic ways of making a call. First, the one everyone's familiar with ­ the common phone call. You dial. Your local switch finds an unused path to the person you called and joins you. While you are speaking, the circuit is 100% all yours. It's dedicated to the conversation. This is called circuit switched. Packet switching is different. In packet switching, the "conversation" (which may be voice, video, images, data, etc.) is sliced into small packets of information. Each packet is given a unique identification and each packet carries its own destination address ­ i.e., where it's going. Each packet may go by a different route. The packets may also arrive in a different order than how they were shipped. The identification and sequencing information on each packet lets the data be reassembled in proper sequence. Packet switching is the way the Internet works. Circuit switching is the way the worldwide phone system works, also called the PSTN (Public Switched Telephone Network). Packet and Circuit Switching each have their own significant advantages. Packet switching for example does a wonderful job of getting oodles of data into circuits. Think about a voice conversation. When you are talking, he's listening. Therefore half the circuit is dead. There are pauses between your voice. Packet switching takes advantage of those pauses to send data. (Ex. D, Newton's Telecom Dictionary at 627-628, emphasis added.) In accordance with the foregoing discussion and consistent with the intrinsic record and extrinsic evidence, the proper construction of "shared packet network" is: 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 26 traffic. Each packet is labeled with its intended destination and a sequence number to allow the packets to be reassembled in the proper order when they reach their destination. The Internet is an example of a shared packet network. L. "route telephone calls in a peer-to-peer fashion over the shared packet network" ESN's Proposed 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. Disputed Claim Term or Phrase a machine-readable storage medium storing processor-executable instructions to control telephone calls, the instructions causing each network device to route telephone calls in a peer-to-peer fashion over the shared packet network (claim 16) As discussed supra in sections IV.H and IV.I, the network devices disclosed in the `519 Patent include their own SIP proxy servers that are capable of controlling telephone calls without the need for a traditional network-based SIP proxy server. "Rout[ing] telephone calls in a peerto-peer fashion over the shared packet network" refers to the ability of a network device on a first customer premise to control telephone calls between a SIP endpoint on the first premise and a SIP endpoint on another customer premise. Figure 3 of the `519 Patent (reproduced supra in section IV.H), illustrates the direct SIP network signaling paths (light gray dashed lines) between network devices located on separate customer premises, which signaling paths do not involve the network-based SIP Proxy Server [12]: FIG. 3 depicts an ESN architecture principally comprised of "connectivity elements." A connectivity element is a particular type of network element that is capable of participating in call sessions using SIP network signaling and RTP bearer transmission. Communities of connectivity elements communicate in a peer-to-peer fashion without necessarily requiring assistance from the network beyond IP connectivity. (Ex. A, `519 Patent at 11:36-43, emphasis added; see also `519 Patent at 18:55-59 ("The call routing includes peer-to-peer call signaling between customer premises over a shared IP 27 network. The call signaling is performed without requiring stateful elements of the shared IP network above the IP infrastructure.").) The `519 Patent explains that the use of the network-based SIP Proxy Server [12] may be necessary in some circumstances. (Ex. A, `519 Patent at 22:2-14.) However, calls within the same network between SIP endpoints connected to network devices on different premises are typically routed in a peer-to-peer manner. (Id.) In accordance with the foregoing discussion and consistent with the intrinsic record, the proper construction of "route telephone calls in a peer-to-peer fashion over the shared packet network" is: 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. M. "SIP proxy server for devices using the telephone line interface and for devices using the computer data interface" ESN's Proposed 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. 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. Disputed Claim Term or Phrase wherein the storage medium further stores processor-executable instructions to act as an SIP proxy server for devices using the telephone line interface and for devices using the computer data interface (claim 16) In claim 16, the term SIP proxy server is used in the same general sense as it is used in claim 9 as discussed supra in section IV.H. Claim 16, however, in addition to acting as a SIP 28 proxy server for devices using the telephone line interface (e.g., a non-SIP telephone) adds the additional requirement that the instructions executing on the network device act as a SIP proxy server for devices using the computer data interface. Devices using the computer data interface may include native SIP signaling devices such as SIP phones or other devices that are not dependent on the network device to create a SIP endpoint (i.e., SIP user agent) on their behalf. In accordance with the foregoing discussion and consistent with the intrinsic record, the proper construction of "SIP proxy server for devices using the telephone line interface and for devices using the computer data interface" is: 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. 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. V. CISCO'S PROPOSED CLAIM CONSTRUCTIONS While ESN's proposed claim constructions are supported by, indeed in many instances expressly defined by, the intrinsic evidence, as well the 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 defenses in this case. Cisco's proposed constructions, inter alia, (1) improperly ignore the intrinsic evidence of the intended meaning and scope of certain claim terms; (2) improperly attempt to require the jury to perform certain claim construction duties; and (3) fail to recognize the law of claim differentiation. For example, Cisco improperly restricts the scope of certain recited SIP claim elements 29 ("SIP user agent" and "SIP proxy server") to non-essential details of a "draft" recommendation for SIP (referred to as a Request For Comment or "RFC"), which details are not included in the intrinsic record. In doing so, Cisco ignores the intrinsic evidence that relies only on essential and fundamental functions of the building blocks of SIP in expressly defining SIP elements. The intrinsic record of the `519 Patent shows that the inventor recognized, as one of ordinary skill in the field would, that the SIP protocol had only recently been proposed and that the specific implementation of certain aspects of SIP were still under development. Cisco's proposed constructions of the terms "SIP user agent" and "SIP proxy server" include the loaded phrase "in accordance with RFC 2543" that, while having a superficial appeal of being succinct, is inconsistent with the intrinsic evidence to the extent every detail of the draft SIP standard is read into the claim. Moreover, Cisco's proposed constructions are useless as a tool for the jury to determine the scope of the claims since the jury would be required to determine for themselves what portions of the 150-plus page draft SIP standard apply and then determine for themselves what those portions mean. This would improperly place the jury in the role of construing the claims. ESN reserves the right to address, in ESN's reply brief, Cisco's arguments in support of its improper claim constructions. VI. CONCLUSION ESN respectfully requests that the Court adopt ESN's proposed claim constructions. 30 Respectfully submitted, FOR PLAINTIFF, ESN, LLC: Date: April 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 (312) 775-8000 Facsimile (312) 775-8100 pmcandrews@mcandrews-ip.com Eric M. Albritton Lead Attorney Texas State Bar No. 00790215 ALBRITTON LAW FIRM P.O. Box 2649 Longview, Texas 75606 Telephone (903) 757-8449 Facsimile (903) 758-7397 ema@emafirm.com T. John Ward Jr. Texas State Bar No. 00794818 Ward & Smith Law Firm 111 W. Tyler St. Longview, Texas 75601 Telephone (903) 757-6400 Facsimile (903) 757-2323 jw@jwfirm.com 31 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 OPENING CLAIM CONSTRUCTION BRIEF 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 charlesverhoeven@quinnemanuel.com Victoria F. Maroulis Quinn Emanuel Urquhart Oliver & Hedges, LLP 555 Twin Dolphin Dr., Suite 560 Redwood Shores, CA 94065 victoriamaroulis@quinnemanuel.com Michael E. Jones Potter Minton 110 N. College Suite 500 Tyler, TX 75702 mike.jones@potterminton.com Date: April 1, 2009 _/s/ Holly K. Mack_________________ Holly K. Mack 32

Disclaimer: Justia Dockets & Filings provides public litigation records from the federal appellate and district courts. These filings and docket sheets should not be considered findings of fact or liability, nor do they necessarily reflect the view of Justia.


Why Is My Information Online?