PTAB
IPR2017-00337
Apple Inc v. VirnetX Inc
Key Events
Petition
Table of Contents
petition Intelligence
1. Case Identification
- Case #: IPR2017-00337
- Patent #: 9,038,163
- Filed: November 29, 2016
- Petitioner(s): Apple Inc.
- Patent Owner(s): VirnetX Inc.
- Challenged Claims: 1-10, 12-18, 21-31, 33-39, and 42
2. Patent Overview
- Title: Systems and Methods for Connecting Network Devices Over Communications Network
- Brief Description: The ’163 patent describes techniques for establishing secure communications, such as virtual private networks (VPNs), over the Internet. The invention focuses on using a modified Domain Name System (DNS) server that, in response to a request to look up a network address, determines if a secure connection is requested and then facilitates the establishment of a direct, encrypted communication link.
3. Grounds for Unpatentability
Ground 1: Obviousness over Beser, RFC 2401, and RFC 2543 - Claims 1-10, 12-18, 21-31, 33-39, and 42 are obvious over Beser in view of RFC 2401 and RFC 2543.
- Prior Art Relied Upon: Beser (Patent 6,496,867), RFC 2401 ("Security Architecture for the Internet Protocol"), and RFC 2543 ("SIP: Session Initiation Protocol").
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner asserted that Beser taught a majority of the claimed elements for establishing a secure IP tunneling association. Beser described a trusted-third-party network device (which can be a DNS server) that receives a request containing a unique identifier (e.g., a domain name) for a destination device. This third-party device then consults a database of registered devices to facilitate a secure tunnel. Petitioner argued that two features were arguably not explicit in Beser: the use of end-to-end encryption and the discrete claim steps for "evaluating" a request and "determining" device availability.
- Petitioner contended that RFC 2401, which defines the IPsec protocol, supplied the missing teaching of end-to-end encryption. The combination of Beser and RFC 2401 would have rendered obvious a system that establishes a "direct encrypted communication link" carrying encrypted data.
- Further, Petitioner argued that RFC 2543, which defines the Session Initiation Protocol (SIP), taught the discrete "evaluating" and "determining" steps. RFC 2543’s call-initiation procedure involves sending a distinct "INVITE" message that queries the destination device to determine if it will accept an incoming call. This process directly maps to the claims' requirements of evaluating a request and determining if the target device is available to communicate before establishing the link.
- Motivation to Combine: The primary motivation to combine Beser with RFC 2401 was that Beser itself expressly identified IPsec (the subject of RFC 2401) as the conventional and desirable protocol for encrypting communications within its IP tunnels. A POSITA implementing Beser's security-focused system would have naturally looked to the IPsec standard detailed in RFC 2401 to provide robust encryption.
- The motivation to further combine this system with RFC 2543 stemmed from Beser's disclosure that its system could be used for Voice over IP (VoIP) and was compatible with IETF standards. A POSITA would have found it obvious to substitute the well-known and efficient SIP protocol from RFC 2543 for the H.323 protocol mentioned as an example in Beser. This would improve system efficiency by avoiding the overhead of setting up a call if the recipient was unavailable, a predictable improvement.
- Expectation of Success: A POSITA would have had a high expectation of success. Integrating the standard IPsec encryption protocol (RFC 2401) into a tunneling system that explicitly recommends its use (Beser) was a predictable and routine task. Likewise, incorporating a standard call setup protocol (RFC 2543) into a VoIP-capable system designed to be compatible with such standards would have yielded predictable results.
4. Key Claim Construction Positions
- "encrypted communication link": Petitioner argued for a construction of "a transmission path that restricts access to data, addresses, or other information on the path at least by using encryption." This construction was asserted to be consistent with constructions of similar terms (e.g., "secure communication link") adopted by the Board in prior IPRs involving patents from the same family as the ’163 patent.
- "virtual private network": For dependent claims reciting this term, Petitioner proposed the construction "two or more devices that can communicate over one or more transmission paths that restrict access to data, addresses, or other information on the path, generally using obfuscation methods to hide information on the path, including, but not limited to, one or more of anonymity, authentication, or encryption." This was also based on prior Board constructions for related patents.
- "domain name": Petitioner argued that the broadest reasonable interpretation is "a name corresponding to an IP address." This construction was deemed reasonable as it encompassed both the common understanding of a hierarchical name and a more general definition advanced by the Patent Owner in other proceedings.
5. Relief Requested
- Petitioner requested the institution of an inter partes review and the cancellation of claims 1-10, 12-18, 21-31, 33-39, and 42 of Patent 9,038,163 as unpatentable.
Analysis metadata