US 7647422

I'll search for this specific patent number across USPTO and CAFC sources.

The CAFC docket search returned no results. Let me verify that negative finding and check for any litigation/assignment activity.

Let me confirm the negative CAFC finding with additional targeted searches.

Summary — US Patent No. 7,647,422

Search coverage note: I ran targeted web searches for the specific string 7647422 / 7,647,422 combined with USPTO and CAFC-2026 terms. Searches for CAFC 2026 docket activity returned zero relevant hits (some searches returned empty results; others returned unrelated 2026 federal-court material). I flag that a keyword web search is not a substitute for the official Federal Circuit docket (CM-ECF / PACER) or the USPTO Patent Center, so this negative finding is not authoritative. No other patent number was substituted; the results below all correspond to ID 7647422.

Bibliographic data (per patent front page / Google Patents)

Identifiers reproduced literally: the OCR front page renders the first inventor's name as "Indepreet Singh," while Google Patents transcribes it "Inderpreet Singh." I have not auto-corrected either rendering.

Assignment chain (as recorded)

Enterasys Networks, Inc. → Wells Fargo Trust Corp. (security interest, 2010) → release (2013) → Extreme Networks, Inc. (2015) → Silicon Valley Bank (security interest, 2017) / release → RPX Corporation (assignment recorded Nov. 10, 2017) → Jefferies Finance LLC security interest (2018) → released (2020) → Barings Finance LLC collateral agent (2020).

Abstract (verbatim)

"An approach to rapid failover of a communication path between computers that are linked by redundant virtual links in a virtual private network (VPN) features detection of communication link and device failures through an active monitoring approach and re-routing of communication through a redundant link of the VPN when a failure is detected."

Plain-language overview

The invention in one sentence: keep more than one VPN tunnel/gateway path alive at all times, actively "heartbeat" the primary path, and — when a heartbeat fails — switch the client's traffic onto the backup gateway fast enough that the client's TCP transport session does not time out (the spec cites ~10 s TCP timeouts and sub-10 s re-routing).

Independent Claim 1 (method, plain language): A method of giving a client remote access to a server over a data network, comprising:

1. Maintaining multiple communication paths between each client system and the server, each path going through one of several gateway devices sitting between the data network and the server — and, critically, each path is kept up as an active transport-layer session (i.e., the redundant path is live, not merely configured);
2. for a given client, the paths go through different gateways;
3. Routing the client's traffic over the first path/first gateway;
4. Monitoring communications associated with that first gateway; and
5. Re-routing the traffic to a second path/second gateway before a transport-layer timeout occurs if there's a communication failure associated with the first gateway.

Key limiting concepts: "active transport layer session" (standby is not merely cold/administrative), the "monitoring" step, and the "before a transport layer timeout" timing constraint.

Independent Claim 30 (system, plain language): The apparatus counterpart — a communication system comprising a plurality of gateway devices, each programmed to: maintain a communication path between each client and the server; route traffic client→server over the first path via the first gateway; monitor communications associated with the first gateway; and re-route the traffic over the second path via an active transport layer session through the second gateway before a transport layer timeout if there's a failure associated with the first gateway.

Dependent claims (2–29) add: geographically distributed gateways linked by a trusted network; separate virtual links/tunnels per client-gateway pair (PPTP, L2TP, IPSec, with PPP-over-tunnel per claims 8–10); addressing via distinct gateway network addresses (claims 11–12); monitoring variants — polling/ICMP echo to server-side devices, monitoring the data network or its Point of Presence, monitoring the client system, and heartbeat messages using ICMP echo requests or LCP echo requests (claims 13–23); and re-routing mechanics — terminating the first gateway's paths and updating routing data propagated to clients, routers, and host computers (claims 24–29).

Discrepancy worth flagging (claim text version)

The claim set captured at the pre-grant publication (US 2003/0088698 A1, e.g., the Justia-hosted page for that publication) shows claim 1 without: (a) the "wherein each path is maintained as an active transport layer session" clause, (b) the "monitoring communications associated with the first gateway device" step, and (c) the "before a transport layer timeout" clause. Those three elements do appear in the granted claim text in the authoritative full text I was provided. This indicates the claims were amended during prosecution; the granted claim 1 is materially narrower than the published application claim 1. Any infringement/validity analysis must use the granted text.

Litigation / docket posture

• CAFC 2026 dockets: No appeal or other Federal Circuit activity involving 7,647,422 was found in any of my searches. Treat as unverified negative, not as affirmative proof of no activity.
• District court: The Enterasys-related litigation surfaced (e.g., Enterasys Networks, Inc. v. Extreme Networks Inc., D. Mass. No. 1:05-cv-12235; the Wisconsin action, W.D. Wis. No. 07-C-0229-C) concerns other patents (e.g., 6,104,700; 6,678,248; 6,859,438; 5,251,205; 6,128,665; 6,147,995). Because 7,647,422 did not issue until Jan. 12, 2010, it could not have been asserted in the 2005 and 2007 filings. I found no evidence that 7,647,422 itself was ever asserted in litigation.
• Patent has lapsed: the "Expired – Fee Related" status and the listed 2025-04-22 adjusted expiration mean the patent is no longer in force as of today (2026-04-26). Note that 2025-04-22 is consistent with the Aug. 16, 2002 filing date + 20 years + the 980-day §154(b) term adjustment.

Remaining uncertainty

• The exact priority date is stated as 2001-11-06 on the front page/Google Patents, but one third-party aggregator page (unifiedpatents.com) displayed 2001-11-05 for this ID. I cannot reconcile that one-day difference from the sources retrieved; the front page controls.
• I could not pull a live USPTO Patent Center or Patent Trial and Appeal Board record directly, so maintenance-fee lapse dates, any post-grant proceedings, and any 2026 docket entries should be confirmed against the official sources.

Sources: Google Patents full text (patents.google.com/patent/US7647422B2/en), patent front-page PDF (patentimages.storage.googleapis.com … US7647422.pdf), uspto.report/patent/grant/7647422, patents.justia.com/patent/20030088698, litigation.rpxcorp.com case page for the 2005 D. Mass. action, and Extreme Networks SEC shareholder filing describing the Enterasys/Extreme litigations.

I'll search for litigation involving US patent 7647422. Let me start with multiple sources.

Let me search more specific litigation databases and the patent portal directly.

Let me check the Unified Patents litigation database and other docket sources directly.

Litigation Search Results: US Patent 7,647,422

Bottom line: I found no record of any litigation (or PTAB/post-grant proceeding) involving U.S. Patent No. 7,647,422.

I searched for the specific patent number across litigation-oriented sources (Unified Patents portal, CourtListener/RECAP, general patent-docket web results, and news/periodical references). Every hit for the literal string "7647422" fell into one of four non-litigation categories:

1. Patent-profile / citation pages — e.g., Google Patents, Justia, Golden wiki, and the Unified Patents patent profile for US-7647422-B2 (which lists Assignee "RPX Corp," title "VPN Failure Recovery"). These confirm the patent's existence and ownership but contain no case data.
2. Unrelated cases using "7647422" as a citation or a coincidental number — e.g., a Westlaw citation "2020 WL 7647422" (Gunn v. McNeil, S.D.N.Y.), a Brazilian notary register entry "7647422," and a nonprecedential CAFC Rule 36 judgment that does not involve this patent.
3. Related-family citations only — the patent appears in patent "cited by"/citing lists (60 citing patents, 143 family-citing documents) for other vendors' VPN/failover patents. Citations in patent specifications are prior-art references, not evidence of litigation (a caveat worth stressing, since many of the citing documents are Cisco, Citrix, Juniper, etc.).
4. Enterasys/Extreme corporate litigation that is unrelated to this patent — the only Enterasys/Extreme Networks litigation surfaced was a 2001–2012 IPO securities class action (In re Extreme Networks IPO Securities Litigation, No. 01-6143 (SAS) (S.D.N.Y.)) and an Enterasys v. Extreme/Foundry suit from 2005. Neither involves the '422 patent, and neither should be confused with a '422 assertion.

The litigation-relevant facts I can confirm from the patent record

• Current/known assignees (per assignment chain): Enterasys Networks, Inc. → Extreme Networks, Inc. → RPX Corporation (assignment recorded 2017-11-10). A "patent profile" page at the Unified Patents portal also lists RPX Corp as assignee.
• Legal status: Expired – Fee Related; adjusted expiration recorded 2025-04-22. A lapsed/expired patent can still be asserted for past damages within the limitations period, so expiration alone does not preclude litigation — but I found none.
• Priority/filing: priority date 2001-11-06 (provisional 60/332,839); application 10/222,531 filed 2002-08-16; granted 2010-01-12.

Important caveat / disclosed limitation on my search

I could not complete a live query against the Unified Patents litigation caselist, PACER, or Docket Alarm directly — my tool calls hit a step limit before those confirmatory lookups returned. The searches that did run (CourtListener/RECAP, general web litigation indexes, and patent-portal pages) produced zero matches tying case numbers, plaintiffs, defendants, or courts to this patent. Accordingly, I cannot rule out that a recently filed or narrowly reported case exists; I simply found no evidence of one.

What I would check to close this out authoritatively

• Unified Patents Portal – Litigation Caselist: https://portal.unifiedpatents.com/litigation/caselist (filter by patent 7,647,422)
• PACER / CourtListener RECAP docket search on the patent number
• USPTO Patent Assignment & PTAB (to confirm no IPR/PGR/CBM naming the patent)
• RPX's own litigation/patent-monetization disclosures, since RPX is the current assignee

If you'd like, I can re-run the caselist and PACER-specific lookups in a fresh session to exhaustively confirm the negative finding. At present, the accurate statement is: no known litigation involving US 7,647,422.

I'll start by verifying the structured data against live sources, then check for any PTAB or Federal Circuit activity.

PTAB proceedings overview

Total AIA trial proceedings on US 7,647,422: 0. The structured "PTAB proceedings on file" block — sourced from the USPTO Open Data Portal — returns no IPR, PGR, or CBM proceeding for this patent, and my independent web searches likewise surfaced no petition, institution decision, Final Written Decision, or Federal Circuit appeal docket tied to 7,647,422. Because there is nothing to invalidate-or-sustain, there is no "claims canceled" / "claims sustained" split to report: all 30 claims are UNTESTED at the PTAB. The bottom-line posture for a defendant is therefore not "the patent is hardened by surviving IPRs" and not "the key claims are dead" — it is that the IPR lever has never been pulled on this patent, and the more consequential fact may be that the patent has lapsed for failure to pay maintenance fees (see below).

I want to be explicit about the limits of this conclusion: I cannot prove a negative from a search engine, and a very recently filed petition may not yet be indexed by ODP. But the default stated in the task — "no PTAB activity on file" — is what the structured data says and what my searches corroborate.

Proceeding search audit (no proceeding to report)

There is no {PROCEEDING_NUMBER} to populate because no qualifying proceeding exists. What I checked:

Cited forward/citing references in the Google Patents record (e.g., the long "Cited By" and "Families Citing" lists, including the many Cisco service-chaining patents) are citation relationships, not litigation or PTAB proceedings — I did not treat them as activity, and they should not be read as such.

Strategic summary

Claim status. All 30 claims of 7,647,422 — independent claims 1 and 30 plus dependents 2–29 — are UNTESTED before the PTAB. No claim has been canceled, and none has been confirmed in an AIA trial. If a demand letter from the current owner (RPX Corporation per the assignment record) or a downstream assignee asserts these claims, there is no prior PTAB Final Written Decision to point to as cancellation, and equally no PTAB affirmance that the owner can brandish. The validity record is a blank slate.

Estoppel landscape. Section 315(e)(2) estoppel is not triggered for anyone, because § 315(e)(2) estoppel attaches only after a Final Written Decision in an IPR the defendant (or its privies/real parties in interest) participated in. With no FWD on this patent, no defendant is estopped, and no prior-art ground has been "used up." Any defendant is free to raise § 102/§ 103 grounds over patents and printed publications in an IPR, and free to run parallel invalidity theories in district court, subject only to ordinary IPR-estoppel rules that would arise if that defendant itself later obtains an FWD. Practically: the full prior-art space remains available to everyone.

Pattern signals. Two things stand out and both cut in the defendant's favor relative to a typical "troll" posture:

• The patent is expired for failure to pay maintenance fees (adjusted expiration 2025-04-22, per Google Patents). An expired patent cannot be infringed prospectively; infringement liability would be confined to conduct occurring before expiration, subject to the 35 U.S.C. § 286 six-year damages lookback. A lapsed patent is also a strong discretionary-denial fact pattern at the PTAB under current Fintiv/discretionary practice — though more importantly, nobody needs to file at all if the only realistic exposure is a stale damages window.
• The last recorded owner is RPX Corporation, a defensive patent aggregator, not a classic assertion entity. That is a meaningful signal: RPX's model is generally to acquire patents to neutralize them (or license them broadly), not to litigate them aggressively. There is no publicly visible pattern of repeated IPRs against this patent by any single petitioner, no patent-owner appeal history at the Federal Circuit, and no indication that a defensive aggregator like Unified Patents ever challenged it — consistent with a patent that simply was never a high-value assertion target.

Caveat on why the IPR well is dry. Well-asserted patents eventually attract IPRs; this one apparently was not asserted in a way that drew them. That can mean (a) it was never asserted, (b) it was asserted only against parties that settled, or (c) the patent's age/expiry made it an unattractive IPR target. I could not confirm any infringement litigation involving this patent from the sources I reviewed, so I am not asserting one exists — I simply don't have high-confidence evidence either way.

Recommended next steps

1. If you have received a demand or been sued on 7,647,422: the absence of PTAB activity means there is no FWD to cite and no cancellation to rely on. Your first-line defense is the expiry/lapse status — confirm the maintenance-fee lapse in USPTO Patent Center and the adjusted expiration date of 2025-04-22 (Google Patents record). If the patent indeed lapsed for non-payment of maintenance fees, prospective infringement is off the table, and the damages window closes at expiration subject to § 286.

2. Verify the chain of title before responding to anyone. The recorded reassignments run Enterasys → Extreme Networks → RPX Corporation (2017-11-10). Confirm whether RPX still holds it or has assigned it onward; a demand from a party not presently holding title is a threshold standing problem worth raising early.

3. If an IPR is still worth filing (e.g., you face a live pre-expiration damages claim on a large revenue base): the full prior-art space is open — no § 315(e)(2) estoppel, no prior petitioner's grounds to work around. Note, however, that the PTAB's current discretionary-denial regime is hostile to old, expired patents, so expect a significant risk of discretionary denial under the "settled expectations"/age and Fintiv-type factors. Budget for that risk.

4. Before spending, re-run the ODP check at PTAB E2E. I could not access live PTAB E2E or the ODP endpoint directly in this session. Re-verify at PTAB E2E and via the ODP API, because a recently filed petition may not yet be reflected in the structured block or in web indexes. If a petition has appeared since my check, treat it as the controlling proceeding and re-assess estoppel and claim status around it.

5. Do not cite nonexistent proceedings. There is no IPR number, panel, institution decision, FWD, settlement, or CAFC docket for this patent that I can substantiate. Anything purporting to be one for 7,647,422 should be independently verified before it is used in a filing.

Open items I could not resolve with high confidence

• Whether any district court infringement litigation involving 7,647,422 ever existed (I found none, but absence of evidence here is not proof of absence).
• The exact maintenance-fee lapse basis and whether any petition to revive was filed — confirm in Patent Center.
• Whether RPX has since reassigned the patent to an assertion entity; the ODP/assignment record I reviewed shows RPX as most recent assignee (2017-11-10).

Patent reference: US7647422B2 — VPN failure recovery.

I'll research the assignment records before writing up. Let me run several searches in parallel.

Let me dig for the actual reel/frame records and any litigation/assertion history.

US 7,647,422 B2 — "VPN Failure Recovery" — Ownership & NPE Analysis

Data-quality caveat up front. The authoritative patent text supplied to me reproduces the Google Patents "Legal Events" panel, which lists dates, conveyance types, assignors, and assignees but does not expose reel/frame numbers, execution-vs-recordation dates separately, or the correspondent of record for most entries. My attempts to reach the USPTO Patent Assignment Search data (assignmentcenter.uspto.gov / assignment.uspto.gov) and Plainsite assignment abstracts for this patent did not return usable records within this session. I therefore cannot supply the reel/frame and correspondent fields the task requires, and I have not invented them. Every place below where those fields are unknown is marked [NOT RETRIEVED]. Dates and conveyance types are drawn from the Google Patents legal-events data embedded in the authoritative text and should be re-verified against the Assignment Center.

Inventors

Pattern observations

• Only two named inventors — no unusual internal-inventor fragmentation.
• Partial departure signal: a "Benjamin E. McCann (Acton, MA)" — matching this inventor's residence city — appears as a co-inventor on an adaptive-services-networking application filed 2004-01-13 and assigned to F5 Networks, Inc. (issued as US 7,877,511). That is ~17 months after this patent's 2002-08-16 filing, i.e. outside the 12‑month window but still a prompt post-filing exit from Enterasys. Treat as a moderate, not textbook, "inventor departure" flag. I have not confirmed that the F5 inventor and this inventor are the same natural person by any unique identifier.
• No evidence that both inventors left within 12 months, so the classic "pre‑fire‑sale inventor exodus" pattern is not established.
• Prosecution attorney of record (front page): Holland & Knight LLP; Brian J. Colandreo, Esq. This is the prosecution attorney, not the assignment correspondent — do not conflate the two. It is offered only as a lead for a correspondent check.

Original assignee

• Entity on the issued patent: Enterasys Networks, Inc., Andover, Massachusetts (front page, field 73).
• Primary line of business: Enterprise networking equipment — LAN switches (Matrix/RoamAbout-era lines), routing, network policy/security and remote-access VPN gateways. The claimed architecture (multiple geographically separate gateways, client-side access devices, IPSec/GRE/PPP tunnels, multi‑gateway failover) tracks Enterasys' remote-access VPN appliance line (the "Aurorean" VPN family). I have not verified claim-by-claim product coverage; treat the product mapping as plausible, not proven.
• Did they ship a product embodying the claims? Enterasys was an operating networking vendor that sold VPN/remote-access gateways and IPSec tunnel endpoints through the relevant period — yes, an operating-company commercializer of the general technology (product-level claim mapping unverified).
• Corporate lineage / current status: formed in 2000 as a spin-off of Cabletron Systems (the residual Cabletron later became Riverstone Networks). Enterasys was subsequently taken private by an investor group (Gores/Tennenbaum-era transaction, ~2006), then acquired by Siemens Enterprise Communications (~2008), and finally acquired by Extreme Networks, Inc. (closed 2013-10-31). Enterasys no longer exists as an independent entity; the brand was retired. No bankruptcy proceeding is known to me for Enterasys — so the sale of assets was M&A, not a Chapter 7/11 liquidation.
• Patent status today: Google Patents legal status = Expired – Fee Related, adjusted expiration 2025-04-22 (20 years from the 2002-08-16 filing plus the 980-day PTA credited on the face of the patent). As of today (2026-10-01) the patent is expired, which materially narrows any assertion value.

Assignment timeline

Dates/conveyance types below are from the Google Patents legal-events data in the authoritative text. Reel/frame and correspondent were not obtainable and are marked [NOT RETRIEVED]. The only reel/frame that appears anywhere in the record is Reel/Frame 025339/0875, and it appears inside the title of the 2013 release document as the instrument being released — so it identifies the Wells Fargo security interest, not the release itself.

1. 2002-08-16 / recorded 2002-08-16 — Reel [NOT RETRIEVED]

   • Conveyance: Assignment
   • Assignor: Inderpreet Singh; Benjamin McCann (individually)
   • Assignee: Enterasys Networks, Inc.
   • Correspondent: [NOT RETRIEVED] (prosecution firm of record: Holland & Knight LLP)
   • Context: inventor-to-employer assignment, filed with/near the 2002-08-16 application — the standard origin link.

2. 2010-11-10 / recorded 2010-11-10 — Reel/Frame 025339/0875 (per the release title at item 3)

   • Conveyance: Grant of Security Interest (patent mortgage)
   • Assignor: Enterasys Networks, Inc.
   • Assignee: Wells Fargo Trust Corporation Limited, as Security Agent
   • Correspondent: [NOT RETRIEVED]
   • Context: securitization — collateral grant under a secured credit facility (Wells Fargo as security agent, i.e. a lender group).

3. 2013-11-01 / recorded 2013-11-01 — Reel [NOT RETRIEVED] (releases instrument at Reel/Frame 025339/0875)

   • Conveyance: Termination and Release of Security Interest in Patents
   • Assignor: Wells Fargo Trust Corporation Limited
   • Assignee: Enterasys Networks Inc.
   • Correspondent: [NOT RETRIEVED]
   • Context: release of security interest — timing (Nov 2013) coincides with the Extreme Networks acquisition of Enterasys (closed 2013-10-31), consistent with payoff/clearing of the lender lien at closing.

4. 2015-08-26 / recorded 2015-08-26 — Reel [NOT RETRIEVED]

   • Conveyance: Assignment
   • Assignor: Enterasys Networks, Inc.
   • Assignee: Extreme Networks, Inc.
   • Correspondent: [NOT RETRIEVED]
   • Context: M&A chain‑of‑title cleanup — recorded ~22 months after the 2013 acquisition closed; a confirmatory/corrective assignment of rights acquired in the merger, not a new bargain.

5. 2015-09-03 / recorded 2015-09-03 — Reel [NOT RETRIEVED]

   • Conveyance: Assignment
   • Assignor: Enterasys Networks, Inc.
   • Assignee: Extreme Networks, Inc.
   • Correspondent: [NOT RETRIEVED]
   • Context: second confirmatory/corrective recording eight days after item 4 — the paired recording pattern typical of a corrective assignment (correcting a prior reel/frame or an omitted property). Not an independent transfer.

6. 2017-07-14 / recorded 2017-07-14 — Reel [NOT RETRIEVED]

   • Conveyance: Security Agreement (grant of security interest, "Second Amended and Restated Patent and Trademark Security Agreement")
   • Assignor: Extreme Networks, Inc.
   • Assignee: Silicon Valley Bank
   • Correspondent: [NOT RETRIEVED]
   • Context: securitization — operating-company credit facility; confirms Extreme was operating and borrowing, not liquidating, when it later sold the patent.

7. 2017-09-29 / recorded 2017-09-29 — Reel [NOT RETRIEVED]

   • Conveyance: Release by Secured Party
   • Assignor: Silicon Valley Bank
   • Assignee: Extreme Networks, Inc.
   • Correspondent: [NOT RETRIEVED]
   • Context: lien release tied to refinancing of the SVB facility.

8. 2017-11-10 / recorded 2017-11-10 — Reel [NOT RETRIEVED]

   • Conveyance: Assignment of Interest
   • Assignor: Extreme Networks, Inc.
   • Assignee: RPX Corporation
   • Correspondent: [NOT RETRIEVED]
   • Context: transfer to an aggregator — the key link. Extreme, a solvent public company, sold the patent (with others) to RPX, the well-known defensive patent aggregator.

9. 2018-05-01 / recorded 2018-05-01 — Reel [NOT RETRIEVED]

   • Conveyance: Release by Secured Party
   • Assignor: Silicon Valley Bank
   • Assignee: Extreme Networks, Inc.
   • Correspondent: [NOT RETRIEVED]
   • Context: second lien release (completes the SVB unwind post-dating the RPX sale).

10. 2018-06-29 / recorded 2018-06-29 — Reel [NOT RETRIEVED]

    • Conveyance: Security Interest
    • Assignor: RPX Corporation
    • Assignee: Jefferies Finance LLC
    • Correspondent: [NOT RETRIEVED]
    • Context: securitization of the RPX portfolio — RPX pledges its patent assets to a lender; evidence the patents are being used as collateral, not asserted.

11. 2020-10-23 / recorded 2020-10-23 — Reel [NOT RETRIEVED]

    • Conveyance: Patent Security Agreement
    • Assignor: RPX Clearinghouse LLC; RPX Corporation
    • Assignee: Barings Finance LLC, as Collateral Agent
    • Correspondent: [NOT RETRIEVED]
    • Context: refinancing/securitization — the appearance of RPX Clearinghouse LLC alongside RPX Corporation is worth flagging: it suggests the patent family sits in, or is jointly pledged by, an RPX Clearinghouse holding entity. I could not confirm that title to this patent was assigned into RPX Clearinghouse LLC; Google Patents still lists the current assignee as RPX Corporation.

12. 2020-10-26 / recorded 2020-10-26 — Reel [NOT RETRIEVED]

    • Conveyance: Release of Security Interest
    • Assignor: Jefferies Finance LLC
    • Assignee: RPX Corporation
    • Correspondent: [NOT RETRIEVED]
    • Context: lien release on refinancing (replaced by the Barings facility at item 11).

Materials-missing note. The Assignment Center likely also holds the recorded duplicate/corrective records and any prosecution-era name records for this application that Google's event panel collapses. Because I could not open the Assignment Center records, the reel/frame and correspondent columns — the single most probative fields for the "same lawyer, rotating LLCs" test — remain unfilled and should be pulled manually.

Timeline diagram

timeline
    title Ownership of US 7647422
    2002 : Filed by Enterasys Networks
         : Inventors assign rights to Enterasys
    2010 : Wells Fargo security interest recorded
    2013 : Wells Fargo releases security interest
    2015 : Enterasys assigns to Extreme Networks
         : Second confirming assignment recorded
    2017 : Silicon Valley Bank security interest
         : SVB releases security interest
         : Extreme Networks assigns to RPX
    2018 : RPX pledges to Jefferies Finance
    2020 : RPX pledges assets to Barings
         : Jefferies releases security interest

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT (on available evidence). The chain runs Enterasys → Extreme Networks → RPX Corporation. Every transferor is a named operating company, and the terminal assignee is an established, publicly known aggregator with real operations — not a single-purpose "IP Holdings/Licensing/Ventures" LLC. No registered-agent-service address, no single-member Delaware/Texas LLC appears in the recorded chain (items 4, 5, 8 — reel/frame [NOT RETRIEVED]). Caveat: the possible RPX Clearinghouse LLC appearance at item 11 (2020-10-23) is a holding-entity hint, but there is no recorded assignment of this patent into RPX Clearinghouse LLC that I could verify, so I decline to call it a shell transfer.

2. Known asserter in the chain — NOT PRESENT as to any listed asserter; UNRESOLVED as to RPX. None of Acacia, Marathon, Intellectual Ventures, IPNav, Wi‑LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation, or Spangenberg entities appear. The chain terminates at RPX Corporation (item 8, 2017-11-10), which is conventionally classified as a defensive aggregator, not a high-frequency plaintiff. Note the nuance: RPX does sit on some analysts' "NPE-adjacent" lists because of its RPX Clearinghouse syndicated-licensing activity, and its portfolio entities have occasionally appeared in fee-shifting/standing disputes. I found no evidence of an RPX infringement suit on this patent.

3. Repeat correspondent across the chain — UNCLEAR / NOT RETRIEVABLE. This is the one signal I most wanted to test and could not: the correspondent-of-record fields on all twelve links are [NOT RETRIEVED]. Without them I cannot say whether one attorney/firm filed every RPX recording. For completeness, the prosecution firm of record is Holland & Knight LLP (Brian J. Colandreo) — a firm that does substantial operating-company patent work, so a single appearance there would not be a finding anyway. Recommend manual pull of the correspondent field for the 2015, 2017, 2018 and 2020 recordings.

4. Cascading transfers — NOT PRESENT. The chain spans 2002 → 2010 → 2013 → 2015 → 2017 → 2018 → 2020, i.e. ~18 years. There is no run of consecutive title transfers through chained LLCs inside 24 months. The two 2015 recordings (items 4–5) are 8 days apart but identical transferor→transferee pairs — a confirmatory double-recording, not a cascade. The 2017 and 2018 RPX/Jefferies entries are security interests, which do not move title.

5. Pre-litigation transfer — NOT PRESENT / UNVERIFIED. I identified no infringement suit naming US 7,647,422, and therefore no transfer sitting within 6 months of a first suit. (A 2017-11-10 transfer-to-aggregator with a 2018-06-29 pledge does not fit the pre-litigation pattern: the buyer is a defensive aggregator and the patent has since expired 2025-04-22.) If a suit does exist that I did not surface, this call would need revision.

6. Bankruptcy fire-sale — NOT PRESENT. Enterasys was not a bankruptcy seller; it went private (~2006) and was then acquired by Siemens Enterprise Communications (~2008) and by Extreme Networks (closed 2013-10-31). Extreme was a solvent public company (EXTR) granting and releasing SVB security interests (items 6, 7, 9) while operating. The RPX sale (item 8) is a portfolio divestiture, not a §363 sale. No Chapter 7/11 is known to me.

7. Privateering — NOT PRESENT on available evidence. The operating company (Extreme) did transfer to a non-practicing buyer (RPX) at item 8 — structurally the shape of privateering — but the counterparty is the industry's canonical defensive buyer, and I found no evidence RPX asserted this patent against Extreme's competitors on Extreme's behalf, nor any SEC/EFF/Patent Progress reporting of such an arrangement for this patent. On the record available: not present.

8. Defensive aggregator (anti-NPE) — PRESENT (strong). The chain terminates at RPX Corporation by the assignment recorded 2017-11-10 (item 8), and Google Patents still lists RPX Corporation as current assignee. RPX is a named defensive aggregator (RFQ/patent-buying syndicate model). Inverse signal: the patent has been neutralized — it sits in an aggregator's defensive stockpile, is pledged as loan collateral (items 10, 11), and expired 2025-04-22.

Verdict

Defensive / non-asserting.

Justification: the title chain is Enterasys → Extreme Networks → RPX Corporation, with the terminal transfer recorded 2017-11-10 (item 8) and RPX Corporation still the listed current assignee. RPX is a canonical defensive patent aggregator, the subsequent recorded events are loan-collateral pledges and releases (RPX→Jefferies 2018-06-29; RPX/RPX Clearinghouse→Barings 2020-10-23; Jefferies release 2020-10-26) rather than assertions, and I found no infringement action naming this patent. The patent is expired (adjusted expiration 2025-04-22), so the assertion window is closed. The verdict is not "NPE — high confidence" because no shell LLC, no high-frequency plaintiff, and no assertion evidence appears; it is not "Operating-company assertion" because the patent left the operating company (Extreme) eight years ago.

Residual uncertainty (be explicit): two requested fields were not retrievable — reel/frame for links 1, 3–12 and correspondent of record for every link. Signal 3 (repeat correspondent) is therefore unresolved, and signal 5 (pre-litigation transfer) rests on a negative litigation search rather than a confirmed docket. Those gaps do not change the terminal-assignee finding, but they should be closed by a manual Assignment Center pull before this analysis is relied on.

Verify at: USPTO Assignment Center (search "7647422" or application 10/222,531) and the legacy USPTO Patent Assignment Search. Patent text and legal events: https://patents.google.com/patent/US7647422/en.

I'll search for the patent and its cited prior art references.

Let me retrieve the full cited reference list and examine the most relevant prior art.

Let me pull the complete reference list for this patent (U.S. patents, foreign, and other publications).

Prior-Art Analysis — US 7,647,422 B2

1. Confirmation of the target document (USPTO record)

I located the specific patent, and only that number:

Grounding sources: Google Patents https://patents.google.com/patent/US7647422/en ; Justia https://patents.justia.com/patent/[7647422](/patent/7647422) ; USPTO.report https://uspto.report/patent/grant/7647422 ; front-page PDF https://patentimages.storage.googleapis.com/ef/b6/43/af05b03a3cb79f/US7647422.pdf .

The "prior art date" listed by Google Patents is 2001-11-06 (the provisional), so any genuinely anticipatory reference must predate ~Nov. 6, 2001 (or Aug. 16, 2002 for §102(a)/(e) art). This is a critical frame for the analysis below.

2. What counts as "a citation for 7647422" — an important clarification

Two different lists exist, and they must not be confused:

• "References Cited" (the '(56)' column) — this is prior art of record. The patent carries an unusually large IDS: Google Patents reports 189 citations; the front page lists dozens of U.S. patent documents (running from US 4,627,052 in 1986 through the 6,1xx,xxx series in 2000), one foreign document (EP 1 154 624 A2, 11/2001), and a long "Other Publications" list.
• "Cited By" (60) and "Families Citing (143)" — these are NOT prior art. They are later patents that cite '422 (e.g., Cisco's US 7,689,722 "Methods and apparatus for VPN fault tolerance," Unisys US 8,341,722 "Load balancing and failover of gateway devices," the US 2009/0144817 A1 "VPN high availability" application). They are follow-on art and cannot anticipate '422.

Data-quality caveat (flagged, not auto-corrected). The '(56)' list as aggregated by third-party sites is internally suspicious: it includes large blocks of IEEE 802.1/VLAN material (1990–96), fiber-optic/token-ring patents, and a cluster of location/geolocation references (Cyberlocator; "DNS LOC"; IETF geopriv; "Geolocation Service Allows Web Sites to Identify Users' Geographic Locations," May 2001; Newbury Networks, Sep. 2001; SnapTrack white paper, Nov. 2001). Several of those location items are dated mid-2002 — after the '422 priority date — so they cannot be §102 art against claim 1 of '422 and almost certainly entered the record via a related Enterasys/Cabletron location-services application. I could not retrieve the complete, de-duplicated 189-entry list within my tool budget; the list below is therefore representative rather than exhaustive, and I expressly do not vouch for each entry's applicability.

3. Most relevant prior art, with citation, date, description, and claim mapping

I have grouped the cited art by what it can actually bear on. "Anticipates §102?" is answered only where a single reference could plausibly disclose all elements of an independent claim; for anything less, I say so.

Group A — Redundant-gateway / routing-protocol art (closest to claim 1 and claim 30)

Group B — Monitoring / polling / liveness art (relevant to claims 13–23, "heartbeats")

Group C — Tunneling / network-layer routing art (relevant to claims 5–12)

Group D — Packet-switching / VLAN / bridging fundamentals (background; at most tangential)

US 4,823,338 (Chan, 1989); US 5,394,402 (Ross, 1995); US 5,485,455 (Dobbins, 1996); US 5,530,703 (3Com, 1996); US 4,734,907 (Turner, 1988); US 4,939,726 (Flammer, 1990); US 5,136,580 (Videlock, 1992); plus the IEEE 802.1 MAC-Bridge and LAN-emulation documents. These disclose virtual-network/forwarding mechanics but no VPN failure recovery; no §102 relevance to claims 1 or 30.

Group E — Location/geolocation cluster (US 5,243,652; US 5,519,760; US 5,640,452; US 5,659,617; US 5,727,057; US 5,757,916; US 5,790,074; and the mid-2002 NPL items)

These are directed to locating/authenticating network users and, as noted, several postdate the priority date. No §102 relevance, and I flag them as likely cross-family contamination of the citation list.

Group F — Foreign

• EP 1 154 624 A2, published Nov. 2001 — the sole foreign document on the face. I could not verify its subject matter from the results returned, so I will not characterize it further rather than speculate.

4. §102 bottom line

On the verified record, no cited reference anticipates any claim of US 7,647,422 under 35 U.S.C. §102. The reason is structural, and it is the same reason the patent issued in 2010: the independent claims require a specific combination that the cited art does not teach in a single reference —

• claim 1: maintaining multiple paths, "each path … maintained as an active transport layer session," associated with different gateways, plus monitoring, plus re-routing "before a transport layer timeout"; and
• claim 30: the system counterpart requiring re-routing "via an active transport layer session … before a transport layer timeout."

The cited U.S. patents are overwhelmingly pre-1996 VLAN/bridging/routing/location art; the cited NPL is routing-protocol and VPN-product documentation. None discloses (a) redundant VPN tunnels to two or more geographically distinct gateways held as simultaneously active transport-layer sessions, together with (b) active heartbeat monitoring, and (c) failover timed to beat the transport-layer timeout. At most, VRRP + Cisco VPN documentation + a polling reference could be combined under §103 — which is precisely why the "before a transport layer timeout" and "active transport layer session" language appears in the granted claims (the file history shows a 980-day §154(b) adjustment, consistent with a contested prosecution).

Most useful prior art for a validity challenge (in descending order): VRRP/RFC 2338; Cisco 7100 Series VPN Router / Cisco VPN Solutions (2001); US 5,517,620 (NEC) and US 5,095,480 (Fenner) for route-update propagation; US 5,781,726 (3Com) for session polling.

5. Limits of this analysis (stated explicitly)

1. I retrieved the front page and partial '(56)' list, not the complete de-duplicated 189-entry reference set; the entries in Groups A–E are those I could name with dates from the record, and I have not verified the full text of each.
2. Descriptions in the table are derived from the titles/dates as they appear in the patent's own citation list (Google Patents/Justia/USPTO.report), not from independent reading of each reference's specification.
3. Where a claim mapping would have required reference content I did not obtain (e.g., EP 1 154 624 A2), I declined to guess.
4. Consistent with the previously generated litigation section, I again found no IPR/PGR/CBM or district-court proceeding naming this patent in the sources returned — so there is no PTAB or court invalidity record to leverage here.

If you want, I can run a follow-up pass to (a) pull the complete '(56)' list from the granted-PDF front page and (b) verify the disclosure of the four "most useful" references against their own specifications, which would let me convert the §103 observations above into element-by-element §102/§103 charts.

I'll ground the prior-art analysis by verifying the reference lists attached to this patent and the substantive content of the most probative references.

The patent's own "References Cited" list is now partly recoverable. Let me pin down the dates and content of the most probative references (including the Utimaco/SafeGuard VPN cluster art and the Cisco/VRRP material the examiner cited).

Obviousness Analysis — U.S. Patent No. 7,647,422 (35 U.S.C. § 103)

Note on the effective legal framework. Application 10/222,531 was filed Aug. 16, 2002 — before the Mar. 16, 2013 effective date of the AIA — so pre-AIA § 103 governs, as construed in Graham v. John Deere and KSR Int'l v. Teleflex (2007). Prior art therefore reaches acts/prints before the Nov. 6, 2001 priority date (§ 102(a)/(b)) and U.S. filings before that date (§ 102(e)). As flagged in the earlier sections, the attack must be aimed at the granted claim text, which is materially narrower than the published claim 1 (the "active transport layer session," "monitoring," and "before a transport layer timeout" elements were added during prosecution). Those three added elements are the crux, and this analysis concentrates there.

Note on the prior-art record actually used. The "Prior Art" material on this page is of two very different qualities, and conflating them is a common analytical error:

The record I worked from is partial — both the Google Patents page and the front-page PDF returned truncated reference lists in my retrieval, so the analysis below covers the recoverable subset of the 189 citations plus the OTHER PUBLICATIONS category. Also reproduced as-is: the spec's OCR renders "OSPP" for OSPF and "Router Interchange Protocol" for RIP; and the of-record entry "IPSec, Cisco Systems, Inc., (1988)" carries a date that is anomalous for the IPSec standard (developed mid-1990s). I make no correction to any of these.

1. The claim elements that must be met

Claim 1 requires, in substance:

• (A) maintaining plural communication paths client↔server, each through one of plural gateways between the data network and the server, each path maintained as an active transport-layer session;
• (B) for each client, the paths go through different gateways;
• (C) routing traffic over the first path/first gateway;
• (D) monitoring communications associated with the first gateway; and
• (E) re-routing to the second path before a transport-layer timeout on a communication failure associated with the first gateway.

Claim 30 is the system counterpart (plural gateway devices "programmed to" perform A–E "via an active transport layer session").

Dependents 2–29 add, essentially, well-known implementation details: geographically distributed gateways over a trusted network (2); separate virtual links per client-gateway pair (3); client + access device architecture (4); tunnels and specific tunnel types — PPTP (6), L2TP (7), IPSec (8); PPP over the tunnel (9–10); distinct gateway network addresses (11–12); monitoring server-side devices by polling/ICMP echo (13–15); monitoring the data network or its POP (16–18); monitoring devices accessible over the data network, including the client (19–20); heartbeat messages using ICMP echo or LCP echo (21–23); terminating the first gateway's paths (24); and updating routing data propagated to clients, routers and hosts (25–29).

2. Element-by-element mapping of the most probative references

Additional art a challenger could add (not of record in the '422, flagged as such): WO 01/95564 A3, "High Availability Networking with Virtual IP Address Failover" (published 13 Dec. 2001; U.S. priority 09/588,130 filed June 2, 2000) — a backup interface plus an application-layer failover mechanism that monitors the primary connection and reconfigures the backup on failure. Because its international filing precedes Nov. 6, 2001, it is a candidate § 102(e) reference (published PCT designating the U.S., in English); verify the international filing date before relying on it.

3. Combinations that would render claims 1 and 30 obvious

Combination 1 (primary): RFC 2338 (VRRP) + IPSec (RFC 2401 et seq.) + OSPF/RIP (RFC 2328 / RFC 1058) + ICMP Echo (RFC 792) or LCP Echo (RFC 1661)

• A: a VRRP group supplies plural gateways with plural logical paths; each gateway terminates an IPSec tunnel to the access device → plural virtual links/tunnels on different gateways (B); the standby tunnel is a live, established session (see motivation below).
• C: VRRP Master forwards for the virtual address.
• D: VRRP advertisements plus ICMP echo to server-side devices and LCP echo over the tunnel = "monitoring communications associated with the first gateway."
• E: Master_Down (~3 s default) < any plausible transport timeout → re-routing "before a transport layer timeout."

Every dependent claim 2–29 is separately met: claims 6–10 by PPTP/L2TP/IPSec/PPP RFCs; 11–12 by VRRP's distinct physical addresses for the gateway group members; 13–15, 21–23 by RFC 792 / RFC 1661; 16–18 by monitoring the uplink/POP (a plain extension of the monitoring step); 24–29 by OSPF/RIP route withdrawal and route propagation to routers and hosts.

Combination 2: US 7,000,121 (Utimaco) + RFC 2338 VRRP (or HSRP RFC 2281) + ICMP/LCP echo + OSPF

• Utimaco supplies the VPN-gateway-cluster and failure-of-gateway-detection-after-establishment problem verbatim in the VPN context (its spec states: "if gateway 2 fails, no further communication … is possible, unless there is a second gateway … and the policy of the client machine is reconfigured…"), and solves it with re-authentication, round-robin gateway selection, and cached session keys.
• VRRP/HSRP supplies the active monitoring element (D) and the timing element (E); OSPF supplies the routing update.

Combination 3: Of-record Cisco VPN literature (Cisco 7100 Series VPN Router; Cisco VPN Solutions (2001)) + RFC 2338 + Cisco OSPF Overview (1999) + ICMP

• The of-record Cisco materials establish redundant/gateway-terminated IPSec VPN deployments; VRRP supplies the redundancy protocol and heartbeat; the OSPF overview supplies the route update. This combination is attractive because all three items are already of record (a § 103 rejection may rest on the applicant's own cited references).

Combination 4 (optional, secondary): US 5,442,633 (Perkins) + RFC 2338 + IPSec + OSPF

• Uses cited-of-record U.S. patents for the tunneling/network-layer routing-to-remote-host element, combined with VRRP for redundancy and OSPF for reconvergence.

4. Why a PHOSITA would have been motivated to combine

1. Same field, same problem. Every reference is in packet networking/fault tolerance; the asserted problem (a single gateway or uplink failing, killing sessions) is common to all of them. KSR makes "familiar elements according to known methods" obvious where the result is predictable.
2. The patent's own background supplies the motivation. The specification admits: (i) services "are often configured to have more than one gateway … to provide high availability"; (ii) fault tolerance in a VPN "is to link computers using redundant virtual links" with "active communication sessions … re-routed" via OSPF/RIP; (iii) routers already detect an inaccessible neighbor from non-response and propagate unreachability; (iv) TCP sessions have a ~10 s timeout, so it is desirable to reroute in time. These are the invention's own stated premises — powerful § 103 evidence that the problem and its general solution were known.
3. Finite number of identified, predictable solutions. The art had already enumerated exactly three mechanisms for detecting loss and re-routing — routing-protocol reconvergence (OSPF/RIP), a dedicated gateway-redundancy protocol (VRRP/HSRP), and application/tunnel-level heartbeats (ICMP/LCP echo). Selecting among them is the KSR "obvious to try" situation.
4. Design incentive and routine optimization. Given a known ~10 s session-timeout ceiling, tuning a 2–4 s heartbeat period and a 2–4 unanswered-heartbeat threshold (the very numbers in the '422 spec) is ordinary engineering optimization, not invention.
5. Reasonable expectation of success. VRRP/HSRP failover times were documented as seconds; ICMP echo and LCP echo are trivial to implement; OSPF/RIP withdrawal is standard. Nothing teaches away.

5. Where a challenger could still fail (and what to prove)

1. "Each path is maintained as an active transport layer session" (claim 1) / "via an active transport layer session" (claim 30). This is the strongest potential saving limitation. Much contemporary redundancy art used cold/stateless standby (renegotiate the IPSec SA only after failover), which would not disclose a standby end-to-end transport session that is already up. A challenger must show either (a) a pre-established standby tunnel (as the '422 spec itself contemplates, with both tunnels up from the outset), or (b) stateful session mirroring. Utimaco's cached session keys help but do not squarely disclose a live transport session on the standby path; US 7,689,722-style stateful failover could not be used because it post-dates the priority date.
2. "Before a transport layer timeout." If the chosen primary reference's failover is slower than the applicable session timeout (e.g., a stateless rekeying design), the combination must be shown to produce sub-timeout rerouting. VRRP's ~3 s default supports this; a "stateless" variant may not.
3. Claim 2's trusted-network/geographic-distribution limitation is the kind of deployment limitation that may support a narrower construction, though it is arguably an obvious architecture choice.
4. The dependent claims are the easiest targets. Claims 13–23 (monitoring targets and ICMP/LCP echo heartbeats) and 24–29 (route withdrawal/propagation) map almost one-to-one onto RFC 792, RFC 1661, and RFC 2328/1058.

6. Honest limits of this analysis

• I could not retrieve the complete 189-reference list or the full front page; my mapping covers the recoverable subset plus the OTHER PUBLICATIONS category. A complete PTO-892 review is required for a filing-grade opinion.
• I could not verify the effective filing/priority dates of US 7,000,121 B2 / EP 1 175 061 A2. If the Utimaco U.S. filing post-dates Nov. 6, 2001, it is not § 102(e) art and Combination 2 collapses. Confirm via USPTO Patent Center.
• EP 1154624 (11/2001), cited of record as a foreign patent document, is dated essentially at the priority date; its content and its § 102(e)/§ 102(a) status are unverified.
• The Cisco product literature (Cisco 7100 Series VPN Router, Cisco VPN Solutions (2001)) is of record but its content is unverified; to be § 102(a)/(b) art it must qualify as a publicly accessible printed publication, which requires an evidentiary showing I have not made.
• The safest, fully dated § 102(b) art here is the standards material: RFC 792 (1981), RFC 1058 (1988), RFC 1122 (1989), RFC 1661 (1994), RFC 2281 (1998), RFC 2328 (1998), RFC 2338 (1998), RFC 2401–2411/2451 (1998), RFC 2637 (1999), RFC 2661 (1999) — all comfortably before the priority date.
• Do not build any § 103 combination on the "Cited By" or "Families Citing" lists (e.g., US 7,689,722; US 8,341,722; US 9,009,327; the Cisco service-chaining family). They post-date the priority date.

Bottom line: Claims 1 and 30 are substantially vulnerable to a § 103 attack built on VRRP/HSRP + IPSec + OSPF/RIP + ICMP/LCP-echo heartbeats, reinforced by the Utimaco gateway-cluster art, and buttressed by the specification's own admissions that redundant gateways, redundant virtual links, dynamic-routing failover, and a ~10 s transport timeout were all known. The two limitations most likely to survive, absent better art, are the requirement that the standby path be an already-active transport-layer session and the sub-timeout rerouting requirement — both of which must be attacked with art showing pre-established/stateful standby sessions that pre-date the Nov. 6, 2001 priority date. Note that the patent is expired (adjusted expiration 2025-04-22) and, per the earlier sections, no litigation involving it was found, so a § 103 challenge today is largely academic unless past damages are at issue.

Sources (verified in this session): Google Patents full text and front-page PDF (patentimages.storage.googleapis.com/ef/b6/43/af05b03a3cb79f/US7647422.pdf); uspto.report/patent/grant/7647422 (OTHER PUBLICATIONS listing); patents.justia.com/patent/7647422 and patents.google.com/patent/US20030088698 (specification); patents.google.com/patent/US7000121 and patents.justia.com/patent/7000121 (Utimaco SafeGuard VPN cluster art); patentimages.storage.googleapis.com/1b/da/14/42dda0066c90d6/WO2001095564A3.pdf (virtual-IP failover art, not of record).