Juniper Networks Inc v. Implicit LLC

1. Case Identification

• Patent #: 8,694,683
• Filed: February 13, 2020
• Petitioner(s): Juniper Networks, Inc.
• Patent Owner(s): Implicit, LLC
• Challenged Claims: 1-2, 4-6, and 8-14

2. Patent Overview

• Title: Method and System for Data Demultiplexing
• Brief Description: The ’683 patent relates to a computer system for data demultiplexing, which addresses the need to convert packet-based data between different formats. The purported invention is a system that can dynamically identify a sequence of conversion routines for processing data packets, create a "path" for a message, and process subsequent packets of that message using the created path.

3. Grounds for Unpatentability

Ground 1: Obviousness over Smith and Decasper - Claims 1-2, 4-6, and 8-14 are obvious over Smith in view of Decasper.

• Prior Art Relied Upon: Smith ("Protecting a Private Network: The AltaVista Firewall," a 1997 journal article) and Decasper ("Router Plugins, A Software Architecture for Next Generation Routers," a 1998 publication).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that during prosecution, the Patent Owner distinguished the claims from Decasper by adding a limitation requiring the execution of a transport layer protocol like Transmission Control Protocol (TCP). Smith, an application-layer gateway (ALG) firewall, inherently executes TCP to manage connections for protocols like HTTP, SMTP, and FTP. It acts as an endpoint for two separate TCP connections (client-to-firewall and firewall-to-server), thus processing packets at the TCP layer and converting them for the application layer. Decasper taught a modular, extensible software framework using "plugins" to handle network functions. It classified packets into "flows," dynamically created a processing path of plugins for the first packet of a flow, and cached that path in a "flow table" for efficient processing of subsequent packets. Petitioner asserted that Decasper’s framework disclosed the dynamic path creation and storage limitations of the challenged claims.
  • Motivation to Combine: A POSITA would combine these references because Decasper expressly stated its framework is "very well suited to Application Layer Gateways (ALGs), and to security devices like Firewalls," such as Smith. A POSITA would have been motivated to apply Decasper's extensible plugin architecture to Smith's existing protocol stack (TCP, HTTP, etc.) to improve modularity and make future protocol updates more efficient and less costly. Furthermore, Smith’s "Future Enhancements" section described desired features like IPv6 and VPN support, which Decasper's existing plugin infrastructure already supported.
  • Expectation of Success: Petitioner contended a POSITA would have had a high expectation of success, as the combination involved the straightforward engineering task of reorganizing the existing protocol-processing functions of Smith into the modular "plugin" architecture described by Decasper.

Ground 2: Obviousness over CheckPoint and Decasper - Claims 1-2, 4-6, and 8-14 are obvious over CheckPoint in view of Decasper.

• Prior Art Relied Upon: CheckPoint (Selected webpages from www.checkpoint.com, archived Feb. 1998) and Decasper (a 1998 publication).
• Core Argument for this Ground:
  • Prior Art Mapping: This ground presented an alternative to Smith for teaching the TCP processing limitation. CheckPoint described the FireWall-1 product, an enterprise firewall that used "Security Servers" for various application-layer protocols. Its "Content Security" feature included anti-virus inspection for files transferred via HTTP, FTP, or SMTP. To perform this inspection, FireWall-1 must first collect and reassemble the file from its constituent packets, a process that requires executing TCP. This execution necessarily involved stripping the TCP headers, thereby converting the packets from a TCP format to the format of the application-layer protocol (e.g., HTTP). CheckPoint also disclosed an additional application-layer protocol, the Content Vectoring Protocol (CVP), providing another conversion routine. Decasper, as in Ground 1, supplied the underlying dynamic, flow-based plugin framework.
  • Motivation to Combine: The motivation was similar to Ground 1. A POSITA would combine the references because Decasper expressly recommended its framework for "security devices like Firewalls," such as CheckPoint's FireWall-1. Applying Decasper’s extensible architecture would make the various protocols implemented by CheckPoint (TCP, HTTP, CVP, etc.) more convenient and less costly to update. The CVP protocol itself was described as being finalized, suggesting periodic updates for which Decasper's extensibility would be beneficial.
  • Expectation of Success: Petitioner argued that a POSA would have a reasonable expectation of success in applying Decasper's established framework to the known functions of the CheckPoint firewall for the same reasons of extensibility and performance.

4. Key Claim Construction Positions

• "execute a Transmission Control Protocol (TCP)" / "a transport layer protocol is executed": Petitioner proposed this term be construed to mean "operate on one or more packets whose outermost header is a TCP header." This construction was central to mapping Smith and CheckPoint, which act as TCP endpoints and process packets at the TCP layer.
• "convert one or more packets [having a TCP format] into a different format": Petitioner proposed this be construed as "convert the outermost header structure of the packet(s) from TCP...to another type of header structure." This was crucial for the argument that stripping the TCP header to pass data to an application-layer protocol, as done in both Smith and CheckPoint, met the claim limitation.
• "sequence of routines" / "list of conversion routines": Petitioner proposed construing this as software routines in a sequence that was not established before receiving a first packet. This construction aligned with Decasper's method of dynamically building a processing path for a new flow, rather than selecting from a pre-configured list.

5. Arguments Regarding Discretionary Denial

• §314(a) (Fintiv Factors): Petitioner argued against discretionary denial because this was the first IPR petition filed against the ’683 patent, only two grounds of attack were presented, and the parallel litigation schedule would not preclude a final written decision within the one-year statutory deadline.
• §325(d) (Same or Substantially Same Art): Petitioner argued against denial, acknowledging that Decasper was presented to the examiner during prosecution. However, the petition asserted that the examiner never considered the combinations of Decasper with either Smith or CheckPoint. These new primary references were argued to be material because they supplied the specific TCP-processing teachings that the Patent Owner previously argued were missing from Decasper alone, thus overcoming the primary basis for allowance.

6. Relief Requested

• Petitioner requested the Board institute an inter partes review and cancel claims 1-2, 4-6, and 8-14 of Patent 8,694,683 as unpatentable.