McAfee, Inc. v. CAP Co., Ltd.

1. Case Identification

• Case #: To Be Assigned
• Patent #: 8,544,078
• Filed: September 2, 2015
• Petitioner(s): McAfee, Inc.
• Patent Owner(s): CAP Co., Ltd.
• Challenged Claims: 7-11, 13-15, 21, and 23-25

2. Patent Overview

• Title: Flexible Network Security System and Method for Permitting Trusted Process
• Brief Description: The ’078 patent discloses a network security system and method using an application-aware firewall. The system maintains a list of user-authorized programs and, when a permitted program requests network access, automatically identifies and stores the corresponding port information to allow inbound network traffic for that specific program, thereby simplifying firewall configuration for users.

3. Grounds for Unpatentability

Ground 1: Obviousness over Yadav and Freund - Claims 7-11, 13-15, 21, and 23-25 are obvious over Yadav in view of Freund.

• Prior Art Relied Upon: Yadav (Patent 7,174,566) and Freund (Patent 5,987,611).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that the combination of Yadav and Freund disclosed all limitations of the challenged claims. Yadav taught an integrated network security system with a "dynamic firewall" that could monitor and block traffic based on application-specific policies. Yadav’s system identified invoked applications (e.g., via hash value, file path), loaded corresponding policies, and managed communication channels based on those policies, including authorizing inbound communications. However, Petitioner contended that Freund provided a more detailed disclosure of a client-based firewall that directly maps to the ’078 patent’s implementation. Freund disclosed maintaining a database (an internal permitted program storage) containing a list of applications permitted to access the network. Freund’s "Client Monitor" would "hook" into the operating system (using WinSock APIs, as in the ’078 patent) to intercept access requests, compare the requesting program against the permitted list, and allow or block traffic accordingly. Freund's system explicitly automated the process, removing the need for users to manually configure ports for specific applications. The combination of Yadav's dynamic firewall architecture with Freund's detailed implementation for managing application lists and permissions renders the claimed invention obvious.
  • Motivation to Combine: Petitioner asserted multiple motivations for a Person of Ordinary Skill in the Art (POSITA) to combine the references. First, Yadav and Freund addressed the same well-known problem: simplifying firewall management for inexpert users by automating permissions for specific applications rather than requiring manual port configuration. Second, both references relied on compatible, if not identical, architectures and implementation details, particularly end-point filtering on Windows-based PCs using WinSock hooking. Freund's detailed, application-centric firewall was a natural and logical implementation choice to supplement the higher-level system described in Yadav. A POSITA seeking to build the dynamic firewall of Yadav would have looked to a detailed reference like Freund, a well-known patent for the popular "Zone Alarm" firewall, for specific implementation guidance.
  • Expectation of Success: A POSITA would have had a high expectation of success in combining Yadav and Freund. The combination involved applying Freund's known, specific firewall techniques (application lists, database storage) to Yadav's compatible system architecture. Since both operated on the same principles and platforms (Windows, WinSock), integrating Freund's detailed firewall rules and management into Yadav's framework would have produced the predictable result of an effective, application-aware firewall, as claimed in the ’078 patent.

4. Key Claim Construction Positions

• internal permitted program storage: Petitioner proposed the construction "internal storage of information identifying programs permitted by the firewall." This broad construction was argued to be supported by the specification and allows for various data structures, such as the policy repositories in Yadav or the database in Freund, to meet the limitation.
• list of programs: Proposed as "a collection of information identifying programs." Petitioner argued this term is duplicative of the internal permitted program storage limitation and should not be confined to a specific data structure, thus encompassing the application-specific policies in Yadav and the application database in Freund.
• internal permitted port storage: Proposed as "internal storage of information identifying permitted ports." This construction runs parallel to the program storage term and is met by Yadav’s "authorization list," which stored parameters (including ports) for approved communication channels.
• server port: Proposed as "a port for listening to accept a new inbound communication." This construction clarifies that the port is for an application acting as a server, which Petitioner argued was disclosed in Yadav when its system intercepted "listen" requests and in Freund when monitoring server activity.
• a port of a packet of inbound traffic: Proposed as "the destination port of a packet of inbound traffic." This construction specifies which port on an inbound packet is relevant for comparison, which Petitioner contended is required by the logic of the patent and disclosed in the prior art.

5. Relief Requested

• Petitioner requested that the Board institute an inter partes review (IPR) and cancel claims 7-11, 13-15, 21, and 23-25 of the ’078 patent as unpatentable.