DCT
4:17-cv-03387
Atticus Research Corp v. Mmsoft Design Ltd
Key Events
Amended Complaint
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Atticus Research Corporation (Texas)
- Defendant: MMSOFT Design Limited (Ireland)
- Plaintiff’s Counsel: Polasek, Quisenberry & Errington, LLP.
- Case Identification: 4:17-cv-03387, S.D. Tex., 03/09/2018
- Venue Allegations: Plaintiff alleges venue is proper because Defendant has transacted business and has customers in the district, and its CEO attended a forum in Texas.
- Core Dispute: Plaintiff alleges that Defendant’s Pulseway remote monitoring software infringes a patent related to remote software fault detection and recovery.
- Technical Context: The technology concerns remote monitoring and management (RMM) software, a field critical for information technology administrators to manage computer systems without being physically present.
- Key Procedural History: This First Amended Complaint asserts infringement based on claim constructions from a prior, unspecified proceeding before Judge Rosenthal of the same court. Plaintiff alleges Defendant had knowledge of the patent at least from the time it received the original complaint in this action.
Case Timeline
| Date | Event |
|---|---|
| 1999-11-17 | ’937 Patent Priority Date |
| 2003-05-20 | ’937 Patent Issue Date |
| 2017-09-01 | Defendant's CEO allegedly attends forum in San Antonio, TX |
| 2018-03-09 | First Amended Complaint Filing Date |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 6,567,937 - Technique For Remote State Notification And Software Fault Recovery, Issued May 20, 2003
The Invention Explained
- Problem Addressed: The patent describes the high cost and inefficiency of ensuring continuous operation of critical software applications. Prior methods required either redundant computer systems or constant on-site human monitoring, which was expensive and could involve delays if technical personnel had to travel to a site to fix a fault (’937 Patent, col. 1:7-46; Compl. ¶¶ 10-11).
- The Patented Solution: The invention is a system that automates this process. It monitors a software application for a fault (e.g., a "DEAD" or "HUNG" state), automatically sends an alert to a remote device (like a pager or phone), and allows a user to initiate a corrective action remotely. Crucially, if the remote user does not respond within a pre-set time, the system initiates a default recovery action on its own, ensuring the problem is addressed without depending on an immediate human response (’937 Patent, Abstract; Fig. 2; col. 2:5-16).
- Technical Importance: This approach provided a method for remote, interactive software maintenance that could reduce the need for dedicated on-site personnel and improve the reliability of fault recovery (’937 Patent, col. 6:62-67).
Key Claims at a Glance
- The complaint asserts independent claim 16 (Compl. ¶51).
- The essential elements of claim 16 are:
- A program storage device with instructions for a computer processor to:
- determine a state of a process executing on the computer processor;
- transmit a first signal to a remote device if the process is in a first state indicative of a fault condition;
- initiate a first software fault recovery action to correct the fault condition in accordance with a second signal, the second signal received in response to the first signal; and
- initiate a second software fault recovery action if the second signal is not received within a specified time period.
III. The Accused Instrumentality
Product Identification
- The accused product is Defendant's "Pulseway" software, described as "Real-Time Remote Monitoring and Management Software" (Compl. ¶16).
Functionality and Market Context
- The Pulseway software allows IT administrators to "remotely monitor and control IT systems from any device" (Compl. ¶18). It functions via two components: a "Pulseway Agent" installed on the computer to be monitored and a "Pulseway app" on a remote device, such as a smartphone (Compl. ¶21). The software sends alerts on "critical IT system issues" and enables the user to "fix them on the go by sending commands" from the remote device to, for example, restart services or manage processes (Compl. ¶19c-d). A screenshot provided in the complaint shows a smartphone displaying a notification that the "W3SVC" service has stopped (Compl. ¶48, Ex. B). Plaintiff alleges the software is used by 3,900 customers to manage 780,000 systems (Compl. ¶26).
IV. Analysis of Infringement Allegations
’937 Patent Infringement Allegations
| Claim Element (from Independent Claim 16) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A program storage device, readable by a computer processor, comprising: instructions stored on the program storage device... | The Pulseway Agent is software downloaded and stored on the memory of a customer's computer, which is a program storage device readable by a processor (Compl. ¶¶ 55-56, 59). | ¶59 | col. 5:18-24 |
| determine a state of a process executing on the computer processor; | A user configures a "Rule" in the Pulseway Agent to monitor the state of a specific process, such as the "W3SVC" service, to determine if its state is "stopped" (Compl. ¶¶ 40, 63). | ¶¶ 40, 63 | col. 5:56-61 |
| transmit a first signal to a remote device if the process is in a first state indicative of a fault condition; | When the Pulseway Agent determines the monitored service has stopped (a fault condition), its instructions cause the processor to send a notification to the user's smartphone (the remote device) (Compl. ¶¶ 43, 69). The complaint provides a screenshot of this notification as Exhibit B (Compl. ¶48). | ¶¶ 43, 69 | col. 6:54-59 |
| initiate a first software fault recovery action to correct the fault condition in accordance with a second signal...received in response...; and | In response to the notification, the user can navigate the Pulseway app and click a "Start Service" button, which sends a command (the "second signal") back to the Pulseway Agent to restart the service (the "first software fault recovery action") (Compl. ¶¶ 44, 76). The complaint provides a screenshot of the "Start Service" button as Exhibit C (Compl. ¶75). | ¶¶ 44, 76 | col. 6:8-12 |
| initiate a second software fault recovery action if the second signal is not received within a specified time period. | The user can configure a second "Rule" to automatically "run a task" to restart the service if it remains stopped for a specified time (e.g., one minute) (Compl. ¶45). If the user does not send the "Start Service" command within that minute, this second rule triggers and initiates the restart (the "second software fault recovery action") (Compl. ¶¶ 46, 50, 83). The complaint alleges that this automatic restart is contingent on the command not being sent within the time period (Compl. ¶50). | ¶¶ 45, 50, 83 | col. 6:1-6 |
- Identified Points of Contention:
- Scope Questions: The complaint's infringement theory rests heavily on claim constructions purportedly adopted in a prior case (Compl. ¶¶ 66, 72, 79). A central point of contention may be whether those constructions are binding or persuasive in this case and how they apply to the Pulseway product's specific architecture.
- Technical Questions: Plaintiff alleges that a user-configured system of two separate "Rules" that "work together in unison" satisfies the integrated logic of Claim 16 (Compl. ¶47). A technical question for the court will be whether the second rule (automatic restart) is truly triggered by the "non-receipt of a signal" as the claim requires, or if it is merely an independent, parallel timed task that is not logically contingent on the first rule's communication loop.
V. Key Claim Terms for Construction
The complaint puts forth constructions for several claim phrases from a prior proceeding. The dispute will likely center on the application of these constructions to the accused product.
The Term: "initiate a first software fault recovery action...in accordance with a second signal"
Context and Importance: This term is central to the remote-control aspect of the invention. The complaint alleges that the user clicking a "Start Service" button in the Pulseway app constitutes the "second signal" that initiates recovery (Compl. ¶¶ 75-76). Practitioners may focus on whether this generic UI command meets the definition of a "second signal" that "instructs" the recovery, as framed by the cited prior construction (Compl. ¶72).
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent states that the system initiates a recovery action "specified in the response message," which could be read broadly to cover any user-initiated command that results in a fix (’937 Patent, col. 6:9-12).
- Evidence for a Narrower Interpretation: The patent provides an illustrative alert message in Figure 4 that includes explicit, pre-defined "RESPONSE OPTION 1" and "RESPONSE OPTION 2." This may support a narrower view that the "second signal" must be a selection from options presented in the initial alert, rather than a command from a separate UI screen.
The Term: "initiate a second software fault recovery action if the second signal is not received within a specified time period"
Context and Importance: This term defines the automatic, failsafe feature. The complaint alleges that a second, timed "Rule" in Pulseway meets this limitation (Compl. ¶¶ 45, 83). The key question is one of logical contingency: does the automatic action trigger because the remote command was not received?
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent abstract describes initiating a "default recovery action" if a response message is not received, suggesting a pre-configured, automatic fallback (’937 Patent, Abstract).
- Evidence for a Narrower Interpretation: The flowchart in Figure 2 presents a direct logical test: "RESPONSE RECEIVED?" (208). If "NO," the system proceeds to the default action (210). This may support an argument that the claimed system requires an integrated logical check for a specific response signal, which may be different from the operation of two separate, user-configured rules in the accused product.
VI. Other Allegations
- Indirect Infringement: The complaint alleges inducement, stating that MMSOFT provides its software with instructions, such as user manuals and website information, that encourage and teach customers how to use the software in an infringing manner (e.g., setting up monitoring, receiving alerts, and remotely restarting services) (Compl. ¶¶ 89, 91).
- Willful Infringement: Willfulness is alleged based on MMSOFT's continued infringement after having knowledge of the patent, with knowledge alleged to have begun at least upon receipt of the original complaint in the action (Compl. ¶¶ 51, 89).
VII. Analyst’s Conclusion: Key Questions for the Case
- 1. Applicability of Prior Rulings: A threshold issue will be the legal and factual applicability of the claim constructions from a prior case, which form the foundation of the plaintiff's infringement theory. The case may turn on whether these constructions are adopted and how they map onto the accused Pulseway software.
- 2. Integrated System vs. User Configuration: A key evidentiary question will be one of technical operation: does the accused Pulseway software, when configured by a user with two separate "Rules" for notification and timed restart, perform the integrated, sequential logic required by Claim 16? The court will need to determine if the automatic restart is functionally triggered by the non-receipt of the remote command, as claimed.
- 3. Sufficiency of Inducement Allegations: The court may examine whether MMSOFT's general instructions for using its RMM software features constitute the specific intent required to induce its customers to combine those features in the precise sequence patented by claim 16.