Apple Inc v. VirnetX Inc

1. Case Identification

• Case #: IPR2014-00482
• Patent #: 7,188,180
• Filed: March 7, 2014
• Petitioner(s): Apple Inc.
• Patent Owner(s): VirnetX, Inc. and Science Application International Corporation
• Challenged Claims: 1, 4, 6, 10, 12-15, 17, 20, 22, 26, 28-31, 33, 35, and 37

2. Patent Overview

• Title: Method for Establishing Secure Communication Link Between Computers of Virtual Private Network
• Brief Description: The ’180 patent discloses a method for creating a secure virtual private network (VPN) communication link. The method involves a client computer receiving a non-standard "secure domain name," querying a special "secure domain name service" to resolve it into a "secure computer network address," and then using that address to establish an encrypted communication link.

3. Grounds for Unpatentability

Ground 1: Anticipation by Kiuchi - Claims 1, 4, 10, 12-15, 17, 20, 26, 28-31, 33, and 35 are anticipated by [Kiuchi](https://ai-lab.exparte.com/case/ptab/IPR2014-00482/doc/1004) under 35 U.S.C. §102.

• Prior Art Relied Upon: Kiuchi (a 1996 publication titled “C-HTTP - The Development of a Secure, Closed HTTP-based Network on the Internet”).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Kiuchi discloses every element of the challenged claims. Kiuchi describes a secure "C-HTTP" protocol for creating a closed virtual network between institutions. Petitioner mapped Kiuchi's "C-HTTP name server" to the claimed "secure domain name service," as it resolves non-standard hostnames (the "secure domain name") that conventional DNS cannot. This server provides an IP address and public key (the "secure computer network address" and "provisioning information") to a client-side proxy. The proxy then uses this information to establish an encrypted C-HTTP connection (the "virtual private network communication link") with a server-side proxy and send access requests.

Ground 2: Obviousness over Kiuchi and Tavs - Claims 6, 22, and 37 are obvious over Kiuchi in view of [Tavs](https://ai-lab.exparte.com/case/ptab/IPR2014-00482/doc/1008).

• Prior Art Relied Upon: Kiuchi (1996 C-HTTP publication) and Tavs (Patent 6,073,175).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner asserted that claims 6, 22, and 37 add the limitation that the VPN is based on inserting a data value representing a "predetermined level of service" into a data packet. While Kiuchi provides the base VPN system, Tavs explicitly teaches a method for managing network congestion by prioritizing traffic. Tavs discloses embedding service-level information (e.g., business relevance) into an HTTP header request, which is then used to allocate bandwidth and prioritize data packets within a proxy-based network structure similar to Kiuchi's.
  • Motivation to Combine: A POSITA would combine Kiuchi with Tavs to improve the performance of Kiuchi’s secure network. Since networks like the one in Kiuchi are prone to congestion, incorporating Tavs' method for service-level categorization would provide a known solution to prioritize important business traffic, thereby making the network more efficient.
  • Expectation of Success: A POSITA would have a reasonable expectation of success because both systems use a similar client-proxy to server-proxy architecture for handling HTTP traffic, making the integration of Tavs' header-based service-level data into Kiuchi's data packets straightforward.

Ground 3: Anticipation by Beser - Claims 1, 4, 6, 10, 12-15, 17, 20, 22, 26, 28-31, 33, 35, and 37 are anticipated by [Beser](https://ai-lab.exparte.com/case/ptab/IPR2014-00482/doc/1031) under §102.

• Prior Art Relied Upon: Beser (Patent 6,496,867).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner contended that Beser discloses a system that anticipates all challenged claims. Beser describes establishing a secure IP tunnel between two end devices using a trusted-third-party network device, which functions as a domain name server. An originating device sends a request with a unique identifier (the "secure domain name," e.g., a dial-up phone number) to the trusted-third-party device (the "secure domain name service"). This service resolves the identifier and negotiates private IP addresses (the "secure computer network address") for the end devices to create a secure, anonymous tunnel (the "virtual private network communication link"). Beser further discloses that standard IP packets used in its system include a "type of service" field, which Petitioner argued meets the limitations for "provisioning information" and "level of service."

Ground 4: Obviousness over Beser and RFC 2401 - Claims 1, 4, 6, 10, 12-15, 17, 20, 22, 26, 28-31, 33, 35, and 37 are obvious over Beser in view of [RFC 2401](https://ai-lab.exparte.com/case/ptab/IPR2014-00482/doc/1032).

• Prior Art Relied Upon: Beser (Patent 6,496,867) and RFC 2401 ("Security Architecture for the Internet Protocol").

• Core Argument for this Ground:

  • Prior Art Mapping: This ground was presented as an alternative in case the Board found Beser did not explicitly teach encryption of all traffic within its IP tunnels, a potential requirement of a "virtual private network communication link." Petitioner argued that Beser itself teaches that IP tunnels ordinarily use encryption and expressly refers to the IPsec protocol, which is defined in RFC 2401. RFC 2401 provides the definitive standard for IPsec, detailing how network traffic is automatically encrypted when sent through security gateways.
  • Motivation to Combine: A POSITA would be motivated to combine Beser with RFC 2401 because Beser explicitly points to the IPsec protocol (defined in RFC 2401) as the conventional method for securing its IP tunnels. Implementing the standard IPsec encryption taught by RFC 2401 would be a natural and obvious step to ensure the security of the communication channel described in Beser.
  • Expectation of Success: Success would be expected, as Beser's system, which uses edge routers and gateways, is fully compliant with the network configurations described in RFC 2401 for implementing IPsec.

• Additional Grounds: Petitioner asserted additional obviousness challenges, including combining Kiuchi with Bhatti (to explicitly add standard HTTP request-and-response functionality) and combining Beser with Kiuchi (to use non-standard domain names as the unique identifier in Beser's system).

4. Key Claim Construction Positions

• Petitioner argued for constructions under the Broadest Reasonable Interpretation standard, noting they were consistent with positions taken in related litigation.
• "virtual private network": Proposed as "a network of computers that privately communicate with each other by encrypting traffic on insecure communication paths between the computers." This construction was argued to be broad and not limited to a specific number of computers or paths.
• "secure domain name": Proposed as "a non-standard domain name that corresponds to a secure computer network address and cannot be resolved by a conventional DNS." This emphasizes that the name is intentionally outside the standard public DNS system.
• "secure domain name service": Proposed as "a service that can resolve secure computer network addresses for a secure domain name for which a conventional domain name service cannot resolve addresses." This construction positions the service as a private or specialized counterpart to conventional DNS.

5. Relief Requested

• Petitioner requested the institution of an inter partes review and the cancellation of claims 1, 4, 6, 10, 12-15, 17, 20, 22, 26, 28-31, 33, 35, and 37 of the ’180 patent as unpatentable.