Apple Inc v. VirnetX Inc

1. Case Identification

• Case #: IPR2016-00332
• Patent #: 8,504,696
• Filed: December 22, 2015
• Petitioner(s): Apple Inc.
• Patent Owner(s): VirnetX Inc.
• Challenged Claims: 1-11, 14-25, 28-30

2. Patent Overview

• Title: System and Method Employing an Agile Network Protocol for Secure Communications Using Secure Domain Names
• Brief Description: The ’696 patent discloses techniques for automatically establishing a secure communication link, such as a virtual private network (VPN), over the Internet. The system uses a modified DNS server to intercept a device’s request to look up an IP address for a domain name, determine if the destination requires a secure connection, and if so, initiate the secure link.

3. Grounds for Unpatentability

Ground 1: Obviousness over Aventail and RFC 2401 - Claims 1, 4, 5, 9-11, 14-16, 19, 20, 24, 25, 28, and 30 are obvious over Aventail in view of RFC 2401.

• Prior Art Relied Upon: Aventail (Aventail Connect v3.01/v2.51 Administrator’s Guide) and RFC 2401 (“Security Architecture for the Internet Protocol,” Nov. 1998).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Aventail discloses a VPN system highly analogous to the claimed invention. In Aventail, client software intercepts a DNS lookup request, checks a local table of redirection rules to determine if the destination host requires a secure connection, and if so, establishes an encrypted VPN link via a proxy server. This process meets the core limitations of independent claims 1 and 16: intercepting a request based on a domain name, determining if a secure service is available, and initiating a VPN link based on that determination.
  • Motivation to Combine: Petitioner contended that while Aventail teaches establishing an encrypted link to a proxy server, it does not explicitly disclose that the connection remains encrypted from the proxy to the final destination host (end-to-end encryption). RFC 2401, which describes the IPsec standard, expressly teaches methods for providing end-to-end encryption, including through intermediate proxies. A POSITA would combine RFC 2401 with Aventail to enhance security, recognizing that internal networks behind a proxy are not always secure.
  • Expectation of Success: A POSITA would have a high expectation of success, as combining the two was a predictable implementation of a known security technique. RFC 2401 stated that its end-to-end encryption technique "imposes no new requirements on the hosts or security gateways, other than a requirement for a security gateway to be configurable to pass IPsec traffic," suggesting straightforward implementation.

Ground 2: Obviousness over Aventail, RFC 2401, and RFC 2543 - Claims 2, 3, 6-8, 17, 18, and 21-23 are obvious over Aventail and RFC 2401 in further view of RFC 2543.

• Prior Art Relied Upon: Aventail, RFC 2401, and RFC 2543 (“SIP: Session Initiation Protocol,” Mar. 1999).
• Core Argument for this Ground:
  • Prior Art Mapping: This ground builds on the base combination of Aventail and RFC 2401 to address dependent claims requiring an "audio-video conferencing service" or a "telephony service." Petitioner asserted that the Aventail system is "protocol-independent," making it a suitable platform for various applications. RFC 2543 discloses the Session Initiation Protocol (SIP), a well-known standard for establishing and managing multimedia sessions like audio/video conferences and telephony calls, and teaches that these sessions can be encrypted.
  • Motivation to Combine: A POSITA would be motivated to implement the telephony services of RFC 2543 over the secure VPN framework established by Aventail and RFC 2401. This would enable organizations to apply consistent security and access control policies across all supported network services, including real-time communications.
  • Expectation of Success: Implementing a known protocol like SIP over a protocol-independent secure layer like the one taught by Aventail would have been a straightforward technical task for a POSITA.

Ground 3: Obviousness over Aventail, RFC 2401, and Yeager - Claims 15 and 30 are obvious over Aventail and RFC 2401 in further view of Yeager.

• Prior Art Relied Upon: Aventail, RFC 2401, and Yeager (“Web Server Technology,” 1996).
• Core Argument for this Ground:
  • Prior Art Mapping: This ground addresses dependent claims 15 and 30, which require the server that intercepts the request to be a separate network device from the client. While Aventail discloses a configuration where a separate server can handle requests, Petitioner introduced Yeager to strengthen this point. Yeager explicitly discusses the advantages of moving secure connection functionality from individual client computers to an intermediate proxy server.
  • Motivation to Combine: Yeager provides a clear motivation: moving the functionality to a centralized, intermediate server reduces the "huge administrative task" and portability problems associated with configuring and maintaining security software on every client device. A POSITA would combine Yeager's teaching with the Aventail/RFC 2401 system as a well-known design choice to improve network manageability and scalability.
  • Expectation of Success: This modification was presented as a routine design choice between two known architectures (client-centric vs. server-centric). A POSITA would expect success because it involved implementing existing functionality in a predictable manner to achieve a known benefit.

4. Key Claim Construction Positions

• "intercepting . . . a request": Petitioner argued for the construction "receiving a request pertaining to a first entity at another entity." This construction is broad enough to cover both client-side software intercepting its own outgoing requests and a separate proxy server receiving requests intended for a different destination (e.g., a primary DNS server), both of which are scenarios disclosed in the prior art.
• "virtual private network communication link": Petitioner contended the term should be construed as "a transmission path that includes a portion of a public network and restricts access to data," which does not strictly require encryption. This construction was important to Petitioner’s argument that Aventail met the basic limitation, with RFC 2401 being added to provide the specific, robust end-to-end encryption that rendered the claims obvious.

5. Arguments Regarding Discretionary Denial

• Petitioner filed this petition concurrently with another IPR (IPR2016-0331) against the same ’696 patent. Petitioner argued that the Board should institute both petitions because each one "advances unique grounds based on different primary references" and presents "distinct and non-redundant grounds," thereby warranting independent institution of trial.

6. Relief Requested

• Petitioner requests institution of an inter partes review and cancellation of claims 1-11, 14-25, and 28-30 of the ’696 patent as unpatentable under 35 U.S.C. §103.