McAfee Inc v. Cap Co Ltd

1. Case Identification

• Case #: IPR2015-01877
• Patent #: RE42,196
• Filed: September 4, 2015
• Petitioner(s): McAfee, Inc.
• Patent Owner(s): CAP Co., Ltd.
• Challenged Claims: 4 and 5

2. Patent Overview

• Title: System and method for blocking harmful information online, and computer readable medium therefor
• Brief Description: The ’196 patent describes a system for computer security where a client computer, upon connecting to a web server, automatically downloads, installs, and executes an antivirus module. This module operates in real time to block harmful information by inspecting file input/output (I/O) and/or network packet I/O before a file is executed.

3. Grounds for Unpatentability

Ground 1: Obviousness over Hodges, Butt, and Freund - Claims 4 and 5 are obvious over Hodges, Butt, and Freund.

• Prior Art Relied Upon: Hodges (Patent 6,035,423), Butt (Patent 6,728,964), and Freund (Patent 5,987,611).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner asserted that the combination of Hodges, Butt, and Freund disclosed every element of the challenged claims. The independent claim from which the challenged claims depend, claim 1, was argued to be obvious over Hodges and Butt. Hodges taught a system for automatically delivering and executing updated antivirus software from a central server to a client computer over a network. This met the limitations related to transmitting and automatically running a "harmful information blocking code module." To the extent Hodges did not explicitly teach real-time blocking by intercepting file operations, Butt disclosed this capability. Butt taught a real-time monitoring method that used a "hook" to intercept an operating system’s file I/O routines (e.g., "open file") before file execution. This hook would trigger a virus scan and, if a virus was found, would either treat the file or abort its execution, thereby blocking harmful information in real time as required by claim 1.
    • Claim 4 adds the limitation of "inspecting network packet input/output (I/O) on the client system." Petitioner argued Freund explicitly taught this. Freund disclosed a client-based filter application with a monitor module that intercepted and interpreted all TCP/IP communications to monitor for suspicious or unwanted activity. Freund’s monitor module used a "Winsock Hook" to connect into the communication driver, which is analogous to the method described in the ’196 patent for inspecting network packet I/O.
    • Claim 5 adds the limitation that the code module "checks whether current processes running on the client system are harmful or not." Petitioner argued Freund also taught this element. Freund disclosed intercepting process loading and unloading using a "Process Hook" to track all currently executing applications. It then checked these processes against various characteristics (e.g., checksums, version headers) to identify and block intentionally destructive programs like viruses or Trojan Horses.
  • Motivation to Combine: Petitioner contended a person of ordinary skill in the art (POSITA) would combine these references for several reasons. All three patents addressed the same problem in the same field of endeavor: proactively protecting computers from harmful information before damage could occur. The references provided complementary, well-known "building blocks" for a comprehensive security solution. A POSITA would have been motivated to combine Hodges’s improved, automated delivery system for antivirus software with the more advanced, real-time detection methods taught by Butt (file I/O hooking) and Freund (network packet and running process inspection) to create a more robust and effective security product. This combination represented a predictable and logical step in the industry’s transition from distributing security software on physical media to providing protection via network updates.
  • Expectation of Success: A POSITA would have had a reasonable expectation of success in making this combination. The integration of automatic updates, on-access file scanning, network filtering, and process monitoring involved combining a finite number of known, predictable solutions. Each component was designed to work within standard operating systems (like Windows) and would predictably yield an antivirus system with the combined functionalities.

4. Key Claim Construction Positions

• "harmful information blocking code module": Petitioner proposed this term means "an executable program that blocks harmful information." This construction was argued as necessary because the claims require the module to be "automatically running," a function only an executable program can perform, as opposed to any generic "digital information."
• "by hooking up file I/O routines": Petitioner proposed this means "by executing additional or alternate routine(s) upon a call to the operating system's file I/O routines." This construction was based on the well-understood technical meaning of "hooking" in operating system programming, which is central to applying the teachings of Butt and Freund.
• "block in real time harmful information": Petitioner proposed this means "prevent execution of harmful information in real time." This construction aimed to clarify that the core function of the claimed method is to stop the execution of a malicious file, either by treating it or aborting the execution process entirely, as it is being accessed.

5. Relief Requested

• Petitioner requested the institution of an inter partes review and the cancellation of claims 4 and 5 of Patent RE42,196 as unpatentable.