PTAB

IPR2017-01391

Intel Corp v. Alacritech Inc

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: Fast-Path Apparatus for Receiving Data Corresponding a TCP Connection
  • Brief Description: The ’036 patent describes a system for improving network performance by offloading Transmission Control Protocol (TCP) processing from a host computer's main processor to a specialized processor on a network interface card (NIC). The system uses a "fast path" for established connections, where the NIC processes packets and transfers data directly to host memory, and a "slow path" where packets are handled by the host's conventional protocol stack.

3. Grounds for Unpatentability

Ground 1: Claims 1-7 are obvious over Erickson in view of Tanenbaum96.

  • Prior Art Relied Upon: Erickson (Patent 5,768,618) and Tanenbaum96 (A. Tanenbaum, Computer Networks, 3rd ed. (1996)).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that the combination of Erickson and Tanenbaum96 taught all limitations of the challenged claims.
      • Erickson disclosed the core architecture of the claimed invention: an I/O device adapter (a NIC) that offloads network protocol processing from a host computer. It taught a "fast path" for applications to bypass the host's slow, conventional protocol stack ("normal streams processing"). Erickson’s adapter used pre-negotiated "endpoint protocol data" and a "protocol script" — a "context" for communication — to process packets. This context included Media Access Control (MAC) and Internet Protocol (IP) layer information. Erickson’s primary example focused on the User Datagram Protocol (UDP), but it explicitly mentioned its applicability to TCP/IP and directed a person of ordinary skill in the art (POSITA) to the Tanenbaum textbook for TCP details.
      • Tanenbaum96, a widely-cited textbook, provided the TCP-specific details that Petitioner alleged were necessary to adapt Erickson’s system. Tanenbaum96 taught "fast path" processing for established TCP connections to reduce software overhead. It described using a "connection record" (analogous to Erickson’s context) containing TCP state information (e.g., sequence numbers, window size, TCP ports) to process packets. It also taught "header prediction," a method for the NIC's transport entity to quickly check if an incoming packet belongs to an established connection suitable for fast-path handling, thereby acting as the claimed "receive sequencer" (claim 2).
      • Combination: Petitioner asserted that combining these references rendered the claims obvious. Erickson provided the fundamental fast-path/slow-path hardware architecture for offloading protocol processing, including the use of a pre-negotiated context with MAC/IP addresses to transfer data directly to host memory (claim 5). Tanenbaum96 supplied the well-known techniques for implementing this architecture specifically for TCP. A POSITA would have incorporated Tanenbaum96’s teachings to include TCP state information in Erickson’s context (claim 1), use header prediction to classify packets (claims 2-3), create and prepend TCP headers (claim 4), and include TCP receive window and port information in the context (claims 6-7).
    • Motivation to Combine: Petitioner asserted multiple motivations. First, Erickson provided an express motivation by explicitly naming TCP/IP as a protocol its system could support and referencing an earlier edition of the Tanenbaum textbook for TCP details. A POSITA seeking to implement Erickson’s system for the increasingly popular TCP/IP protocol in 1996 would have naturally consulted the then-current edition, Tanenbaum96. Second, the combination was motivated by the predictable goal of improving network performance for TCP traffic, which was a well-known objective in the art.
    • Expectation of Success: Petitioner argued a POSITA would have had a high expectation of success. The combination involved applying the standard, well-documented TCP fast-path methods from Tanenbaum96 to the general-purpose protocol offload engine described in Erickson. This was portrayed as a straightforward implementation of known techniques to achieve a predictable result, not an inventive leap.

4. Key Claim Construction Positions

  • "context for communication": Petitioner did not propose a specific construction under the broadest reasonable interpretation standard. Instead, for the purposes of the petition, it adopted the Patent Owner's proposed construction from related district court litigation: "data regarding an active connection." Petitioner argued that even under this construction, the claims were obvious.
  • "prepend": Petitioner argued that, based on the patent’s specification, "prepend" should be construed to mean "add to the front." The specification provided an explicit parenthetical definition: "...prepends (adds to the front) that status information to the packet..."

5. Relief Requested

  • Petitioner requests institution of an inter partes review (IPR) and cancellation of claims 1-7 of the ’036 patent as unpatentable.