PTAB

IPR2016-00331

Apple Inc v. VirnetX Inc

Log In

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 ’696 patent describes techniques for secure communication over the Internet. The primary focus is on a method where a modified Domain Name System (DNS) server intercepts a request for a network address based on a domain name, determines if the requested destination supports secure communication, and if so, initiates a virtual private network (VPN) communication link to that destination. This is presented as an alternative to the patent’s broader disclosure of a "Tunneled Agile Routing Protocol" (TARP).

3. Grounds for Unpatentability

Ground 1: Claims 1-11, 14-25, and 28-30 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 teaches all limitations of the challenged claims. Independent claims 1 (system) and 16 (method) recite the core invention: (1) intercepting a request to look up an IP address based on a domain name; (2) determining if the target device is available for a secure service; and (3) initiating a VPN link based on that determination.
      • Petitioner contended that Beser discloses a system where a first network device intercepts a request containing a unique identifier (which Beser explicitly states can be a domain name) and forwards it to a trusted-third-party device for special processing. This trusted-third-party device, which can be a DNS server, checks an internal database to determine if the destination can establish a secure IP tunnel. This process directly maps to the "intercepting" and "determining" steps of the independent claims.
      • Upon a positive determination, Beser's system initiates a secure IP tunnel, which Petitioner argued is a "virtual private network communication link." While Beser’s primary security mechanism is anonymity via private IP addresses, the combination with RFC 2401 adds the element of encryption.
      • Petitioner further asserted that Beser, a system for creating secure tunnels for various data types, also discloses the subject matter of the dependent claims, including support for audio/video conferencing (claims 2-3, 17-18), messaging/email (claims 4-5, 19-20), telephony (claims 6, 21), specific modulation techniques (claims 7-8, 22-23), and use with mobile devices like notebook computers (claims 9-10, 24-25).
    • Motivation to Combine: Petitioner asserted that a person of ordinary skill in the art (POSA) would have been strongly motivated to combine the teachings of Beser and RFC 2401. The primary motivation comes from Beser itself, which expressly identifies the IPsec protocol as a conventional method for encrypting traffic within its IP tunnels. RFC 2401 is the definitive standard that defines the IPsec protocol. Therefore, a POSA implementing Beser's suggested encryption would have naturally and necessarily consulted RFC 2401 for guidance. Furthermore, Petitioner argued that the network topologies described in Beser (using gateways and end devices) are functionally identical to the secure gateway and host configurations detailed in RFC 2401, making the integration straightforward.
    • Expectation of Success: A POSA would have had a high expectation of success in combining the references. Beser was designed to be compliant with existing standards, and RFC 2401 provides the exact standard for implementing the encryption Beser suggests. Petitioner noted that even though Beser mentions potential performance challenges with encrypting high-volume streaming data, a POSA would have viewed this as a simple engineering trade-off (e.g., between video quality and security) or a problem solvable with increased computing power, not a teaching away from the combination.
    • Key Aspects: A central pillar of Petitioner's argument was that the Patent Trial and Appeal Board, in a Final Written Decision for a related patent (IPR2014-00237), had already found that Beser anticipates or renders obvious nearly identical claim limitations, including that Beser's domain-name-based tunneling request constitutes a "request for a look up of an IP address."

4. Key Claim Construction Positions

  • "intercept[ing] ... a request": Petitioner argued this term should be construed as "receiving a request pertaining to a first entity at another entity." This construction, previously adopted by the Board, is critical because it allows the functionality of Beser's trusted-third-party device (which receives the request from a first network device) to satisfy the claim limitation, even though it is not the original intended destination of the user's communication.
  • "virtual private network communication link": Petitioner asserted this term means "a transmission path that includes a portion of a public network and restricts access to data, addresses, or other information on the path, generally using obfuscation methods...including, but not limited to, one or more of anonymity, authentication, or encryption." This construction is important because it does not strictly require encryption. Petitioner argued that Beser's system, which provides anonymity by hiding true IP addresses, meets this definition on its own. The addition of RFC 2401 simply adds the optional, but obvious, feature of encryption.
  • "secure communications service": Construed as "the functional configuration of a network device that enables it to participate in a secure communications link with another computer or device." This broad definition allows Beser’s system, which configures devices to create a secure tunnel, to meet the claim limitation.

5. Relief Requested

  • Petitioner requested 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.