PTAB

IPR2015-00813

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 ’009 patent discloses techniques for establishing secure communications, such as a virtual private network (VPN), in response to a domain name service (DNS) request. The system uses a modified DNS server that intercepts a request, determines if the destination requires a secure connection, and then facilitates the creation of an encrypted link.

3. Grounds for Unpatentability

Ground 1: Obviousness over Aventail and RFC 2401 - Claims 1, 6-14, 19-20, and 22-25 are obvious over Aventail in view of RFC 2401.

  • Prior Art Relied Upon: Aventail (Aventail Connect v3.01/v2.51 Administrator’s Guide, published no later than Jan. 31, 1999) and RFC 2401 (“Security Architecture for the Internet Protocol,” published Nov. 1998).
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Aventail, a guide for a commercial VPN product, taught nearly every element of the independent claims. Aventail described a system where client software intercepts connection requests (including DNS lookups) to determine if a remote host requires a secure connection. If a secure connection was required, Aventail established an encrypted channel (a VPN) to a proxy server (the Aventail Extranet Server) protecting the remote host. Petitioner contended the only potential distinction was that Aventail did not explicitly describe true "end-to-end" encryption, where data remains encrypted through intermediary proxies to the final destination host.
    • Motivation to Combine: Petitioner asserted a person of ordinary skill in the art (POSITA) would combine Aventail with RFC 2401 to implement end-to-end encryption. Both references addressed the same field of establishing secure network communications. RFC 2401, an Internet standard for IPsec, expressly taught end-to-end encryption, including configurations where traffic passes through a firewall or proxy. A POSITA would combine the teachings to improve the security of the Aventail system—a known and desirable goal—by ensuring data remained encrypted across the entire communication path, including within the destination's internal network.
    • Expectation of Success: Petitioner claimed a POSITA would have a high expectation of success. RFC 2401 stated that its end-to-end encryption technique "imposes no new requirements on the hosts or security gateways," suggesting straightforward implementation. Since both Aventail and IPsec (from RFC 2401) operate at the IP layer to provide security, their combination would have been predictable and achievable with only routine effort.

Ground 2: Obviousness over Aventail, RFC 2401, and RFC 2543 - Claims 2-5 and 15-18 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,” published Mar. 1999).
  • Core Argument for this Ground:
    • Prior Art Mapping: This ground built upon the foundation of Ground 1, addressing dependent claims that added limitations for audio-video conferencing and telephony services. Petitioner argued that the combination of Aventail and RFC 2401 already established the underlying end-to-end encrypted communication link. RFC 2543, an Internet standard for Session Initiation Protocol (SIP), disclosed a network-based architecture for secure video telephony supporting both audio and video, and taught that these sessions could use end-to-end encryption.
    • Motivation to Combine: Petitioner argued that Aventail was described as a "protocol-independent" security solution capable of supporting various applications. A POSITA would be motivated to add support for common and valuable services like telephony and video conferencing, as taught by RFC 2543, over the secure VPN established by Aventail and RFC 2401. This would allow an organization to apply consistent security policies across all types of network traffic, a clear benefit.
    • Expectation of Success: Implementing support for SIP-based telephony within the Aventail architecture would have been straightforward from a technical perspective. Adding a known, standard application layer protocol (SIP) on top of an established secure network layer (the Aventail/IPsec VPN) was a conventional design choice.

4. Key Claim Construction Positions

  • "interception of the DNS request": Petitioner argued this term should be construed as "receiving a DNS request pertaining to a first entity at another entity." This construction was central to its argument that Aventail's system, where a client or proxy server receives and acts on a DNS request intended for a different, authoritative DNS server, met this limitation.
  • "encrypted communication link": Petitioner proposed the construction "a transmission path that restricts access to data, addresses, or other information on the path at least by using encryption." This interpretation supported Petitioner's view that the VPN tunnels created by Aventail and IPsec (from RFC 2401) satisfied this claim element.
  • "provisioning information": Petitioner proposed this term meant "information that enables communication in a virtual private network, where the virtual private network uses encryption." Petitioner mapped this to information disclosed in Aventail, such as SSL certificates, encryption methods, and SOCKS negotiation parameters, which are provided to the client to establish the secure link.

5. Relief Requested

  • Petitioner requested institution of an inter partes review and cancellation of claims 1-8, 10-20, and 22-25 of Patent 8,850,009 as unpatentable.