DCT

2:16-cv-00291

BROADWAY National Bank v. Plano Encryption Tech LLC

Log In

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 1:15-cv-01056, W.D. Tex., 11/20/2015
  • Venue Allegations: Plaintiff alleges venue is proper in the Western District of Texas as a substantial part of the events giving rise to the claim occurred there and Defendant is subject to personal jurisdiction in the district.
  • Core Dispute: Plaintiff seeks a declaratory judgment that its mobile applications and online banking features do not infringe three patents owned by Defendant related to secure key distribution and data access control.
  • Technical Context: The technology at issue involves methods for authenticating software integrity and securely distributing cryptographic keys in client-server systems, which are foundational technologies for secure online banking and e-commerce.
  • Key Procedural History: This declaratory judgment action was filed in response to a July 10, 2015 letter from Defendant alleging that Plaintiff's products infringe the patents-in-suit. The complaint notes that Defendant has filed infringement lawsuits against several other banks asserting the same patents, creating what Plaintiff alleges is a reasonable apprehension of litigation.

Case Timeline

Date Event
1997-12-12 ’550 Patent Priority Date
1997-12-18 ’399 Patent Priority Date
1999-09-30 ’858 Patent Priority Date
1999-10-26 ’550 Patent Issued
1999-11-23 ’399 Patent Issued
2003-07-01 ’858 Patent Issued
2015-07-10 Defendant sends infringement allegation letter to Plaintiff
2015-11-20 Complaint for Declaratory Judgment filed

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

U.S. Patent No. 5,991,399 - "Method for Securely Distributing a Conditional Use Private Key to a Trusted Entity on a Remote System"

The Invention Explained

  • Problem Addressed: The patent describes the personal computer as a "fundamentally insecure computing platform" where malicious users can observe and modify executing code, such as a software DVD player, to extract pre-loaded decryption keys and make unauthorized copies of digital content (ʼ399 Patent, col. 1:13-24, col. 2:50-59).
  • The Patented Solution: To solve this, the invention proposes a system where a decryption key is not pre-loaded. Instead, a server dynamically generates a private key for a specific piece of content and "wraps" it into an executable, "tamper resistant key module" (ʼ399 Patent, Abstract). This module is sent to a "trusted player" application on a client's machine. The module first verifies the integrity of the trusted player (e.g., by checking its signed manifest) before it will decrypt and provide the necessary key to access the content, thereby providing conditional access (ʼ399 Patent, Fig. 2; col. 6:18-49).
  • Technical Importance: This method provided a framework for on-demand, dynamic access control for digital content, shifting security away from static, embedded keys that represented a single point of failure for a content protection system (ʼ399 Patent, col. 3:59-65).

Key Claims at a Glance

  • The complaint notes that Defendant asserted independent claims 1 and 29, and dependent claims 9 and 37 (Compl. ¶13).
  • Independent Claim 1 recites a method of securely distributing data, with key elements including:
    • generating an asymmetric key pair having a public key and a private key;
    • encrypting predetermined data with the generated public key; and
    • building an executable tamper resistant key module identified for a selected program, the module including the generated private key and the encrypted predetermined data.

U.S. Patent No. 5,974,550 - "Method for Strongly Authenticating Another Process in a Different Address Space"

The Invention Explained

  • Problem Addressed: The patent notes that conventional challenge-response protocols can verify that two parties share a secret, but cannot ensure that one of the parties has not been "hacked" or tampered with, which is a particular problem when authenticating a software process running in a different memory address space (ʼ550 Patent, col. 1:10-33).
  • The Patented Solution: The invention describes a method where a local process creates a "tamper resistant module" containing a temporary secret. This module is sent with a challenge to a remote process. The remote process executes the module, which first verifies the remote process's own integrity. Only upon successful verification does the module reveal the secret, which the remote process then uses to correctly encode the challenge and send back a response, thereby proving its integrity to the local process (ʼ550 Patent, Abstract; col. 2:31-54).
  • Technical Importance: The described protocol provided a mechanism to establish trust in the operational integrity of a remote software process itself, rather than just authenticating a communication channel, without requiring persistent, pre-shared secrets (ʼ550 Patent, col. 4:31-38).

Key Claims at a Glance

  • The complaint notes that Defendant asserted independent claim 14 and dependent claims 15-17 (Compl. ¶13).
  • Independent Claim 14 recites an apparatus (a first process) comprising a processing unit and a storage medium with instructions that, when executed:
    • receive a tamper resistant module from a second process;
    • initiate execution of the tamper resistant module;
    • recover a secret embedded in the module when the integrity of the first process is verified during the module's execution;
    • receive a challenge from the second process;
    • encode the challenge using the secret to produce a response; and
    • send the response to the second process.

U.S. Patent No. 6,587,858 - "Systems and Methods for the Control of Dynamic Data and Request Criteria in a Data Repository"

  • Technology Synopsis: The patent addresses the problem of controlling access to a data repository when the format of data requests is variable and not known in advance ('858 Patent, col. 1:21-31). The solution uses rule sets called "notational fragments" and "query template constructs" that allow the repository to interpret dynamic requests, substitute variable content, and apply access privileges to assemble a result on-the-fly ('858 Patent, Abstract).
  • Asserted Claims: At least Claim 6 (Compl. ¶13).
  • Accused Features: Plaintiff's "online banking features" (Compl. ¶13).

III. The Accused Instrumentality

Product Identification

Plaintiff’s "mobile apps" and "online banking features" (Compl. ¶13).

Functionality and Market Context

The complaint states that Plaintiff is in the business of banking and has 39 branches in the Austin/San Antonio area (Compl. ¶7). The accused instrumentalities are alleged by Defendant to infringe patents related to secure communication, authentication, and data access (Compl. ¶13). The complaint does not provide sufficient detail for analysis of the specific technical operation or architecture of the accused mobile apps or online banking features. No probative visual evidence provided in complaint.

IV. Analysis of Infringement Allegations

The complaint references an infringement allegation letter and its exhibits, which purportedly detail the basis for Defendant's claims (Compl. ¶13, Ex. D). As these exhibits were not included with the complaint, a direct summary of Defendant's infringement theory is not possible. However, the nature of the asserted claims and the accused products raises key potential points of contention.

’399 Patent Infringement Allegations

The complaint does not provide a claim chart for analysis.

  • Identified Points of Contention:
    • Scope Questions: A central question may be whether the security architectures used in modern mobile banking applications fall within the scope of a "tamper resistant key module." The patent describes this module as a specific type of executable built by a "tamper resistant compiler" to be obfuscated and self-validating ('399 Patent, col. 5:48-6:16). The court may need to determine if standard app code-signing, sandboxing, and runtime OS protections meet this specific definition.
    • Technical Questions: Claim 1 requires "building" a module that includes a newly generated private key for a given transaction. A key factual question is whether Plaintiff's systems dynamically generate new asymmetric key pairs and build new software components on the server for user sessions, or if they rely on more conventional, persistent security credentials like user passwords, device tokens, or pre-established SSL/TLS certificates.

’550 Patent Infringement Allegations

The complaint does not provide a claim chart for analysis.

  • Identified Points of Contention:
    • Scope Questions: The infringement analysis will likely focus on whether any security component in Plaintiff's systems performs the function of the claimed "tamper resistant module." Specifically, does any part of Plaintiff's software execute an integrity check on the client application itself as a precondition to revealing a secret, as described in the patent ('550 Patent, col. 3:3-10), or are integrity checks performed by external systems (e.g., the mobile OS or an app store)?
    • Technical Questions: The sequence of steps in claim 14 is specific: receive module, execute module, verify integrity, recover secret, encode challenge. An evidentiary question is whether the authentication protocols used by Plaintiff's banking apps follow this precise sequence or a different one, such as a standard TLS handshake, which involves a different exchange of certificates, keys, and authenticators.

V. Key Claim Terms for Construction

  • The Term: "tamper resistant key module" / "tamper resistant module" (appearing in claims of the ’399 and ’550 patents)

    • Context and Importance: This term is foundational to the independent claims of both lead patents. Whether Plaintiff's modern mobile app security measures can be characterized as this "module" will likely be a dispositive issue. Practitioners may focus on this term because its construction could resolve the infringement question for both patents.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The specification provides a high-level functional description, stating that "Tamper resistant software is software which is resistant to observation and modification" and can operate "as intended even in the presence of a malicious attack" ('550 Patent, col. 2:50-54).
      • Evidence for a Narrower Interpretation: The patents provide a more detailed and limiting description, explaining that such software is generated by a special "tamper resistant compiler," is "obfuscated," and is "self-decrypting" in a way that it "will only execute properly if no part of the image has been altered" ('550 Patent, col. 2:55-63). The '399 Patent further links the concept to specific "Integrity Verification Kernel (IVK)" software ('399 Patent, col. 6:6-16).

  • The Term: "building an executable tamper resistant key module" ('399 Patent, Claim 1)

    • Context and Importance: This term appears in the core method step of claim 1. The dispute may turn on whether "building" requires a dynamic, on-demand compilation or code generation process, or if it can be read more broadly to mean configuring a secure session.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The term "building" is not explicitly defined and could arguably encompass any process of assembling or constructing a functional component, including one from pre-existing parts.
      • Evidence for a Narrower Interpretation: Figure 5 of the '399 Patent depicts a specific process flow involving a "Key Compiler" and a "Tamper Resistant Compiler" that take source code and keys as inputs to generate "Key Module Object Code" and the final module ('399 Patent, Fig. 5; col. 10:5-22). This detailed embodiment suggests "building" is a specific act of compilation and generation.

VI. Other Allegations

  • Indirect Infringement: The complaint seeks a declaration that Plaintiff does not infringe "directly or indirectly" (Compl. ¶¶ 18, 22, 26), but provides no specific facts regarding any allegations of induced or contributory infringement that may have been made by Defendant.
  • Willful Infringement: The complaint does not address willfulness. However, it does confirm that Defendant provided Plaintiff with notice of the patents-in-suit via the letter dated July 10, 2015 (Compl. ¶13). This fact could be used by Defendant in a potential counterclaim to support allegations of willful infringement for any infringing activity post-dating the letter.

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

  • A core issue will be one of definitional scope: can the term "tamper resistant module," which the patents describe in the context of specially compiled and obfuscated software from the 1990s, be construed broadly enough to cover the standard security architectures, code-signing practices, and operating system protections used in modern mobile banking applications?
  • A key evidentiary question will be one of functional operation: do Plaintiff’s banking platforms perform the specific, dynamic, and sequential steps recited in the asserted claims—such as a server "building" a new software module with a newly generated key for a transaction ('399 patent) or a client-side module performing an internal integrity check before revealing a secret ('550 patent)—or is there a fundamental mismatch in technical architecture?
  • A threshold procedural question may arise regarding the justiciable controversy for the '858 patent. The court may need to consider whether Defendant’s pre-suit allegations concerning the "online banking features" were sufficiently specific to create an actual controversy, given the patent's distinct focus on dynamic data repository management.