2:25-cv-00454
Lattice Tech LLC v. Guardian Protection Services Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Lattice Technologies LLC (NM)
- Defendant: Guardian Protection Services Inc. (PA)
- Plaintiff’s Counsel: Garibian Law Offices, P.C.; Rabicoff Law LLC
- Case Identification: 2:25-cv-00454, E.D. Pa., 01/27/2025
- Venue Allegations: Venue is alleged to be proper based on Defendant maintaining an established place of business within the district and having committed alleged acts of infringement in the district.
- Core Dispute: Plaintiff alleges that Defendant’s emergency response products and services infringe a patent related to systems and methods for providing emergency response using internet-protocol-based communications.
- Technical Context: The technology concerns personal emergency response systems (PERS) that utilize internet and cellular networks to connect a user's portable device to a central monitoring service for notifying designated contacts.
- Key Procedural History: The complaint states that Plaintiff is the assignee of the patent-in-suit, possessing all rights to enforce it. No other significant procedural events are mentioned.
Case Timeline
| Date | Event |
|---|---|
| 2003-07-22 | '153 Patent Priority Date (via U.S. Prov. App. 60/489,022) |
| 2012-01-17 | '153 Patent Issue Date |
| 2025-01-27 | Complaint Filing Date |
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"
The Invention Explained
- Problem Addressed: The patent describes prior art emergency response systems as being inadequate, particularly those relying on public switched telephone networks (PSTN) that tether a user to a speakerphone base station. Such systems limit a user's ability to communicate the nature of an emergency if they are not near the device and may not effectively combine user tracking with internet-based notification methods ('153 Patent, col. 1:26-42).
- The Patented Solution: The invention discloses a system where a portable user device (32) communicates over the Internet (36) with a "monitoring database" (34). This database stores a user-defined, prioritized list of emergency contacts. Upon receiving an alert from the user device, the database automatically processes this list, attempting to notify contacts via various methods, including Voice-over Internet Protocol (VoIP) and SMS, until a contact confirms acceptance. The system is designed to establish bidirectional audio communication between the user and the responding contact ('153 Patent, Abstract; col. 2:9-26; Fig. 1).
- Technical Importance: The technology aimed to untether emergency response from landlines by integrating portable device technology, GPS, and IP-based communication networks to create a more mobile and responsive personal safety system ('153 Patent, col. 1:60-65).
Key Claims at a Glance
- The complaint asserts infringement of "one or more claims" and "Exemplary '153 Patent Claims" identified in an attached exhibit, but does not specify claim numbers in the body of the complaint (Compl. ¶11). Independent Claim 1 is representative of the patented method.
- Essential elements of independent Claim 1 include:
- establishing a monitoring database with an identification for a user device;
- storing a plurality of contacts and contact methods in the database;
- arranging the contacts and methods in a user-determined priority order;
- establishing IP addresses for both the user device and the monitoring database;
- establishing communication between them over the Internet;
- transmitting an alert from the user device to the database;
- automatically establishing communication with contacts according to the priority order using internet protocols or PSTN;
- receiving an "accepted," "not accepted," or "unresponsive" response from the contact; and
- automatically establishing communication with another contact according to the priority order until an "accepted response" is received.
- The complaint reserves the right to assert additional claims (Compl. ¶11).
III. The Accused Instrumentality
Product Identification
The complaint identifies the accused instrumentalities as the "Exemplary Defendant Products" (Compl. ¶11). The specific products are detailed in charts within Exhibit 2, which is incorporated by reference but was not filed as a separate document with the complaint (Compl. ¶16).
Functionality and Market Context
The complaint alleges the accused products are part of an emergency response system that practices the technology claimed by the '153 Patent (Compl. ¶16). It alleges Defendant distributes "product literature and website materials" detailing the products' use (Compl. ¶14). However, the complaint itself does not provide sufficient detail for an independent analysis of the accused instrumentality's specific technical functionality or market position.
No probative visual evidence provided in complaint.
IV. Analysis of Infringement Allegations
The complaint incorporates by reference claim charts in its Exhibit 2, which was not publicly filed with the main complaint document (Compl. ¶17). The following analysis of infringement allegations against representative Claim 1 is based on the complaint's narrative assertions.
'153 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| establishing a monitoring database (34) including an identification for a user device (32); | The complaint alleges Defendant's system includes a back-end infrastructure that functions as a monitoring database, which stores information associated with specific user devices (Compl. ¶11, ¶16). | ¶11, ¶16 | col. 13:25-28 |
| storing in the monitoring database (34) a plurality of contacts to be contacted...and a plurality of contact methods; | Defendant's system allegedly allows users to create and store a list of emergency contacts and their preferred contact methods (e.g., phone, text) within its service database (Compl. ¶11, ¶16). | ¶11, ¶16 | col. 13:29-33 |
| arranging the contacts and contact methods in a priority order determined by the user; | Defendant's system allegedly provides for the user-defined prioritization of emergency contacts, dictating the sequence in which they are notified (Compl. ¶11, ¶16). | ¶11, ¶16 | col. 13:34-36 |
| transmitting an alert from the user device (32) to the monitoring database (34); | Defendant's user devices are allegedly capable of transmitting an emergency alert signal to its central monitoring system when activated by a user (Compl. ¶11, ¶16). | ¶11, ¶16 | col. 13:41-43 |
| automatically establishing communication with one of the contacts...according to the priority order...using one of internet protocols and public-switched telephone networks; | Upon receiving an alert, Defendant's system allegedly automatically initiates contact with the highest-priority contact on the user's list using network-based communication methods (Compl. ¶11, ¶16). | ¶11, ¶16 | col. 13:44-53 |
| receiving one of an accepted and a not accepted and an unresponsive response...from the contact; and automatically establishing communication with another contact...until the monitoring database receives an accepted response. | The complaint alleges Defendant's system includes an automated notification logic that proceeds to the next contact on the priority list if a prior contact does not provide an "accepted response," continuing this process until acceptance is confirmed (Compl. ¶11, ¶16). | ¶11, ¶16 | col. 13:54-65 |
- Identified Points of Contention:
- Technical Questions: A central question will be whether the accused system's notification logic performs the specific, iterative process claimed: automatically attempting to contact individuals in a prioritized sequence until an "accepted response" is affirmatively received. The complaint does not provide specific evidence detailing this operational logic for the accused products.
- Scope Questions: The case may raise the question of whether the term "monitoring database", as described in the context of the patent’s 2003 priority date, can be construed to read on the architecture of a modern emergency response service, which may involve distributed, cloud-based server infrastructure rather than the more centralized system depicted in the patent ('153 Patent, Fig. 1).
V. Key Claim Terms for Construction
The Term: "automatically establishing communication with another contact according to the priority order with the monitoring database (34) until the monitoring database receives an accepted response"
Context and Importance: This limitation defines the core automated escalation logic of the invention. The outcome of the infringement analysis will likely depend on whether the Defendant's system operates in this precise manner. Practitioners may focus on this term because it requires not just sequential notification, but a specific condition for halting the sequence: receipt of an "accepted response."
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: A party could argue the term covers any automated system that tries contacts sequentially and stops upon receiving any form of acknowledgment that a human has been notified, pointing to the general description of notifying contacts ('153 Patent, col. 4:10-17).
- Evidence for a Narrower Interpretation: A party could argue this requires a specific, closed-loop process where the system continues to cycle through the contact list until it receives a discrete "accepted" signal (e.g., a key press or specific verbal command), as distinguished from a simple "no answer" or voicemail. The patent's detailed flowcharts, such as Figure 14 showing distinct paths for "Rejected selected" versus accepted, may support a narrower reading requiring an active confirmation ('153 Patent, col. 9:57-64; Fig. 14).
The Term: "monitoring database (34)"
Context and Importance: The infringement case requires showing that the Defendant's back-end system is equivalent to the claimed "monitoring database". The definition will be critical in determining if modern, distributed architectures fall within the claim's scope.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: A party could argue the term should be read broadly to mean any server or system of servers that performs the claimed functions of storing user data, contact lists, and processing alerts ('153 Patent, col. 4:1-4).
- Evidence for a Narrower Interpretation: A party could point to the specification's description and Figure 1, which illustrates a more specific architecture including "Servers ASP Hosted," a "NMS VOIP Gateway," and "Data\App\WEB Servers," to argue the term implies a more integrated and centralized system than what may be used in modern cloud services ('153 Patent, Fig. 1; col. 4:5-9).
VI. Other Allegations
- Indirect Infringement: The complaint alleges induced infringement, stating that Defendant provides "product literature and website materials" that instruct customers on how to use the accused products in a manner that allegedly infringes the '153 Patent (Compl. ¶14, ¶15).
- Willful Infringement: The complaint alleges that Defendant has had "Actual Knowledge of Infringement" since being served with the complaint and has continued its allegedly infringing activities (Compl. ¶13, ¶14). This allegation forms a basis for post-suit willful infringement.
VII. Analyst’s Conclusion: Key Questions for the Case
- A key evidentiary question will be one of functional equivalence: because the complaint's specific infringement allegations are contained in an un-provided exhibit, a central issue will be whether Plaintiff can produce evidence that the accused system's automated notification logic precisely mirrors the claimed method of escalating through a priority list until a specific "accepted response" is received, as required by the patent.
- A core issue will be one of definitional scope: can the term "monitoring database," which is rooted in the technological context of the patent’s 2003 priority date, be construed to cover the potentially dissimilar architecture of a modern, cloud-based emergency response service?