PTAB

IPR2025-00201

Liberty Mutual Insurance Company v. Intellectual Ventures I

Log In

1. Case Identification

2. Patent Overview

  • Title: Secure Virtual Community Network System
  • Brief Description: The ’785 patent relates to a system for creating a private virtual dynamic network that allows computing devices on public or private networks to communicate securely. The system uses a central "virtual network manager" to register devices and route traffic, purporting to solve issues like IP address depletion and device mobility by enabling users to collaborate from different locations as if on a single physical local network.

3. Grounds for Unpatentability

Ground 1: Obviousness over Mehta and RFC-1383 - Claims 1-2, 6-12, 22, 25-26, 28-49, 51-55, 60-63, 65-66, 72-80, and 82-90 are obvious over Mehta in view of RFC-1383.

  • Prior Art Relied Upon: Mehta (Application # US 2003/0028671) and RFC-1383.
  • Core Argument for this Ground:
    • Prior Art Mapping: Petitioner argued that Mehta discloses the core architecture of the claimed "virtual network manager." Mehta’s Address Management Proxy System (AMPS) was asserted to be a virtual network system that manages communications between devices on private and public networks. Petitioner mapped Mehta’s "Address Proxy/Router" to the claimed "route director" and its "DNS/API server" to the claimed "DNS server." The temporary public IP addresses that Mehta's AMPS allocates from a pool were argued to meet the limitations of a "virtual network address," as they are unique within the system and effectively non-routable to a specific device until dynamically assigned.
    • The central argument focused on the claimed DNS server function: returning a triplet of addresses (a public address for the route director, a private address for the destination device, and a virtual address for the destination device) in response to a single DNS query. Petitioner argued that while Mehta teaches returning a public address for its router and internally uses the destination's private address, it does not explicitly teach returning all three in a single DNS response. RFC-1383 was argued to supply this teaching. RFC-1383 describes an experiment in DNS-based IP routing and explicitly teaches using standard DNS "TXT" records to return multiple, arbitrary pieces of routing information, including multiple IP addresses and other data fields, in response to a single query.
    • Motivation to Combine (for §103 grounds): Petitioner asserted that a person of ordinary skill in the art (POSA) implementing Mehta's system would be motivated to combine it with the teachings of RFC-1383. Because DNS is a foundational and standardized Internet technology, a POSA seeking to implement or improve the DNS-based routing in Mehta would naturally consult IETF standards documents (RFCs) like RFC-1383. A POSA would combine the two to leverage RFC-1383's standardized, efficient method of returning multiple data points via TXT records, which is a more practical and interoperable solution than developing a proprietary method or performing extensive modifications to DNS server source code as suggested by Mehta.
    • Expectation of Success (for §103 grounds): Petitioner contended a POSA would have a high expectation of success in making this combination. Both references operate in the predictable field of computer networking, and the proposed modification involves applying a known data-return technique (from RFC-1383) to a known system architecture (Mehta). The result would be the predictable aggregation of known elements to achieve the claimed system.

4. Key Claim Construction Positions

  • Petitioner argued that the terms "register module" (claims 30, 34, 76) and "join module" (claims 35-37, 77-78) are means-plus-function terms governed by 35 U.S.C. §112, ¶6.
  • The petition asserted that the generic term "module" is a nonce word that, without more, fails to recite sufficient definite structure for performing the claimed functions. These functions include "receiving a registration request," "distributing a virtual network address," "receiving a join request," and "maintaining data to associate a virtual network address with a device."
  • Petitioner proposed that the corresponding structure in the ’785 patent's specification is limited to the specific algorithms and process flows disclosed, such as the registration exchange using an HTTP wrapper shown in Figure 12A and the join/leave process flows in Figures 13 and 14. This construction is critical to the invalidity argument, as it narrows the claim scope to a specific implementation that Petitioner then maps to the prior art, rather than a broad functional concept.

5. Arguments Regarding Discretionary Denial

  • Petitioner argued that discretionary denial of the inter partes review (IPR) would be inappropriate under both 35 U.S.C. §325(d) and §314(a).
  • Under §325(d), Petitioner asserted that the primary prior art combination of Mehta and RFC-1383 presents a new question of patentability that was not considered by the examiner during original prosecution or in a subsequent ex parte reexamination.
  • Under §314(a) and the Fintiv factors, Petitioner argued that the parallel district court litigation is in a very early stage. At the time of filing, the Markman process had not begun, fact discovery was still open, and the trial date was set for late 2025, well after a Final Written Decision (FWD) in the IPR would be due. Petitioner also noted that the IPR challenges claims that have not been asserted in the district court, meaning the IPR provides the only forum for an efficient resolution on the validity of those claims. These factors were argued to weigh strongly in favor of institution.

6. Relief Requested

  • Petitioner requested institution of an IPR and cancellation of claims 1-2, 6-12, 22, 25-26, 28-49, 51-55, 60-63, 65-66, 72-80, and 82-90 of the ’785 patent as unpatentable.