DCT
1:18-cv-00809
Mod Stack LLC v. Unify Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Mod Stack LLC (Texas)
- Defendant: Unify Inc. (Delaware)
- Plaintiff’s Counsel: Stamoulis & Weinblatt LLC; Direction IP Law
- Case Identification: 1:18-cv-00809, D. Del., 05/29/2018
- Venue Allegations: Venue is asserted based on Defendant’s incorporation in Delaware.
- Core Dispute: Plaintiff alleges that Defendant’s telecommunications systems, which bridge packet-switched and circuit-switched networks, infringe a patent related to a voice gateway architecture designed to handle multiple, disparate call control protocols simultaneously.
- Technical Context: The technology addresses the challenge of interoperability in telecommunications during the industry's transition from traditional circuit-switched telephone networks to converged, packet-based networks like Voice over IP (VoIP).
- Key Procedural History: The complaint references the patent’s prosecution history, highlighting arguments made to distinguish prior art. The applicant reportedly argued that the invention was unconventional because it uses a distinct "internal protocol" to mediate between different external communication protocols, whereas prior art allegedly used a single protocol or simply passed data forward without such mapping.
Case Timeline
| Date | Event |
|---|---|
| 2002-11-20 | ’520 Patent Priority Date |
| 2008-12-02 | ’520 Patent Issue Date |
| 2018-05-29 | Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 7,460,520 - "Apparatus and Method for Using Multiple Call Controllers of Voice-Band Calls"
- Patent Identification: U.S. Patent No. 7,460,520, "Apparatus and Method for Using Multiple Call Controllers of Voice-Band Calls," issued December 2, 2008.
The Invention Explained
- Problem Addressed: As telecommunications networks evolved from circuit-switched (for voice) to converged packet-switched networks (for voice and data), a technical challenge arose. There was a need for a "voice gateway" that could interface with both network types and simultaneously support the multitude of different call control protocols used by legacy telephony switches and modern softswitches (Compl. ¶¶11, 14; ’520 Patent, col. 1:46-56).
- The Patented Solution: The patent describes a voice gateway architecture that uses a common "internal protocol" to act as an intermediary. The gateway comprises multiple "protocol endpoints," where each endpoint is tailored to a specific external protocol (e.g., from a circuit-switched controller or a packet-based device). Each endpoint is configured to "map" messages from its external protocol to the gateway's internal protocol, and vice versa. A central "protocol adapter" then routes these standardized internal messages between the appropriate endpoints, enabling communication between otherwise incompatible systems (’520 Patent, Abstract; col. 9:14-40; Fig. 7). This design abstracts the protocol-specific details, allowing the gateway to flexibly manage calls across different network technologies (Compl. ¶¶20-21).
- Technical Importance: This architecture offered a scalable method for building voice gateways that could ensure interoperability between legacy and emerging network equipment during the industry’s critical migration to VoIP (’520 Patent, col. 1:46-56).
Key Claims at a Glance
- The complaint identifies independent claim 27 as being infringed (Compl. ¶37).
- The essential elements of independent claim 27 include:
- An apparatus that connects a local packet network (LPN) and a circuit-switched network.
- A plurality of protocol endpoints, each configured to: receive external call control messages, map them to an internal protocol's messages, receive routed internal messages, and map those internal messages back to external messages.
- At least one endpoint configured to receive messages from a call controller on the circuit-switched network.
- At least a second endpoint configured to receive messages from an integrated access device (IAD) on the LPN.
- A protocol adapter configured to route the internal call control messages between the endpoints.
- The complaint’s prayer for relief seeks judgment on "one or more claims," suggesting the possibility that dependent claims may also be asserted (Compl. p. 16).
III. The Accused Instrumentality
Product Identification
- Unify devices, specifically the Openscape 4000 system (Compl. ¶37).
Functionality and Market Context
- The complaint alleges the Openscape 4000 is an apparatus that connects an LPN (comprising devices like OpenScape access points and SIP phones) with a circuit-switched network such as the PSTN (Compl. ¶38). It is alleged to provide a "plurality of protocol endpoints" that interface with various devices (e.g., legacy analog phones, SIP trunks) by receiving external call control signals and mapping them to an "internal protocol" for routing. The system is also alleged to contain a "protocol adapter" to manage the routing of these internal messages between endpoints (Compl. ¶¶39, 42).
IV. Analysis of Infringement Allegations
The complaint includes Figure 6A from the patent, a block diagram illustrating an embodiment of the claimed voice gateway architecture with distinct interfaces and modules (Compl. ¶17). While illustrative of the patented technology, the complaint uses high-level product datasheets, rather than technical schematics of the accused product, to support its infringement contentions.
’520 Patent Infringement Allegations
| Claim Element (from Independent Claim 27) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| An apparatus connecting a local packet network (LPN) and a circuit-switched network... | The Accused Instrumentality connects an LPN (of OpenScape access points, SIP phones) and a circuit-switched network (PSTN). | ¶38 | col. 23:4-5 |
| a plurality of protocol endpoints, each protocol endpoint configured to receive external call control messages...and to map the external call control messages to corresponding internal call control messages of an internal protocol for routing to another... | The Accused Instrumentality provides a plurality of protocol endpoints (e.g., router/switch-devices, interfaces for analog phones) that receive external messages and map them to corresponding internal messages of an internal protocol for routing. | ¶39 | col. 23:6-12 |
| wherein at least one of the plurality of protocol endpoints is configured to receive the external call control messages from a first call controller associated with the circuit-switched network... | At least one endpoint is configured to receive messages from a call controller associated with the circuit-switched network (e.g., PSTN central office). | ¶40 | col. 24:5-8 |
| and at least a second of the plurality of protocol endpoints is configured to receive the external call control messages from an integrated access device (IAD) associated with the LPN... | At least a second endpoint is configured to receive messages from an IAD (e.g., OpenScape access points) associated with the LPN. | ¶41 | col. 24:9-12 |
| a protocol adapter configured to route the internal call control messages from the mapping protocol endpoint to the another protocol endpoint. | The Accused Instrumentality has a protocol adapter that routes internal call control messages to the appropriate endpoints. | ¶42 | col. 24:13-16 |
Identified Points of Contention
- Technical Questions: A primary question will be whether the accused Openscape 4000 system actually performs the claimed "map[ping]... to corresponding internal call control messages of an internal protocol." The infringement case may depend on evidence demonstrating that the accused system uses a distinct, mediating internal protocol, rather than performing direct protocol-to-protocol translation or simply passing data through a software bridge. The complaint's allegations on this point are supported by marketing documents rather than architectural evidence (Compl. ¶39).
- Scope Questions: The definition of "protocol endpoint" will be subject to dispute. Does a software driver or a physical port on the accused device meet the definition of a "protocol endpoint" as described in the patent, which includes the specific functions of mapping to and from an internal protocol?
V. Key Claim Terms for Construction
"internal call control message of an internal protocol"
- Context and Importance: This term is central to the patent's claims and its distinction over the prior art, as argued during prosecution (Compl. ¶¶23, 27). The infringement analysis will turn on whether the accused device's internal workings can be characterized as using such a protocol. Practitioners may focus on this term because its construction will determine whether any intermediate data representation suffices, or if a more formally defined, protocol-like message set is required.
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent states that "All Protocol Endpoints 701, 702 support the same set of internal messages 703," which could suggest that any common message format shared between internal components qualifies (’520 Patent, col. 9:31-32).
- Evidence for a Narrower Interpretation: The complaint emphasizes that the invention is "neither generic, nor conventional" and uses "non-generic components" because it employs an internal protocol (Compl. ¶¶21, 27). A defendant may argue this prosecution history, along with specific embodiments like Figure 7 (showing messages like
EST_BEARER_REQ), limits the term to a defined set of command-like messages rather than any internal data structure (’520 Patent, col. 9:36-40).
"map"
- Context and Importance: This term defines the key function performed by the "protocol endpoints." Its definition is critical because the complaint alleges the prior art was deficient for merely "pass[ing] data forward" rather than performing the claimed mapping (Compl. ¶25).
- Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The specification does not explicitly define "map," which could support an argument for its plain and ordinary meaning, covering a wide range of transformations or correlations between external and internal messages.
- Evidence for a Narrower Interpretation: The prosecution history argument distinguishing the invention from prior art that "did not disclose 'mapping to a corresponding internal call control message'" suggests that "map" requires a substantive transformation into a message of a different, distinct protocol, not just repackaging or re-routing data (Compl. ¶23).
VI. Other Allegations
- Indirect Infringement: The complaint makes a general allegation of induced infringement, stating that Defendant "promoted the infringing use... through advertising the use of the Accused Instrumentality to connect an IAD and a circuit-switched network" (Compl. ¶43).
- Willful Infringement: No allegations of willful infringement are made. The complaint asserts only that Defendant had "at least constructive notice of the '520 patent by operation of law" (Compl. ¶46).
VII. Analyst’s Conclusion: Key Questions for the Case
- A core issue will be one of claim construction and scope: can the term "internal call control message of an internal protocol," as limited by the specification and prosecution history, be construed to read on the internal software architecture of the accused Openscape 4000 system? The outcome will likely depend on whether the patent requires a formally defined, command-based internal language or if any common intermediate data representation falls within the claim’s scope.
- A key evidentiary question will be one of technical operation: what is the actual software architecture of the accused product? Discovery will be critical to determine whether the Openscape 4000 system performs the specific "mapping" function to a distinct internal protocol as claimed, or if its method for handling disparate protocols is fundamentally different from the architecture described in the ’520 patent.