PTAB

IPR2016-01585

Apple Inc v. VirnetX Inc

Log In
Key Events
Petition
petition

1. Case Identification

2. Patent Overview

  • Title: System and Method Employing an Agile Network Protocol for Secure Communications Using Secure Domain Names
  • Brief Description: The ’516 patent discloses techniques for establishing secure communications over a network. The system involves intercepting a DNS request, determining if the destination supports a secure service, and if so, initiating an encrypted communication link, such as a virtual private network (VPN), with the destination site.

3. Grounds for Unpatentability

Ground 1: Obviousness over Beser and RFC 2401 - Claims 1-9, 11-23, and 25-28 are obvious over Beser in view of RFC 2401.

  • Prior Art Relied Upon: Beser (Patent 6,496,867) and RFC 2401 ("Security Architecture for the Internet Protocol," Nov. 1998).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that the combination of Beser and RFC 2401 disclosed all limitations of the challenged claims. Beser taught a system for establishing a secure IP tunnel between an originating device and a terminating device to provide anonymity and security. In Beser, a request from the originating device containing a unique identifier (e.g., a domain name) is intercepted by a network device and forwarded to a trusted-third-party device (e.g., a DNS server). This trusted device then determines if the destination supports tunneling by checking an internal database. If available, the trusted device initiates the secure tunnel by negotiating private IP addresses. Petitioner contended this maps directly to the ’516 patent’s core method of "intercepting," "determining," and "initiating" a secure connection. RFC 2401, a well-known standard, disclosed the IPsec protocol for automatically encrypting traffic within such IP tunnels, thereby providing the claimed "encrypted communication link."
    • Motivation to Combine: A POSITA would combine Beser and RFC 2401 because Beser expressly identified IPsec (the protocol defined in RFC 2401) as the conventional and desirable method for encrypting data within its IP tunnels. Petitioner asserted that Beser’s primary goal was enhancing user privacy and security, and a POSITA would have naturally looked to the industry-standard IPsec protocol detailed in RFC 2401 to implement the necessary encryption. Furthermore, the network topology described in Beser was argued to be analogous to a specific end-to-end encryption configuration ("case 3") detailed in RFC 2401, making the combination straightforward.
    • Expectation of Success: A POSITA would have had a high expectation of success in combining the references. Beser explicitly suggested that its tunneling scheme was compatible with standard techniques like IPsec. RFC 2401 provided a detailed and widely adopted framework for implementing such encryption. Petitioner argued that any statements in Beser regarding computational challenges of encrypting streaming media would have been viewed by a POSITA as a solvable engineering trade-off (e.g., by using more powerful hardware) rather than a reason not to combine the teachings for general data security.

4. Key Claim Construction Positions

  • "intercept[ing] ... a request": Petitioner proposed this term be construed as "receiving a request pertaining to a first entity at another entity." This construction was argued to be critical because, in Beser, intermediate network devices (the first network device and the trusted-third-party device) receive a request that is ultimately directed to the terminating end device. This interpretation allows Beser’s architecture to meet the "intercepting" limitation of the claims.
  • "encrypted communication link": Petitioner proposed this term meant "a transmission path that restricts access to data, addresses, or other information on the path at least by using encryption." This construction was central to the argument that RFC 2401’s disclosure of IPsec supplies a key element that complements Beser’s tunneling framework. The combination creates a link that is not only anonymized by Beser’s private addresses but also encrypted per RFC 2401.

5. Key Technical Contentions (Beyond Claim Construction)

  • Beser Does Not "Teach Away" from Encryption: Petitioner dedicated significant argument to refuting the potential assertion that Beser "teaches away" from encrypting streaming media. Petitioner contended that Beser merely acknowledged that encrypting high-volume data streams could present performance challenges with the computing power of the era. This was presented not as a statement that encryption should not be used, but as a known engineering trade-off. A POSITA, particularly when guided by RFC 2401, would have understood this not as a barrier but as a problem to be solved with more powerful hardware or by adjusting encryption parameters, a common practice in the field.

6. Relief Requested

  • Petitioner requests institution of an inter partes review and cancellation of claims 1-9, 11-23, and 25-28 of the ’516 patent as unpatentable.