DCT
8:19-cv-01699
Modern Font Applications LLC v. El Pollo LoCo Inc
I. Executive Summary and Procedural Information
- Parties & Counsel:
- Plaintiff: Modern Font Applications LLC (Utah)
- Defendant: El Pollo Loco, Inc. (Delaware)
- Plaintiff’s Counsel: One LLP; Kunzler Bean & Adamson
- Case Identification: 8:19-cv-01699, C.D. Cal., 09/05/2019
- Venue Allegations: Venue is alleged to be proper based on Defendant operating approximately 143 restaurants and a corporate headquarters within the judicial district.
- Core Dispute: Plaintiff alleges that Defendant’s mobile applications for iOS and Android infringe a patent related to methods for delivering and rendering non-standard fonts on a client device.
- Technical Context: The technology concerns the display of custom fonts in software applications, a common requirement for maintaining brand identity and user interface consistency across different platforms.
- Key Procedural History: The complaint notes that the priority application for the patent-in-suit was filed in 2001, preceding the widespread adoption of modern smartphone operating systems. The complaint also alleges that licensed articles have been marked in accordance with 35 U.S.C. §287 since at least June 2018, potentially setting a date for the start of damages calculations.
Case Timeline
| Date | Event |
|---|---|
| 2001-07-16 | '421 Patent Priority Date |
| 2018-02-06 | U.S. Patent No. 9,886,421 Issued |
| 2018-06-01 | Alleged start of patent marking by licensee (approximate) |
| 2019-07-17 | Accused El Pollo Loco Android App v2.2.1 Released |
| 2019-07-18 | Accused El Pollo Loco iOS App v2.2.1 Released |
| 2019-09-05 | Complaint Filed |
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 9,886,421 - Allowing Operating System Access to Non-Standard Fonts in a Network Document
- Patent Identification: U.S. Patent No. 9,886,421, Allowing Operating System Access to Non-Standard Fonts in a Network Document, issued February 6, 2018.
The Invention Explained
- Problem Addressed: The patent addresses the problem of ensuring that electronic documents (like web pages or applications) display text with the author's intended "non-standard" fonts, even when those fonts are not pre-installed on the reader's computer (Compl. ¶25; '421 Patent, col. 1:58-65). Prior methods, such as representing text as images, were inefficient, increased download times, and prevented user interactions like copying, pasting, or stylizing text (Compl. ¶¶26-27; '421 Patent, col. 2:4-20). Another prior art approach using proprietary font players was also inefficient and limited interoperability between applications (Compl. ¶¶28-29; '421 Patent, col. 2:21-53).
- The Patented Solution: The invention describes a system where a "font package" containing the necessary formatting information for the non-standard font is delivered to the user's computer along with the document or application ('421 Patent, col. 3:10-20). An "exposure module" (installation software) is also provided, which automatically and temporarily "exposes" or permanently installs the font package, making the non-standard font available to the client's operating system for native rendering ('421 Patent, Abstract; col. 3:21-28). This allows the operating system to treat the new font like any other standard font, enabling full functionality like copying, pasting, and printing ('421 Patent, col. 3:30-39).
- Technical Importance: The described technology sought to solve a fundamental issue in digital document and web design: enabling creative and branding consistency through custom typography without sacrificing performance or core system functionality (Compl. ¶30; '421 Patent, col. 2:54-59).
Key Claims at a Glance
- The complaint asserts independent claims 1 and 11 (Compl. ¶41).
- Independent Claim 1 (Non-transitory computer-readable medium):
- A non-transitory computer-readable medium accessible by a hand-held device.
- An "electronic file package" with display characters and instructions for identifying them.
- A "font package" with external font files, separate from the executable instructions.
- An "exposure module" for installing the external font files in a "temporary fonts directory."
- The external font files are received from a computer in response to a request from the hand-held device.
- When displayed, the characters are rendered by a program module of the operating system using the external font files.
- A "system font table" on the device is updated to reflect the availability of the external font files.
- Independent Claim 11 (Hand-held device):
- A hand-held device with a display, processor, and memory.
- Instructions to download an "electronic file" from a second computer, which includes instructions identifying display characters and a font, and which references a "font package."
- Instructions to install an "exposure module" to automatically install or expose the font package.
- Instructions to cause the exposure module to install the font package into a "temporary fonts directory."
- Instructions to cause a "system font table" to be updated to reflect the font's availability.
- The complaint also asserts, upon information and belief, claim 6 and unspecified dependent claims (Compl. ¶¶17, 41).
III. The Accused Instrumentality
Product Identification
- Defendant’s "El Pollo Loco application for iOS devices" (version 2.2.1 and later) and "El Pollo Loco application for Android devices" (version 2.2.1 and later), collectively the "Accused Product(s)" (Compl. ¶41).
Functionality and Market Context
- The complaint alleges the Accused Products are mobile applications distributed through the Apple iTunes and Google Play stores (Compl. ¶47). Their relevant technical function involves bundling custom font files (e.g., ".ttf" files) within the application package (".ipa" for iOS, ".apk" for Android) (Compl. ¶¶44, 46). When the application is installed, these custom fonts are made available to the device's operating system, allowing the application to render text using its own branded typography rather than relying solely on the device's default system fonts (Compl. ¶¶48-49). No probative visual evidence provided in complaint.
IV. Analysis of Infringement Allegations
'421 Patent Infringement Allegations (Claim 1)
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation |
|---|---|---|---|
| A non-transitory computer-readable medium...including: an electronic file package including a plurality of display characters and computer executable instructions...for identifying one or more external fonts used to render at least one of the plurality of display characters; | The Accused Products are provided as a non-transitory computer-readable medium (e.g., via a storage device) containing an electronic file package (the ".ipa" or ".apk" file) which includes characters for display and executable instructions for identifying and using external fonts (e.g., in ".xml", ".arsc", ".nib", or ".strings" files). | ¶¶42, 43 | col. 16:1-9 |
| a font package comprising one or more external font files that include formatting information...the font package separate from the computer executable instructions for identifying the plurality of display characters for display; | The Accused Products provide a font package with external font files (e.g., a ".ttf" file) in a specific directory ("/assets/fonts/" for Android, "/Payload/" subdirectory for iOS), which is separate from the application's main executable instructions. | ¶¶44, 45 | col. 16:10-17 |
| an exposure module for installation of the one or more external font files in a temporary fonts directory on the hand-held device... | The application package itself (the ".apk" or ".ipa" file) is alleged to be the "exposure module." The "temporary fonts directory" is alleged to be the "/assets/" directory (for Android) or a subdirectory of "/Payload/" (for iOS), which is deleted when the application is removed or updated. | ¶46 | col. 16:18-21 |
| the one or more external font files being received from the computer responsive to the computer receiving a request for the font package from the hand-held device... | The external font files are received as part of the application download from an app store server (e.g., Google Play, iTunes) in response to a user's request to install the application on their device. | ¶47 | col. 16:21-25 |
| whereby when the plurality of display characters are displayed, the plurality of display characters are displayed by a program module of the operating system using the one or more external font files... | When the application displays characters, they are rendered by a program module of the operating system using the external font files contained within the ".apk" or ".ipa" package. | ¶48 | col. 16:28-32 |
| wherein in response to the one or more external font files being installed, a system font table of the hand-held device is updated to reflect an availability of the external font files. | The "system font table" is allegedly updated when the application is installed. For iOS, this is done by providing a font listing in the "Info.plist" file using the "UIAppFonts" key. For Android, inclusion of the font file in the "/assets/" directory is alleged to cause the operating system to load the fonts. | ¶49 | col. 16:33-36 |
- Identified Points of Contention:
- Scope Question: A primary issue may be whether the accused application package (e.g., the ".apk" or ".ipa" file) can be properly construed as an "exposure module" as claimed. The patent describes the module as software that is installed on the computer, such as an ActiveX control or a browser plug-in, which then installs the fonts ('421 Patent, col. 12:35-42, col. 16:34-42). The defense may argue that an application package is not an "exposure module" that installs fonts, but rather an application that simply contains fonts as resources for its own use, a standard practice in mobile development.
- Technical Question: It is a question of fact whether an application's resource manifest (like the "Info.plist" file in iOS) or asset directory structure (in Android) constitutes an update to a "system font table" as required by the claims. The defense could argue that these are application-specific declarations, not modifications to a core, OS-level "system font table" as depicted in the patent's figures (e.g., '421 Patent, Fig. 6, element 506). The court will need to determine if the accused functionality is technically equivalent to the claimed "update."
V. Key Claim Terms for Construction
The Term: "exposure module"
Context and Importance: This term is central to the infringement theory. The complaint alleges the entire application package (".apk" or ".ipa") is the "exposure module" (Compl. ¶46). The case may depend on whether this interpretation is supportable. Practitioners may focus on this term because its construction could determine whether standard mobile app architecture falls within the patent's scope.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent abstract states an "exposure module is also downloaded...which in turn either permanently installs or temporarily exposes the operating system...to the computer readable font formatting information." One could argue that any software component that makes fonts available to the OS performs this function.
- Evidence for a Narrower Interpretation: The specification repeatedly provides specific examples of the module, such as "an ACTIVEX® control" or a "plug-in for NETSCAPE," which are distinct software components that interact with a browser or OS ('421 Patent, col. 12:41-42; col. 12:57-65). Figure 6 shows the "EXPOSURE MODULE 501" as a distinct block separate from the application, mediating between the browser and the operating system.
The Term: "system font table"
Context and Importance: The claims require this table to be "updated." The infringement allegation rests on interpreting an application's "Info.plist" or "assets" directory as this "table" (Compl. ¶49). The viability of the infringement claim hinges on whether this interpretation holds.
Intrinsic Evidence for Interpretation:
- Evidence for a Broader Interpretation: The patent does not explicitly define "system font table." Plaintiff may argue that any mechanism the OS uses to recognize available fonts, including application-specific manifests that the OS reads upon installation, serves the function of a "system font table."
- Evidence for a Narrower Interpretation: The patent specification includes Figure 6, which depicts "SYSTEM FONT TABLE 506" as a distinct component of the "OPERATING SYSTEM 505," alongside "PERMANENT SYSTEM FONTS 508" and "SYSTEM REGISTRY 509." This suggests a centralized, OS-level data structure, rather than a per-application resource file. The patent also describes updating the table to "reflect the new temporary font files" ('421 Patent, col. 13:58-59), which may imply a more active modification of an OS resource.
VI. Other Allegations
- Indirect Infringement: The complaint alleges active inducement, stating Defendant's marketing materials and online application store listings "encourage customers to infringe the '421 patent" by making, using, or selling the accused products (Compl. ¶52). It also alleges contributory infringement, stating the products are especially adapted for practicing the invention and are not staple articles of commerce suitable for substantial non-infringing use (Compl. ¶53).
- Willful Infringement: The complaint does not allege pre-suit knowledge of the patent. It alleges that patent marking has been in place since June 2018, providing constructive notice to the public (Compl. ¶39). Willfulness is further supported by the allegation that infringement is ongoing post-filing, and the prayer for relief requests enhanced damages (Compl. ¶¶54-55; Prayer ¶3).
VII. Analyst’s Conclusion: Key Questions for the Case
This case appears to center on whether standard, modern mobile application development practices for including custom fonts fall within the scope of a patent filed in 2001, before such practices were established. The key questions for the court will likely be:
- A core issue will be one of definitional scope: can the term "exposure module," described in the patent as a component like an ActiveX control or plugin, be construed to read on an entire, self-contained mobile application package like an ".apk" or ".ipa" file?
- A related question is one of technical interpretation: does an application declaring its own font resources in a standard manifest file (like "Info.plist") or including them in an "assets" directory constitute "updating a system font table" as that term is used and depicted in the patent?
- Ultimately, the dispute may turn on technological evolution: whether the accused functionality, while achieving a similar outcome (displaying custom fonts), operates via a fundamentally different and non-equivalent technical mechanism than the one patented two decades ago in the context of desktop web browsers.