BlackBerry Corp v. MAZ Encryption Technologies LLC

1. Case Identification

• Case #: IPR2019-00624
• Patent #: 7,096,358
• Filed: January 25, 2019
• Petitioner(s): BlackBerry Corporation
• Patent Owner(s): MAZ Encryption Technologies LLC
• Challenged Claims: 1-15

2. Patent Overview

• Title: Encrypting File System
• Brief Description: The ’358 patent discloses a system for encrypting and decrypting documents that intercepts user commands, such as opening or closing a file, to perform cryptographic operations transparently, thereby minimizing disruption to the user's workflow. The system uses a two-table lookup process to retrieve the correct decryption key for a given document.

3. Grounds for Unpatentability

Ground 1: Claims 1, 3-15 are obvious over Johnson in view of McDonnal

• Prior Art Relied Upon: Johnson (Patent 5,694,472) and McDonnal (Patent 5,699,428).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued Johnson taught the core elements of the independent claims, including an encryption system with a processing device that manages encrypted files. Johnson disclosed a "first table" (Table 370) that associates file names with "operational key file names" and a "second table" that maps these key names to the actual "operational key codes" (decryption keys). Petitioner asserted that Johnson’s system uses this two-table structure to retrieve the correct key and decrypt files. However, Petitioner contended that Johnson’s method for initiating decryption (e.g., inserting a smart card) may not meet the limitation of detecting an "open command" from a user application. McDonnal was introduced to supply this teaching, as it explicitly disclosed a system for automatic decryption and re-encryption in direct response to intercepted file-OPEN and file-CLOSE requests issued by an authorized user.
  • Motivation to Combine: A POSITA would combine McDonnal's interception of standard file commands with Johnson's secure file management and key-retrieval system to provide a more seamless and user-friendly encryption process. Both references are in the analogous art of encrypted file management.
  • Expectation of Success: A POSITA would have a high expectation of success because both references were directed to file management systems for encrypted files, and incorporating well-known open and close command interception into such a system was a predictable design choice.

Ground 2: Claims 1, 3-15 are obvious over Johnson in view of CFS Source Code

• Prior Art Relied Upon: Johnson (Patent 5,694,472) and CFS Source Code (a 1996 printed publication by Dr. Matthew Blaze).
• Core Argument for this Ground:
  • Prior Art Mapping: As an alternative to Ground 1, this ground again used Johnson as the primary reference for its two-table key management architecture. To the extent Johnson did not teach detecting a user-initiated "open command," Petitioner argued that CFS Source Code did. The CFS Source Code disclosed a Cryptographic File System for Unix that integrates with the Network File System (NFS). It taught that a standard read command functions as an "open command," which triggers a registered function (nfsproc_read_2) to check if a file is in a table of encrypted files and, if so, decrypt it.
  • Motivation to Combine: A POSITA would combine the teachings because both address file system security. It would have been obvious to replace Johnson's specific method of initiating decryption (smart card insertion) with the more conventional and broadly applicable file system call interception method taught by CFS Source Code.
  • Expectation of Success: A POSITA would expect success in combining the references, as it amounted to substituting one known method for initiating a file operation (hardware-based) with another (software-based) within the known context of encrypted file systems.

Ground 3: Claims 1, 4, 6-9, and 11-14 are obvious over CFS Source Code in view of CFS I

• Prior Art Relied Upon: CFS Source Code (a 1996 printed publication by Dr. Blaze) and CFS I (a 1993 article by Dr. Blaze).

• Core Argument for this Ground:

  • Prior Art Mapping: Petitioner argued that CFS Source Code, as a primary reference, taught most claimed features. It disclosed a "crypto server" (the cfsd daemon), a "first table" (a file hash table), and a method of retrieving a key name (an instance pointer) to find the associated key value from a "second table" (an instance table). Petitioner asserted that CFS I, a publication describing the system implemented in the CFS Source Code, could be used to supplement its teachings. For example, CFS I explicitly disclosed that keys could be stored on and managed by removable "smart cards" (relevant to claims 5, 10, and 15) and clarified that unique "file handles" are used for each file, satisfying the "respective names" limitation.
  • Motivation to Combine: The motivation to combine was presented as exceptionally strong, as CFS I is an academic paper that describes the architecture and advantages of the system for which CFS Source Code is the prototype implementation. A POSITA analyzing the source code would have been directly motivated to consult the corresponding publication for context and a higher-level explanation.
  • Expectation of Success: Success was practically assured, as the two references are not merely related but are two parts of the same disclosed system, authored by the same person.

• Additional Grounds: Petitioner asserted additional obviousness challenges for dependent claims 2 and 3. These grounds added Chan (Patent 5,713,018) for its teachings on SQL database systems and Rackman (Patent 5,903,646) for its disclosure of using an indicator flag in a database to identify encrypted documents.

4. Relief Requested

• Petitioner requested the institution of an inter partes review and the cancellation of claims 1-15 of the ’358 patent as unpatentable.