DCT

2:17-cv-00176

Uniloc USA Inc v. Zendesk Inc

Key Events
Complaint
complaint

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 2:17-cv-00176, E.D. Tex., 03/06/2017
  • Venue Allegations: Plaintiff alleges venue is proper in the Eastern District of Texas because Defendant is deemed to reside there, has committed acts of infringement in the district, and has transacted business in Texas, including providing services to Texas-based customers and attending conferences in the state.
  • Core Dispute: Plaintiff alleges that Defendant’s customer service software platform infringes a patent related to a method and apparatus for remote software maintenance and updates.
  • Technical Context: The technology concerns centralized systems for distributing software updates and fixes to remote computers, a foundational element of modern cloud-based software and application management.
  • 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

Date Event
1994-12-28 '228 Patent Priority Date
2000-08-29 '228 Patent Issue Date
2017-03-06 Complaint Filing Date

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

U.S. Patent No. 6,110,228 - "METHOD AND APPARATUS FOR SOFTWARE MAINTENANCE AT REMOTE NODES," issued August 29, 2000

The Invention Explained

  • Problem Addressed: The patent describes the state of the art in the early 1990s, where updating software on remote computers in a distributed network was complex and lacked a common methodology. Different programs and operating systems had unique update procedures, and ensuring that all necessary prerequisite fixes (or "requisite fixes") were applied correctly was a significant manual effort for system programmers ('228 Patent, col. 2:5-23).
  • The Patented Solution: The invention proposes a centralized "service facility" that manages software updates. A customer at a "remote location" uses a common interface to send a service request (e.g., for an update) to the central site. The central site, which exclusively holds the program's source code, performs "service research" to determine all necessary changes, applies the fix, and returns a new, ready-to-be-executed version of the program to the customer. This process is depicted in the patent's Figure 2, which shows a customer system (50) interacting with a central service facility (34) that manages service requests and applies fixes ('228 Patent, Abstract; col. 2:47-67; Fig. 2).
  • Technical Importance: This centralized architecture aimed to simplify software maintenance by offloading the complexity of dependency management and update application from the end-user to a central server, thereby improving efficiency and reducing errors ('228 Patent, col. 3:5-9).

Key Claims at a Glance

  • The complaint asserts independent claims 1 and 18, among others (Compl. ¶15).
  • Independent Claim 1 (Method) includes the following essential elements:
    • Interactively receiving a request for a computer program service from a customer at a remote location interface, with optional service incorporation instructions.
    • Providing the received request over a computer network to a service facility at a central computer site.
    • Determining the components of the requested service at the central computer site.
    • Providing the results of the requested service over the computer network back to the customer at the remote location interface.
  • The complaint reserves the right to assert numerous dependent claims (Compl. ¶15).

III. The Accused Instrumentality

Product Identification

  • The "Zendesk Support Service," which is described as comprising "software and associated backend server architecture" (Compl. ¶15).

Functionality and Market Context

  • The complaint alleges the accused service provides software that allows for customer service requests (Compl. ¶11). The functionality at issue involves a system where users can manage computer programs through a user interface. This interface, presented via screenshots, is an "Apps Marketplace" that allows a user to manage "Currently Installed" apps, including functionality to "Update" or "Download" them (Compl. ¶¶ 11-13; p. 3-4). The complaint states this system allows for "receiving users' requests for service (for example, upgrades), determining the service requested (for example, provide an upgrade), and providing the upgrade to the user" (Compl. ¶15). The screenshot on page 4 of the complaint shows a menu with options to "Update" or "Download" a specific app version. (Compl. p. 4, Image "Download a copy of the app..."). A separate visual on the same page gives explicit instructions on how to "update a private app" by clicking a cog icon and selecting "Update." (Compl. p. 4, Image "To update a private app").

IV. Analysis of Infringement Allegations

The complaint makes narrative allegations rather than providing a formal claim chart. The following table summarizes these allegations against the elements of independent claim 1.

'228 Patent Infringement Allegations

Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
A method of applying service to a computer program... comprising the steps of: interactively receiving a request for a computer program service from a customer at a remote location interface... Zendesk's service provides a user interface on a remote user's computer where a user can request services, such as by clicking an "Update" or "Download" button for an application in its "Apps Marketplace." The screenshot on page 4 illustrates this interactive request process. ¶¶11, 12, 15; p. 4 col. 25:39-44
... with optional service incorporation instructions of the remote location customer; The complaint does not provide sufficient detail for analysis of this specific element, though the ability to select different actions like "Update" or "Download" could be argued to constitute such instructions. ¶15 col. 25:40-44
providing the received request for service over the computer network to a service facility at the central computer site; Zendesk's "backend server architecture" allegedly receives the user's request for service (e.g., an upgrade) from the remote user's location. ¶15 col. 25:12-15
determining the components of the requested service at the central computer site; and The backend server architecture allegedly "determin[es] the service requested (for example, provide an upgrade)." ¶15 col. 26:45-47
providing the results of the requested service over the computer network back to the customer at the remote location interface. The Zendesk service allegedly provides the result, such as an upgrade, back to the user. The "Download" functionality shown in the screenshot on page 4 is presented as evidence of the result being provided back to the customer. ¶15; p. 4 col. 26:12-16
  • Identified Points of Contention:
    • Scope Questions: A central question may be whether the '228 patent, filed in 1994 with descriptions tied to mainframe-era software like "VM/ESA," can be construed to cover a modern, web-based SaaS application marketplace. The defense may argue that terms like "remote location interface" and "service facility" are limited by the specification to the specific client-server architecture disclosed and do not read on a web browser interacting with a cloud platform.
    • Technical Questions: What evidence supports the allegation that Zendesk's system performs the claimed step of "determining the components of the requested service"? The patent specification describes this step as potentially involving complex "service research" to identify prerequisite fixes ('228 Patent, col. 2:11-23). It is an open question whether the accused service performs such a detailed analysis or merely serves a pre-packaged, newer version of an application, which may be a technically distinct operation.

V. Key Claim Terms for Construction

  • The Term: "remote location interface"

  • Context and Importance: The definition of this term is critical for determining whether a modern web browser, through which a user accesses the Zendesk service, falls within the claim scope. Practitioners may focus on this term because the patent's embodiments depict specific, non-web-based, menu-driven interfaces.

  • Intrinsic Evidence for Interpretation:

    • Evidence for a Broader Interpretation: The claim language itself is general, not explicitly limiting the "interface" to a specific technology. The term appears in the context of a "customer at a remote location," which could support a broad reading covering any user interface accessible remotely ('228 Patent, col. 25:40-42).
    • Evidence for a Narrower Interpretation: The specification repeatedly illustrates the interface with specific screen mockups like the "Enter screen" in Figure 4, which shows a text-based menu of options. This detailed depiction of specific embodiments could be used to argue for a narrower construction limited to such structured, terminal-like interfaces ('228 Patent, Fig. 4; col. 6:40-54).
  • The Term: "determining the components of the requested service"

  • Context and Importance: This term is the functional core of the invention. Its construction will determine whether simply identifying that a user clicked "Update" and providing the latest software version constitutes infringement, or if a more complex analysis is required by the claims.

  • Intrinsic Evidence for Interpretation:

    • Evidence for a Broader Interpretation: The claim language itself does not specify the complexity of the "determining" step. It could be argued that identifying the requested action (e.g., "update") and the target software is sufficient to meet this limitation ('228 Patent, col. 26:45-47).
    • Evidence for a Narrower Interpretation: The patent's background and summary heavily emphasize the concept of "service research," which is the "process of determining all of the changes necessary from the original program version to result in the fully updated program," including identifying "requisite fixes" ('228 Patent, col. 2:11-16). This context suggests that "determining the components" is a substantive analytical step, not merely a simple file retrieval.

VI. Other Allegations

  • Indirect Infringement: The complaint alleges induced infringement, asserting that Zendesk intentionally instructs its customers to infringe by providing training videos, demonstrations, brochures, and user guides through its website, support pages, and app stores (Compl. ¶17). It also alleges contributory infringement, stating the Zendesk Support Service is a material part of the invention, not a staple article of commerce, and is especially adapted for use in infringing the patent (Compl. ¶¶ 18-19).
  • Willful Infringement: Willfulness is alleged based on post-suit knowledge. The complaint asserts that Zendesk "will have been on notice of the '228 Patent since, at the latest, the service of this complaint upon Zendesk," and that continued infringement would therefore be willful (Compl. ¶20).

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

  1. Definitional Scope: A core issue will be whether the claim terminology of the '228 Patent, rooted in the 1994 context of centralized maintenance for enterprise software, can be construed to encompass a modern, web-based SaaS platform. The case may turn on whether a "remote location interface" can be interpreted as a web browser and whether Zendesk's cloud backend functions as the claimed "service facility."

  2. Functional Equivalence: A key evidentiary question will be one of technical operation. Does Zendesk's system for updating apps perform the specific, multi-step process of "determining the components of the requested service" as detailed in the patent specification—including "service research" for dependencies—or does it perform a more direct function of serving a pre-packaged new version, raising the question of a fundamental mismatch in the accused and claimed methods?