Modern Font Applications v. Domino's Pizza LLC

I. Executive Summary and Procedural Information

• Parties & Counsel:
  • Plaintiff: Modern Font Applications LLC (Utah)
  • Defendant: Domino's Pizza LLC (Michigan)
  • Plaintiff’s Counsel: Kunzler Bean & Adamson, PC
• Case Identification: 2:19-cv-00614, D. Utah, 09/03/2019
• Venue Allegations: Plaintiff alleges venue is proper in the District of Utah because Defendant operates regular and established places of business in the district, such as corporate-owned Domino's Pizza stores.
• Core Dispute: Plaintiff alleges that Defendant’s Domino's Pizza USA application for iOS devices infringes a patent related to methods for delivering and rendering non-standard fonts on a computer.
• Technical Context: The technology concerns the display of custom fonts within software applications, particularly in networked environments where the end-user's device may not have the custom fonts pre-installed.
• Key Procedural History: The patent-in-suit claims priority to an application filed in 2001, which the complaint notes predates the modern mobile application ecosystem, including the first iPhone and mobile application stores.

Case Timeline

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

• 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 describes a problem where electronic documents, such as web pages, use "non-standard" fonts that are not installed on a reader's computer (’421 Patent, col. 1:54-65). When this occurs, the reader’s operating system either fails to display the text or substitutes a different, standard font, altering the author's intended visual presentation (Compl. ¶25). Prior solutions, such as rendering text as images, were inefficient, increasing download times and preventing resizing or editing, while solutions using proprietary font players were often sluggish and did not allow the fonts to be used by other applications (’421 Patent, col. 2:5-20, 2:45-53).
• The Patented Solution: The invention provides a system where a "font package" containing the necessary non-standard font information is delivered to the reader's computer along with the network document (’421 Patent, col. 3:10-21). An "exposure module," such as an ActiveX control, is also provided, which automatically installs or temporarily "exposes" this font information to the client's operating system (’421 Patent, col. 11:33-44; Fig. 5). This enables the operating system itself to render the non-standard fonts correctly, not just within the original document but potentially for other functions like copying and pasting into different applications (’421 Patent, col. 3:30-39).
• Technical Importance: This approach allows content creators to use unique fonts in network documents with the assurance that they will be rendered as intended on end-user devices, thereby enhancing inter-application functionality and preserving creative design (’421 Patent, col. 14:23-39).

Key Claims at a Glance

• The complaint asserts independent claims 1 and 11 (Compl. ¶41).
• Independent Claim 1 (non-transitory computer-readable medium):
  • An electronic file package with display characters and instructions to identify characters and external fonts.
  • A font package, separate from the electronic file package, with one or more external font files.
  • An exposure module for installing the external font files in a temporary fonts directory.
  • The installation is responsive to a request for the font package from a hand-held device.
  • In response to installation, a system font table of the hand-held device is updated to reflect the availability of the external fonts.
• Independent Claim 11 (hand-held device):
  • A display, processing unit, and memory with instructions.
  • Instructions cause the device to enable communication with a network and download an electronic file.
  • The file includes instructions identifying display characters and a font, and references a font package.
  • Instructions cause the device to install an exposure module for automatically installing or exposing the font package.
  • The exposure module installs the font package into a temporary fonts directory.
  • A system font table is updated to reflect the font's availability.
• The complaint also asserts infringement of dependent claims, including claim 6 (Compl. ¶41).

III. The Accused Instrumentality

• Product Identification: Defendant’s "Domino's Pizza USA application for iOS devices, including at least version number 6.6.0" (the "Accused Product") (Compl. ¶41).
• Functionality and Market Context:
  • The Accused Product is a mobile application distributed through an application store server, such as the Apple iTunes store (Compl. ¶47). It is delivered to a user's iOS device as a single ".ipa" file package (Compl. ¶46).
  • The complaint alleges this package contains an executable file, resource files like ".nib" and ".strings" files, and separate external font files (".ttf" or ".otf") located in a subdirectory (Compl. ¶¶43-45).
  • To make these external fonts available for use, the application includes a font listing in its "Info.plist" file using the "UIAppFonts" key. The complaint alleges this causes the iOS operating system to load the specified fonts and make them available for use by the application (Compl. ¶49). The directory containing the fonts is allegedly temporary because it is deleted when the application is updated or removed (Compl. ¶46).
  • No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

U.S. Patent No. 9,886,421 Infringement Allegations

• Identified Points of Contention:
  • Scope Questions: A central question is whether the standard iOS mechanism for bundling and registering custom fonts within an application's sandboxed environment constitutes the specific architecture claimed in the patent. Does the use of the "UIAppFonts" key in an "Info.plist" file, a standard practice for iOS developers, meet the definition of updating a "system font table" as described in the patent, which depicts a distinct "system font table 506" module within the operating system (Fig. 6)?
  • Technical Questions: The complaint alleges the entire ".ipa" file acts as the "exposure module" (Compl. ¶46). This raises the question of whether a self-contained application package and its standard OS-managed installation process can be equated with the patent’s description of a distinct software module (like an ActiveX control) that is separately requested and installed to manage fonts (col. 11:33-44; Fig. 5, step 412). Further, a question exists as to whether a font directory inside an application's own package, which is deleted only when the app is removed, qualifies as a "temporary fonts directory" in the manner contemplated by the patent, which discusses clearing the directory when a browser is closed (col. 14:10-15).

V. Key Claim Terms for Construction

• The Term: "system font table"

• Context and Importance: This term is critical because the infringement allegation hinges on equating the iOS "UIAppFonts" key functionality with an "update" to a "system font table." The definition will determine whether a standard, application-level font registration mechanism falls within the scope of the claims. Practitioners may focus on this term because the patent's viability against modern mobile apps depends on a broad interpretation.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent states that one benefit is the ability to copy and paste characters into "any other application being control[led] by [the] operating system," which may suggest the font table update has system-wide or inter-application effects (col. 14:30-35).
  • Evidence for a Narrower Interpretation: The patent’s Figure 6 depicts "System Font Table 506" as a distinct component within the "Operating System 505," separate from other components like the "System Registry 509." This may support an argument that the term refers to a specific, centralized OS data structure, not just a state of general availability.

• The Term: "exposure module"

• Context and Importance: The complaint identifies the ".ipa" application file itself as the "exposure module" (Compl. ¶46). The case will depend on whether this interpretation is viable, as the patent appears to describe this module as a separate piece of software that facilitates the installation.

• Intrinsic Evidence for Interpretation:

  • Evidence for a Broader Interpretation: The patent abstract describes an "exposure module" that is "downloaded to the browsing computer" and "either permanently installs or temporarily exposes the operating system... to the computer readable font formatting information." This functional language could arguably be mapped onto the overall effect of an app installation.
  • Evidence for a Narrower Interpretation: The detailed description and figures consistently treat the module as a distinct entity. For example, it is identified as an "installation module 501" that can be an "ACTIVEX® control" (col. 11:40-42), which is requested (Fig. 5, step 412) and installed (step 416) separately from the initial processing of the network document. This suggests it is not the application package itself but a component technology for enabling font access.

VI. Other Allegations

• Indirect Infringement: The complaint alleges inducement, stating that Defendant’s marketing materials and website encourage customers to make and use the infringing application (Compl. ¶52). It also alleges contributory infringement by asserting the Accused Product is especially made for practicing the invention and is not a staple article of commerce with substantial non-infringing uses (Compl. ¶53).
• Willful Infringement: The complaint does not contain an explicit count for willful infringement. However, the prayer for relief requests enhanced damages pursuant to 35 U.S.C. § 284 and a decree that the case is "exceptional" under 35 U.S.C. § 285, which are remedies associated with findings of willfulness or other egregious conduct (Prayer for Relief ¶¶3, 5).

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

The dispute appears to center on whether the specific, multi-component architecture described in the 2001-era patent can be read onto the integrated, sandboxed environment of a modern mobile application.

• A core issue will be one of definitional scope: Can the term "system font table," as described in the patent, be construed to cover the application-specific font registration mechanism ("UIAppFonts" key) used in Apple's iOS, or does the patent require an update to a more fundamental, system-wide OS component?
• A related question is one of architectural mapping: Does the standard installation of a self-contained mobile application (".ipa" file) satisfy the patent's requirement for a distinct "exposure module" that installs a "separate" font package, or is there a fundamental mismatch between the claimed process and the accused functionality?
• Finally, an evidentiary question will be whether the fonts are made available in a way that provides the inter-application functionality described as a key benefit of the invention, or if their use is confined to the accused application, potentially undermining the allegation that a true "system font table" has been updated.