PTAB
IPR2025-00201
Liberty Mutual Insurance Co v. Intellectual Ventures I
Key Events
Petition
Table of Contents
petition
1. Case Identification
- Case #: IPR2025-00201
- Patent #: 7,949,785
- Filed: November 20, 2024
- Petitioner(s): Liberty Mutual Insurance Company, Liberty Mutual Technology Group, Inc., Liberty Mutual Holding Company Inc., Liberty Mutual Group Inc., Liberty Mutual Plano LLC, Comparion Insurance Agency, LLC, Ironshore Holdings (U.S.) Inc., and Comerica Incorporated
- Patent Owner(s): Intellectual Ventures I LLC
- Challenged Claims: 1-2, 6-12, 22, 25-26, 28-49, 51-55, 60-63, 65-66, 72-80, and 82-90
2. Patent Overview
- Title: Secure Virtual Community Network System
- Brief Description: The ’785 patent describes 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 virtual network manager that handles device registration, routing, and Domain Name System (DNS) services to manage communication within the virtual network.
3. Grounds for Unpatentability
Ground 1: Obviousness over Mehta and RFC-1383 - All challenged claims are obvious over Mehta in view of RFC-1383.
- Prior Art Relied Upon: Mehta (Application # US2003/0028671) and RFC-1383 (Request for Comment, Dec. 1992).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued that Mehta discloses the core components of the claimed virtual network system, including a virtual network manager (its Address Management Proxy System, or AMPS), a DNS server, device registration, and a route director (its Address Proxy/Router). Mehta's system uses DNS to map a device's unique identifier to a public IP address. However, the key feature that led to the ’785 patent’s allowance—returning a triplet of addresses (a public route director address, a private destination address, and a virtual destination address) in a single DNS response—is taught by combining Mehta with RFC-1383. Petitioner asserted that RFC-1383 explicitly teaches using DNS TXT records to return multiple pieces of information, including multiple IP addresses, in response to a single query to facilitate routing. A POSITA would have found it obvious to apply RFC-1383's efficient DNS data return method to Mehta's virtual network system to provide the necessary routing information, including the private and virtual addresses needed for communication.
- Motivation to Combine: Petitioner contended that a person of ordinary skill in the art (POSITA) implementing Mehta’s system, which relies on DNS for routing, would be motivated to improve its functionality by consulting well-known DNS standards like RFCs. RFC-1383 directly addresses routing IP packets using information stored in DNS. A POSITA would have been motivated to combine RFC-1383's disclosure of using TXT records to return multiple addresses with Mehta’s system to provide all necessary routing information (public, private, and virtual addresses) in a single, efficient DNS response, rather than modifying the DNS server source code as suggested by Mehta. This combination represented a predictable and less burdensome implementation.
- Expectation of Success: Petitioner argued a POSITA would have had a high expectation of success because DNS is a foundational, standardized, and well-understood internet protocol. Combining the known DNS mechanism from RFC-1383 with the virtual network architecture of Mehta would involve applying predictable technologies to achieve the desired result of efficiently distributing routing information.
4. Key Claim Construction Positions
- "register module" (claims 30, 34, 76) and "join module" (claims 35-37, 77-78): Petitioner argued these terms are means-plus-function limitations under 35 U.S.C. §112, ¶6 because "module" is a nonce word used without sufficient corresponding structure in the claims.
- Function/Structure for "register module": The function is "receiving [a] registration request...and distributing a virtual network address." Petitioner identified the corresponding structure in the specification as the registration exchange process detailed in Figure 12A, involving a Member Agent sending an HTTP-wrapped registration packet containing a Fully Qualified Domain Name (FQDN) and a Diffie-Hellman key exchange request to the VCN Manager.
- Function/Structure for "join module": The function is "receiving join and leave requests from the device or its agent." Petitioner identified the corresponding structure as the Member Join and leave processes illustrated in Figures 13 and 14, respectively, which detail the specific message exchanges (e.g., Init Request, Join Request, Acks/Nacks) between a Member Agent and the VCN Manager.
5. Arguments Regarding Discretionary Denial
- §325(d) - Same or Substantially Same Art or Arguments: Petitioner argued against discretionary denial under §325(d), asserting that the primary prior art combination of Mehta and RFC-1383 was never considered by the examiner during original prosecution or in a subsequent ex parte reexamination. While Mehta was cited in the reexamination, it was in combination with different references. Petitioner contended that RFC-1383 is new to the proceedings and critical to establishing how a POSITA would have arrived at the claimed invention, particularly the return of a triplet of addresses in a DNS response.
- §314(a) - Fintiv Factors: Petitioner argued that the Fintiv factors weigh against discretionary denial. The parallel district court litigation is in a very early stage: filed in late 2023, the Markman process has not begun, fact discovery is not advanced, and the trial is scheduled for late 2025. This timeline provides ample opportunity for a Final Written Decision (FWD) to issue well before trial. Furthermore, Petitioner argued that this IPR petition challenges numerous claims not asserted in the district court litigation, meaning the IPR is a more efficient vehicle for resolving the patentability of the challenged claims.
6. Relief Requested
- Petitioner requests institution of an inter partes review 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 Patent 7,949,785 as unpatentable.
Analysis metadata