Lattice Tech LLC v. TELUS Communications US Inc

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Lattice Technologies LLC (NM)
  • Defendant: TELUS Communications (US.) Inc. (DE)
  • Plaintiff’s Counsel: Garibian Law Offices, P.C.; Rabicoff Law LLC
• Case Identification: 1:25-cv-00111, D. Del., 01/27/2025
• Venue Allegations: Plaintiff alleges venue is proper in the District of Delaware because Defendant has an established place of business in the district and has committed alleged acts of infringement there.
• Core Dispute: Plaintiff alleges that Defendant infringes a patent related to systems and methods for providing emergency response services to a user via a personal device connected to a monitoring database.
• Technical Context: The technology concerns emergency alert systems that leverage internet protocols, including Voice-over-IP (VoIP), to automate communication between a user's device and a prioritized list of emergency contacts.
• Key Procedural History: The complaint does not mention any prior litigation, Inter Partes Review (IPR) proceedings, or licensing history related to the patent-in-suit.

Case Timeline

II. Technology and Patent(s)-in-Suit Analysis

U.S. Patent No. 8,098,153 - System and method of providing emergency response to a user carrying a user device

• Patent Identification: U.S. Patent No. 8,098,153, System and method of providing emergency response to a user carrying a user device, issued January 17, 2012. (Compl. ¶8-9).

The Invention Explained

• Problem Addressed: The patent describes prior art emergency response systems as being limited. For example, systems connected to a Public Switched Telephone Network (PSTN) may require a user to be close to a stationary speakerphone, and mobile monitoring systems did not effectively combine user tracking with the user's ability to initiate contact with responders over the internet. (’153 Patent, col. 1:26-65).
• The Patented Solution: The invention is a system comprising a user device and a "monitoring database" (server) that communicate over the internet using Internet Protocol (IP). (’153 Patent, Abstract). The database stores a prioritized list of contacts for each user; when the user device sends an alert, the database automatically processes the priority list to notify contacts using internet protocols (like VoIP) or traditional telephone networks until a response is confirmed. (’153 Patent, col. 2:9-25; col. 4:11-24).
• Technical Importance: The described approach sought to automate emergency notifications by leveraging modern IP-based networks, which could reduce reliance on human intervention and the limitations of legacy PSTN-only systems. (’153 Patent, col. 9:36-42).

Key Claims at a Glance

• The complaint alleges infringement of "one or more claims" without specifying them in the body of the complaint, instead referencing an external exhibit. (Compl. ¶11). Method claim 1 is representative of the core invention.
• Independent Claim 1 requires:
  • Establishing a monitoring database with a user device identification.
  • Storing in the database a plurality of contacts and contact methods.
  • Arranging the contacts and methods in a user-determined priority order.
  • Establishing an IP address for the monitoring database and for the user device.
  • Establishing communication over the Internet between the database and the device.
  • Transmitting an alert from the device to the database.
  • Automatically establishing communication with a contact from the priority list using internet protocols or PSTN.
  • Receiving an "accepted," "not accepted," or "unresponsive" response from the contact.
  • Automatically establishing communication with another contact from the priority list until an "accepted response" is received.
• The complaint does not explicitly reserve the right to assert dependent claims.

III. The Accused Instrumentality

Product Identification

The complaint does not identify any specific accused products, services, or methods by name. (Compl. ¶11). It refers generally to "Exemplary Defendant Products" that are purportedly identified in charts incorporated as Exhibit 2, an exhibit not filed with the complaint. (Compl. ¶11, 16).

Functionality and Market Context

The complaint does not provide sufficient detail for analysis of the functionality or market context of the accused instrumentalities. It makes only a general allegation that Defendant makes, uses, sells, or imports products that "practice the technology claimed by the '153 Patent." (Compl. ¶16).

IV. Analysis of Infringement Allegations

The complaint incorporates infringement allegations by reference to an external claim chart exhibit that was not provided. (Compl. ¶17). Therefore, a detailed claim chart summary cannot be constructed. The narrative theory of infringement is that unspecified "Exemplary Defendant Products" practice the technology claimed in the ’153 Patent and satisfy all elements of the "Exemplary '153 Patent Claims." (Compl. ¶16).

No probative visual evidence provided in complaint.

Identified Points of Contention

Based on the patent’s language and the general allegations, the infringement analysis may raise several questions:

• Scope Questions: The claims require both a "monitoring database" and a "user device" to have established IP addresses. A point of dispute may be what evidence demonstrates that Defendant's system architecture meets this limitation, particularly for the end-user device.
• Technical Questions: Claim 1 requires a specific, automated, and sequential notification logic where the system proceeds through a priority list until an "accepted response" is received. A central question will be whether the accused system performs this precise iterative notification and response-handling process, or if it employs a more general or different notification scheme. The patent's detailed flowcharts, such as FIG. 13, illustrate a multi-level priority logic that may set a high bar for infringement. (’153 Patent, Fig. 13).

V. Key Claim Terms for Construction

"monitoring database"

• Context and Importance: This term defines a central component of the claimed system. Its construction will determine what type of server-side architecture falls within the scope of the claims. Practitioners may focus on this term because its definition could either be limited to the specific database functions described in the patent or cover a broader range of modern cloud-based user management systems.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The specification introduces the term broadly as being "preferably a server" connected to the internet to receive and transmit signals. (’153 Patent, col. 4:3-5).
  • Evidence for a Narrower Interpretation: The specification also describes the "monitoring database" with very specific functionalities, including storing a list of contacts with multiple, ordered contact methods, geofence information, and providing administrator-level access to certain contacts to modify the list. (’153 Patent, col. 4:11-22, 52-54).

"automatically establishing communication with another contact... until the monitoring database receives an accepted response"

• Context and Importance: This limitation defines the core automated logic of the invention. Its construction is critical because it requires not just notification, but a specific, state-dependent, sequential process that continues until a specific condition ("accepted response") is met.
• Intrinsic Evidence for Interpretation:
  • Evidence for a Broader Interpretation: The claim language itself does not specify the means of acceptance (e.g., key press, voice command), which could support a construction covering various forms of automated confirmation.
  • Evidence for a Narrower Interpretation: The patent’s detailed flowcharts illustrate a highly specific process. For example, Figure 14 shows discrete steps for handling busy signals, no-answers, invalid replies, and rejections, before moving to the next contact. (’153 Patent, Fig. 14, steps 270-282). An argument could be made that "automatically establishing communication" requires this comprehensive, pre-programmed logic.

VI. Other Allegations

• Indirect Infringement: The complaint alleges induced infringement, stating that Defendant sells the accused products to customers for use in a manner that infringes. (Compl. ¶15). This inducement is allegedly supported by Defendant's distribution of "product literature and website materials" that instruct end users on the infringing use. (Compl. ¶14).
• Willful Infringement: The complaint does not use the term "willful." It alleges that Defendant has had "Actual Knowledge of Infringement" from the date of service of the complaint. (Compl. ¶13). This forms a basis for alleging post-suit willful infringement.

VII. Analyst’s Conclusion: Key Questions for the Case

• A central issue will be one of evidentiary proof: given the complaint's lack of specific factual allegations about the accused products, the case will depend on whether discovery reveals that Defendant’s systems in fact perform the highly specific, multi-step automated notification and response-handling method recited in the claims.
• The case will also turn on a question of functional scope: does the accused system's notification logic perform the same function in substantially the same way to achieve the same result as the iterative, priority-based, and response-gated process detailed in the '153 patent's specification and flowcharts? A potential defense may arise if the accused system's architecture or notification logic differs fundamentally from the patent's specific implementation.