US 7721084

I'll search for authoritative information on this patent number, including any 2026 litigation activity.

Let me run a couple more targeted checks for litigation/docket activity and confirm the assignee chain.

Summary — US Patent No. 7,721,084

Sourcing note: The figures below are taken from the authoritative patent text you supplied (Google Patents, US7721084B2), cross-checked against USPTO/PubChem, FreePatentsOnline, and Unified Patents listings returned by search. Where sources diverge I flag it.

Bibliographic data

Assignment chain (as listed): Stonesoft Corp. → Websense Finland Oy (2016-02-25) → Forcepoint Finland Oy (2016-04-15) → Forcepoint LLC (2017-08-01) → (security interest to Raytheon, 2018; released 2021) → Forcepoint Federal Holdings LLC (2021-05-10) → Forcepoint LLC (2021-05-18) → UBS/ Credit Suisse collateral entries → release 2025-04-02 naming Bitglass, LLC and Forcepoint, LLC. Current assignee is listed as Everfox Holdings LLC.

Minor variance flagged: A Unified Patents portal entry lists the priority date as 2001-11-28 and assignee Everfox Holdings LLC. The authoritative patent text states priority 2001-11-29. I treat 2001-11-29 as correct, but note the discrepancy rather than silently normalizing it. The EP counterpart is EP 1 317 115 A3 (applicant Stonesoft Corporation; same three inventors).

Abstract

A method of filtering a tunneled data packet (outer header + outer payload, the payload containing an inner data packet with an inner header and inner payload), in which the value of at least one outer header field is matched to a first rule and the action defined in the first rule is taken. Taking that action includes detecting the inner data packet within the tunneled packet, matching the value of at least one field of the inner data packet to a second rule, and taking the action defined in the second rule.

Independent claims in plain language

There are six independent claims: 1, 10, 11, 12, 14 and 16. Claims 2–9 depend from claim 1; claim 13 depends from 12; claim 15 depends from 14.

Claim 1 — Method (core invention).

• Provide a first rule set that filters tunneled packets on outer headers only.
• Provide multiple second rule sets that filter inner data packets only (distinct from the first set).
• Receive a tunneled packet at an intermediate device located along the tunnel — not at either tunnel endpoint — the packet being sent from the first endpoint to the second endpoint, with the outer header added at the first endpoint and to be removed at the second.
• Search only the first set for a rule whose header value matches an outer header field.
• Only if such a first rule is found, execute its action — which filters the inner packet without involving the endpoints and without interrupting the tunnel — by: (a) detecting the inner packet; (b) selecting only the one second rule set that corresponds to the matched first rule; (c) searching only that selected set (explicitly not the unselected sets) for a matching inner-field rule; and (d) executing the matched second rule's action, filtering the inner packet separately from the outer-header filtering.
• If no matching first rule is found, forward the packet toward the second endpoint without searching any second rule set and without inner filtering.

Claim 10 — Network gateway (apparatus counterpart of claim 1). A gateway positioned at an intermediate point of the tunnel, apart from both endpoints, comprising mechanisms for: storing the first (outer-header-only) rule set and the plurality of second (inner-only) rule sets; intercepting a tunneled packet; searching the first set for a matching first rule; and — responsive only to finding such a rule — filtering the inner packet without endpoint involvement and without interrupting the tunnel, including detecting the inner packet, selecting the single corresponding second rule set, searching only that set, and executing the matched second rule. If no first rule matches, the gateway forwards the packet without inner filtering.

Claim 11 — Apparatus / computer-readable storage with software. A storage medium containing software that, when executed, provides the same filtering routine as claim 1, expressed as being performed transparently to the first and second endpoints and without breaking the tunnel, with the same "search only the selected second set" and "forward if no first rule matches" limitations.

Claim 12 — Method with stateful processing (first-packet + connection-state handling). Adds state tracking to the claim-1 architecture:

• If the received packet is the first packet of the tunnel, search only the first rule set.
  • No match → reject the tunnel and discard.
  • Match → allow the tunnel; create an entry in a first connection state table (keyed on outer header field(s), with instructions for filtering the inner packet); detect the inner packet; if it is the first packet of a connection, select the one second rule set corresponding to the matched first rule and search only that set.
    • No match → reject the connection, discard the packet.
    • Match → allow the connection; create an entry in a second connection state table keyed on inner header field(s); execute the matched second rule's action (inner filtering separate from outer filtering).
• Forward packets that passed filtering from the intermediate device to the second endpoint.
  (Steps in sub-parts a) and b) are drafted as alternatives keyed to whether a match is found.)

Claim 14 — Apparatus (computer-readable storage with software), stateful version. The storage-medium counterpart of claim 12, expressly performed at an intermediate point apart from the endpoints, transparently to the endpoints and without breaking the tunnel, with the dual connection-state tables and forwarding of packets that pass filtering.

Claim 16 — Network gateway (GPRS-specific). A gateway comprising a firewall connectable between a GGSN ("gateway packet radio support node") and an SGSN ("packet radio support node") for filtering tunneled packets sent over a tunnel between those two nodes, without involvement of those nodes and without interrupting the tunnel, the firewall being located apart from them. It carries the same architecture: a first outer-header-only rule set, a plurality of inner-only second rule sets, a first search only in the first set, action taken only on a match (detect inner packet → select the one corresponding second set → search only that set → filter the inner packet separately from the outer header), and forwarding of the packets that pass filtering.

Litigation / docket status (as requested)

• No CAFC 2026 docket or opinion involving US 7,721,084 was found. Searches of Federal Circuit 2026 opinion/order and docket material returned unrelated patents and cases (e.g., Nichia v. [appellees], No. 2024-2122, involving US 6,879,040; Spero v. Mercedes-Benz, No. 2025-1306, involving US 11,208,029). None referenced 7,721,084.
• The only docket-corpus hits for "7721084" are as cited prior art, not as an asserted or challenged patent: it appears as a reference in the file histories cited in IPR2021-01152 (Palo Alto Networks v. Centripetal Networks) and in the IPR2018-01443 / IPR2018-01512 / IPR2018-01444 Cisco v. Centripetal file histories (the string "7721084" appears in applicant IDS listings with issue date 2010-05-18, "Salminen et al.").
• Consistent with the record, the patent's legal status is Expired – Lifetime (adjusted expiration 2024-11-26), so it is no longer enforceable; this also makes active 2026 assertion litigation unlikely. I cannot confirm this with certainty — I have no authoritative 2026 docket feed in front of me — so treat "no 2026 CAFC activity" as a negative search result rather than an affirmative finding.

Uncertainty / caveats

• Inventor name spelling varies across sources (Syvänne vs. "Syvaenne" in PubChem), which is a transliteration artifact, not a different person.
• I did not locate an authoritative claim-construction or IPR decision on this patent's own claims. Everything above about the claims is drawn directly from the claim text you supplied, which I treat as authoritative over secondary summaries.

I'll research litigation involving US patent 7721084 across patent litigation databases.

Let me search more targeted litigation databases for this specific patent.

Let me search additional litigation-specific sources to confirm whether this patent was ever asserted.

Summary: US Patent 7,721,084 — Litigation Search Results

Bottom line: I found no evidence of any litigation in which US 7,721,084 ("the '084 patent") was asserted as a patent-in-suit, challenged as a patent-at-issue, or adjudicated before a district court, the PTAB, or the Federal Circuit.

Every appearance of "7721084" that my searches surfaced falls into one of three non-litigation categories, detailed below.

Patent identity (for the record)

• Patent: US 7,721,084 B2, "Firewall for filtering tunneled data packets"
• Inventors: Riku Salminen, Tuomo Syvänne, Mika Jalava
• Application: 10/301,857; priority FI 20012338 (2001‑11‑29); filed 2002‑11‑22; granted 2010‑05‑18
• Original assignee: Stonesoft Corp.
• Ownership chain (per prosecution/assignment records): Stonesoft → Websense Finland Oy (2016) → Forcepoint Finland Oy (2016) → Forcepoint LLC (2017) → Forcepoint Federal Holdings LLC → Forcepoint LLC; listed current assignee Everfox Holdings LLC
• Status: Expired – Lifetime; adjusted expiration 2024‑11‑26

Why the search hits are NOT litigation involving the '084 patent

1. Prior-art citations in other parties' IPRs. The '084 patent appears in the file histories/exhibit lists of several inter partes reviews, but always as a cited reference — never as the challenged patent:

   • [Cisco Systems Inc.](/litigations/by-plaintiff/Cisco%20Systems%20Inc.) v. Centripetal Networks Inc., IPR2018‑01443 / ‑01444 and IPR2018‑01512 (the '084 number shows up in IDS listings in the '205 and '213 file histories).
   • Palo Alto Networks Inc. v. Centripetal Networks Inc., IPR2021‑01152 (the '084 number appears in Exhibit 1002‑3 file-history material for U.S. 10,091,246).

   In each instance the patent being reviewed is a different patent; '7721084 is merely listed among references.

2. Patent-office / catalog database entries. Google Patents, FreePatentsOnline, PubChem's patent record, the Unified Patents patent database page (US‑20030115328‑A1 / US‑7721084), and the Golden wiki page are bibliographic records only — no case data.

3. Unrelated cases surfaced by keyword drift. My searches returned many Forcepoint-related suits (e.g., Webroot, Inc. v. AO Kaspersky Lab, W.D. Tex. No. 6:22‑cv‑00243; Touchpoint Projection Innovations, LLC v. Forcepoint LLC, W.D. Tex. No. 7:24‑cv‑00305; Gatekeeper Solutions Inc. v. Forcepoint, LLC, No. 24‑cv‑601). These litigations involve Forcepoint — the former owner of the '084 patent — but assert entirely different patents (e.g., the '721, '903, '784, '038 patents). None asserts the '084 patent. A number is not common to these cases; the connection is only the corporate party Forcepoint.

Important caveats (please read)

• Diligence limitation: I was not able to directly query PACER, the CAFC docket, or run a complete party-name sweep (e.g., searches for every Stonesoft, Websense, Forcepoint, and Everfox case) before hitting my research limit. My conclusion is therefore "no litigation found," not a verified negative.
• Practical significance: Although the '084 patent covers a broadly relevant subject matter (filtering inner packets of tunnels such as IPsec/GRE/GTP without terminating the tunnel), it appears to have been maintained as a portfolio/prior-art asset rather than a litigation weapon. Its expiration on 2024‑11‑26 further counsels that no active enforcement exists today.
• No case data provided: Because I could not confirm any actual case, I am deliberately not listing plaintiff/defendant/jurisdiction/case-number/filing-date/outcome fields — doing so would risk fabricating case numbers, which I will not do.

Recommended next steps to confirm a definitive negative

If you need a verified "no litigation" record for a freedom-to-operate or due-diligence opinion, I recommend a direct, purpose-built search:

• Unified Patents litigation portal — https://portal.unifiedpatents.com/litigation/caselist (search by patent number)
• RPX Insight — https://insight.rpxcorp.com (search patent number → "Litigation" tab)
• Docket Alarm / CourtListener / Docket Navigator — query "7,721,084" as a text term in complaint and docket text
• USPTO PTAB — search 7721084 at https://ptacts.uspto.gov for any IPR/PGR/CBM
• CAFC — search the patent number across the court's opinions/orders database

If you'd like, I can run those targeted queries and report back per-case details.

I'll verify the canonical "no proceedings" result against web sources before drafting.

Let me check the litigation/assertion history and any PTAB activity under the Stonesoft/Forcepoint owners.

Let me run a few more targeted checks on litigation, reexam, and the expired status.

PTAB / AIA Trial Landscape — US 7,721,084

"Firewall for filtering tunneled data packets" · App. 10/301,857 · Filed 2002-11-22 · Granted 2010-05-18 · Priority 2001-11-29 (FI 20012338) · Inventors Salminen, Syvänne, Jalava · Original assignee Stonesoft Corp. · Current assignee as listed by Google Patents: Everfox Holdings LLC · Status: Expired – Lifetime, adjusted expiration 2024-11-26

Proceedings overview

There are zero AIA trial proceedings on file against US 7,721,084 — 0 active, 0 claims invalidated, 0 claims sustained, 0 settled, 0 institution denials — and web search surfaced no older or unindexed IPR/PGR/CBM petitions either, which means the defensive posture here is not "the patent is hardened by PTAB wins" but rather "every claim 1–16 is untested at the Board, and the patent has already expired," so the live question for a defendant is the residual past-damages exposure and the § 102/§ 103 record a jury (not the PTAB) would see.

Negative search — what I actually checked, and what the "7721084" hits mean

I searched for IPR/PGR/CBM challenge activity and for assertion history. The only web hits tying "7721084" to PTAB dockets are third-party IDS citations — i.e., 7,721,084 cited as prior art in the file histories of Centripetal Networks patents being challenged by Cisco and Palo Alto Networks, not as the challenged patent:

• https://ptabdata.blob.core.windows.net/files/2018/IPR2018-01444/v2_Cisco%20Ex%201002%20file%20history%20205%20patent.pdf — Cisco Systems, Inc. v. Centripetal Networks, Inc., IPR2018-01444, Ex. 1002 (file history of U.S. Pat. 9,137,205), listing "7721084 – 2010-05-18 – Salminen et al." in an IDS.
• https://www.docketalarm.com/cases/PTAB/IPR2018-01512/.../Exhibit-1002-2-Ex_1002_File_History_of_US_Patent_9,565,213.pdf — same pattern in IPR2018-01512.
• https://www.docketalarm.com/cases/PTAB/IPR2021-01152/Palo_Alto_Networks_Inc._v._Centripetal_Networks_Inc/.../Exhibit-1002-3-US10091246_FH_Part_3.pdf — IPR2021-01152, again an IDS citation.

Those are dockets about other patents. Do not let a search-result snippet suggesting otherwise mislead you — none of them is a proceeding on 7,721,084.

I also found no record of district court assertion of 7,721,084 (searches by patent number, by Stonesoft, and by Forcepoint returned nothing). Treat that as an unverified negative, not proof: I could not run an exhaustive PACER/Docket Alarm litigation sweep within this task, and pre-2010 litigation would not necessarily surface in web search.

Proceeding-by-proceeding

None to report. I will not manufacture a proceeding number, panel, or FWD for a proceeding that does not exist. The correct entry for this patent is:

No AIA trial proceeding has ever been instituted against US 7,721,084. Claims 1–16 are UNTESTED at the PTAB.

Strategic summary

Claim-by-claim status. All sixteen claims — the independent method claim 1, its dependents 2–9, the network-gateway claim 10, the CRM/apparatus claim 11, the stateful method claim 12 and dependent 13, the CRM/apparatus claim 14 and dependent 15, and the GPRS-specific network-gateway claim 16 — are UNTESTED. Nothing has been canceled, nothing has been confirmed, nothing has been disclaimed by certificate (none surfaced). There is no narrowing claim set to point at, and correspondingly no PTAB record to use as a roadmap: a defendant gets no free invalidity work product, but also inherits no adverse findings.

Estoppel landscape — it is empty. Because no IPR/PGR was ever instituted, § 315(e)(2) estoppel never attached to anyone on this patent. There is no petitioner, no privy, and no prior ground that is now off the table. Any defendant facing assertion today may raise every § 102/§ 103/§ 112 ground it can develop, in the district court, in an IPR, or both — with one practical caveat: an IPR petition filed now would almost certainly be a dead letter, because the patent's adjusted expiration (2024-11-26) has already passed, the Board's one-year statutory deadline under § 316(a)(11) would run past any possible enforceable term, and the Board routinely denies institution where no meaningful relief is available. Practically, a defendant's invalidity work belongs in the district court or in a summary-judgment posture, not at the PTAB.

Pattern signals. No repeat-petitioner pattern (no petitioner at all). No PTAB appeal history — there is no FWD to have appealed, so no Federal Circuit docket exists. No defensive aggregator (Unified Patents, RPX, etc.) appears in the chain; the ownership chain instead runs through operating companies and their lenders: Stonesoft → Websense Finland Oy (2016-02-25) → Forcepoint Finland Oy (2016-04-15) → Forcepoint LLC (2017-08-01) → Raytheon security interest (2018-02-12, released 2021-01-08) → Credit Suisse collateral agent (2021-01-20) → Forcepoint Federal Holdings LLC (2021-05-10) → Forcepoint LLC (2021-05-18) → release to Bitglass, LLC / Forcepoint, LLC (2025-04-02). Google Patents' listed current assignee is Everfox Holdings LLC (the renamed Forcepoint Federal entity). That chain is a corporate-reorganization and financing story, not an assertion story — consistent with the absence of PTAB activity.

The dominant fact is the calendar, not the Board. The patent is expired as of 2024-11-26 and carries the "Expired – Lifetime" status on Google Patents. Infringement requires an unexpired patent, so there is no prospective liability for conduct, product shipments, or sales after 2024-11-26. What remains is a decaying past-damages window under 35 U.S.C. § 286: for a complaint filed today (2026-09-27), the six-year lookback reaches 2020-09-27, and the recoverable period would be 2020-09-27 to 2024-11-26. That window shrinks every day and closes entirely once six years have run from expiration (i.e., a complaint filed after roughly 2030-11-26 recovers nothing). This is the single most important defensive asset in the file, and it is independent of any invalidity theory.

Recommended next steps

1. Lead with the expiration, not with invalidity. Demand letters on this patent that do not acknowledge the 2024-11-26 expiry are either stale or overreaching. Map any accused conduct on a timeline against 2020-09-27 → 2024-11-26 and quantify the maximum theoretical exposure before doing anything else. Everything after 2024-11-26 is non-actionable as a matter of law.

2. Do not plan on an IPR as your primary vehicle. With no AIA proceedings on file (verified against the ODP structured data and corroborated by web search) and the patent expired, an IPR is unlikely to be instituted to a useful FWD. Preserve invalidity for the district court, where § 282 and Rule 12(c)/summary judgment remain fully available — and where you are free of any estoppel, since § 315(e)(2) never attached to this patent.

3. Build the invalidity record from the file history and the cited art. US 7,721,084 is itself cited as prior art in the Centripetal Networks file histories (Cisco IPR2018-01443 / -01444 and IPR2021-01152 exhibits). That is a ready-made trail to the art of record and to how skilled searchers have characterized this disclosure. The '084 specification is self-limiting in a useful way: it distinguishes the invention from the FIG. 2A/2B prior art (firewall-as-tunnel-endpoint, and firewall-originated tunnels) and its own stated novelty is filtering "in the middle of the tunnel" — see the Summary of the Invention and the FIG. 4/FIG. 5 flow descriptions at https://patents.google.com/patent/US7721084/en. Art that teaches outer-header matching driving a selected inner-header rule set (the core of claim 1) is the target.

4. Watch claim 12 and claim 16 specifically if suit is threatened. Claim 12 is the fully stateful formulation (first connection state table for the tunnel, second for the inner connection) and claim 16 is the GPRS-specific network-gateway claim (GGSN ↔ SGSN firewall). These are the claims a sophisticated plaintiff would assert, and they carry the richest set of limitations to attack — but note they are untested, so you cannot rely on any prior PTAB construction of "inner data packet," "tunnel," or "outer header."

5. Verify the litigation negative before you rely on it. My searches found no assertion history, but I could not run a complete PACER sweep. Before finalizing a clearance or freedom-to-operate position, confirm no co-pending or previously dismissed case names Everfox Holdings LLC, Forcepoint, or Stonesoft as plaintiff on this patent, and confirm whether any terminal disclaimer, reissue, or reexamination certificate exists that would alter the claim set.

Constraint note: I have not stated any proceeding number, judge panel, institution date, FWD disposition, or Federal Circuit docket for this patent, because none exists in the record I could verify. If you have a demand letter or complaint that cites a specific IPR number for 7,721,084, that citation is almost certainly to a different patent or a different Stonesoft family member — flag it and I'll check it against the docket.

I'll research the USPTO assignment record for US 7,721,084, including reel/frame data and correspondents of record.

Let me search for the specific assignment recording data and correspondents.

I hit my search-step limit before retrieving the reel/frame and correspondent fields. Here is the assignment analysis with that gap flagged rather than filled in with invented data.

Ownership & Assignment Analysis — US 7,721,084

Patent: US 7,721,084 B2, "Firewall for filtering tunneled data packets" · App. 10/301,857 · Priority FI 20012338 (2001-11-29) · Filed 2002-11-22 · Granted 2010-05-18 · Status Expired – Lifetime, adjusted expiration 2024-11-26.

Sourcing caveat — read before relying on the timeline below. The chain, assignors, assignees, conveyance types and dates are taken from the assignee legal-events record reproduced on the authoritative Google Patents page you supplied (https://patents.google.com/patent/US7721084/en), which is derived from the USPTO assignment record. I was unable to retrieve the reel/frame numbers or the correspondent-of-record fields from the Assignment Center during this session — my searches for those fields returned no usable results before I reached my step limit. I therefore do not state any reel/frame number or attorney name, because doing so would require fabrication. The reel/frame and correspondent columns must be re-run directly at https://assignmentcenter.uspto.gov/ (search by patent number 7,721,084) or https://assignment.uspto.gov/patent/index.html before this memo is used for diligence. The Assignment Center does hold records for this patent; this is not a "no records" case.

Inventors

Basis for employer: All three are named as assignors to STONESOFT CORPORATION in the 2003-02-11 assignment-of-assignors'-interest recording — the standard employer-assignment pattern for a company filing.

Unusual-pattern check — no adverse pattern found. The classic red flag (all inventors leaving the original assignee within ~12 months of filing, presaging a fire-sale) is not present. To the contrary, all three are prolific Stonesoft filers whose names recur across the Stonesoft portfolio well past 2001 — GoodIP's assignee profile for Stonesoft Corp. lists Syvänne on 18 filings, Jalava on 11, Salminen on 6, spanning the company's 2000–2010s output. That continuity is inconsistent with an inventor-departure/fire-sale narrative. (Caveat: I could not retrieve employment contracts or personnel records; this inference rests on continued co-filing, not on HR documentation.)

Name-spelling note carried over: PubChem renders Syvänne as "SYVAENNE TUOMO" — a transliteration artifact, not a second person.

Original assignee

Stonesoft Corporation (Helsinki, FI; later Stonesoft Oy / "Stonesoft Oy dba Stonesoft Corporation").

• Did it ship a product embodying the claims? Yes. Stonesoft was a pure-play network-security vendor whose flagship line was the StoneGate firewall/VPN product family (appliance + Management Center), a stateful-inspection gateway that inspects rule bases and connection state — i.e., the exact subject matter of claims 1–16. The '084 claims are directed to how such a gateway filters inside tunnels, so the original assignee was using the technology in commerce.
• Primary line of business: Network security software/appliances — firewalls, VPN, IPS/intrusion prevention, and later next-generation firewall with the company's well-known "Advanced Evasion Techniques" research.
• Current status: Acquired. Stonesoft Oyj was taken over by McAfee (Intel Security) in 2013–2014.

⚠️ Ownership divergence I cannot reconcile — flagged, not normalized. Stonesoft's firewall business was absorbed by McAfee, yet this US patent was recorded to Websense Finland Oy in 2016, not to McAfee. I do not have a verified explanation for how the Stonesoft patent family reached Websense/Forcepoint (possible carve-out, separate Stonesoft entity, or a later portfolio sale), and I will not guess. Anyone relying on this chain should pull the underlying assignment instruments to confirm the assignor's exact legal identity and corporate authority.

Assignment timeline

Chronological recordings, as they appear in the assignee legal-events record. Reel/frame and correspondent: NOT RETRIEVED (see sourcing caveat). Dates below are the recording/event dates shown; execution dates were not exposed in the source I had and are therefore omitted rather than assumed.

• Recorded 2003-02-11 — Reel NNNNNN/NNNN (not retrieved)

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Salminen, Riku; Jalava, Mika; Syvänne, Tuomo (individually)
  • Assignee: Stonesoft Corporation
  • Correspondent: Not retrieved. If a single correspondent recurs across this chain it could not be evaluated — flag for follow-up.
  • Context: Initial inventor→employer assignment.

• Recorded 2016-02-25 — Reel NNNNNN/NNNN (not retrieved)

  • Conveyance: Assignment of Interest
  • Assignor: Stonesoft Oy dba Stonesoft Corporation
  • Assignee: Websense Finland Oy
  • Correspondent: Not retrieved.
  • Context: Portfolio transfer out of the Stonesoft entity to Websense — acquisition/carve-out.

• Recorded 2016-04-15 — Reel NNNNNN/NNNN (not retrieved)

  • Conveyance: Change of Name
  • Assignor: Websense Finland Oy
  • Assignee: Forcepoint Finland Oy
  • Correspondent: Not retrieved.
  • Context: Change of name only (Raytheon-era rebrand of Websense to Forcepoint).

• Recorded 2017-08-01 — Reel NNNNNN/NNNN (not retrieved)

  • Conveyance: Assignment of Interest
  • Assignor: Forcepoint Finland Oy
  • Assignee: Forcepoint LLC
  • Correspondent: Not retrieved.
  • Context: Internal reorganization / consolidation into the US parent.

• Recorded 2018-02-12 — Reel NNNNNN/NNNN (not retrieved)

  • Conveyance: Patent Security Agreement Supplement
  • Assignor: Forcepoint LLC
  • Assignee: Raytheon Company
  • Correspondent: Not retrieved.
  • Context: Securitization — grant of a security interest as collateral (not a title transfer).

• Recorded 2021-01-08 — Reel NNNNNN/NNNN (not retrieved)

  • Conveyance: Release of Security Interest in Patents
  • Assignor: Raytheon Company
  • Assignee: Forcepoint LLC
  • Correspondent: Not retrieved.
  • Context: Release of the 2018 security interest.

• Recorded 2021-01-20 — Reel NNNNNN/NNNN (not retrieved)

  • Conveyance: Patent Security Agreement
  • Assignor: Forcepoint LLC; RedOwl Analytics, Inc.
  • Assignee: [Credit Suisse AG, Cayman Islands Branch, as Collateral Agent](/asserters/credit-suisse-cayman-islands-branch-as-collateral-agent)
  • Correspondent: Not retrieved.
  • Context: Securitization/refinancing — new collateral grant to a lender.

• Recorded 2021-05-10 — Reel NNNNNN/NNNN (not retrieved)

  • Conveyance: Change of Name
  • Assignor: Forcepoint LLC
  • Assignee: Forcepoint Federal Holdings LLC
  • Correspondent: Not retrieved.
  • Context: Change of name only (later renamed Everfox Holdings LLC, per the listed current assignee).

• Recorded 2021-05-18 — Reel NNNNNN/NNNN (not retrieved)

  • Conveyance: Assignment of Interest
  • Assignor: Forcepoint Federal Holdings LLC
  • Assignee: Forcepoint LLC
  • Correspondent: Not retrieved.
  • Context: Internal reorganization — reassignment back into the operating Forcepoint entity.

• Recorded 2025-04-02 — Reel NNNNNN/NNNN (not retrieved)

  • Conveyance: Release by Secured Party
  • Assignor: UBS AG, Stamford Branch
  • Assignee: Bitglass, LLC; Forcepoint, LLC
  • Correspondent: Not retrieved.
  • Context: Release of security interest following the 2021-financing restructuring (Bitglass was a Forcepoint-affiliated operating entity).

Timeline diagram

timeline
    title Ownership of US 7721084
    2003 : Inventors assign rights to Stonesoft
    2010 : Patent issued to Stonesoft Corporation
    2013 : Stonesoft acquired by McAfee
    2016 : Assigned to Websense Finland Oy
         : Renamed Forcepoint Finland Oy
    2017 : Assigned to Forcepoint LLC
    2018 : Security interest granted to Raytheon
    2021 : Raytheon interest released
         : Security interest to Credit Suisse
         : Reorg into Forcepoint Federal Holdings
         : Reassigned to Forcepoint LLC
    2025 : Security interest released by UBS

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT.
Every transferee in the chain is an operating entity or a lender: Websense Finland Oy → Forcepoint Finland Oy → Forcepoint LLC → Forcepoint Federal Holdings LLC, plus Raytheon, Credit Suisse and UBS as secured parties only. No assignee carries a licensing/patents/ventures suffix; there is no single-member Delaware/Texas LLC shell; no registered-agent-service address is visible in the record. (No reel/frame was retrieved to test the "shared correspondent address" tell, which is why signal 3 remains open rather than negative.)

2. Known asserter in the chain — NOT PRESENT.
None of the assignees — Stonesoft, Websense Finland Oy, Forcepoint Finland Oy, Forcepoint LLC, Forcepoint Federal Holdings LLC, Raytheon, Credit Suisse AG, UBS AG, Bitglass LLC — appears on the NPE rosters named in the brief (Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation, Spangenberg entities) or on the Unified Patents / RPX high-frequency-plaintiff lists. Control point: no litigation was identified in the earlier sections of this analysis, so there is no plaintiff to map against these directories in the first place.

3. Repeat correspondent across the chain — UNCLEAR (not retrieved).
This is the single most probative tell for a chained-NPE family, and it is exactly the field I could not retrieve. I am marking it unclear, not "not present," and I am not naming any attorney or firm. Follow-up: pull the correspondent for each of the eleven recordings listed above at https://assignmentcenter.uspto.gov/ and check for recurrence.

4. Cascading transfers — NOT PRESENT (as an NPE pattern).
There is a dense recording cluster (2016-02-25, 2016-04-15, 2017-08-01, 2018-02-12, 2021-01-08, 2021-01-20, 2021-05-10, 2021-05-18), and the 2016→2017 span is ~18 months. But these are not chained shells: two are Change of Name recordings (2016-04-15; 2021-05-10), three are security-interest events (2018-02-12; 2021-01-08; 2021-01-20), and the remainder are reorganizations among entities of one corporate family sharing common principals. That is a leveraged operating company restructuring its IP holding structure, not an assertion chain.

5. Pre-litigation transfer — NOT PRESENT.
No assignment falls within 6 months before any infringement suit, because no suit naming this patent was identified. The last title-affecting recording (2025-04-02) is a security-interest release that postdates the 2024-11-26 expiration.

6. Bankruptcy fire-sale — NOT PRESENT.
Stonesoft was acquired (McAfee, 2013–2014) — a sale, not a bankruptcy. The 2018 Raytheon security agreement and the 2021 Credit Suisse security agreement evidence secured financing, not Chapter 7/11 liquidation, and no court-supervised patent sale is in the record. No Kodak/Nortel-style sale proceeding identified.

7. Privateering — NOT PRESENT.
No evidence that an operating company transferred the patent to an NPE that then asserted on its behalf against competitors. Neither the SEC-filing nor Patent Progress/EFF coverage surfaced any such arrangement.

8. Defensive aggregator (anti-NPE) — NOT PRESENT.
The chain does not terminate at RPX, Allied Security Trust, LOT Network, Unified Patents, or Open Invention Network. It terminates in the Forcepoint/Bitglass operating group. The inverse "neutralization" signal is therefore absent.

Verdict

Defensive / non-asserting.

Justification: The complete recorded chain — inventors → Stonesoft Corporation (2003-02-11) → Websense Finland Oy (2016-02-25) → Forcepoint Finland Oy (2016-04-15, name change) → Forcepoint LLC (2017-08-01) → collateral to Raytheon (2018-02-12) → release (2021-01-08) → collateral to Credit Suisse (2021-01-20) → Forcepoint Federal Holdings LLC (2021-05-10, name change) → Forcepoint LLC (2021-05-18) → release to Bitglass/Forcepoint (2025-04-02) — is an unbroken operating-company and secured-lender record, with zero NPE sourcing, zero shell LLCs, zero recognized asserters, and zero identified assertion litigation. Because the chain terminates in operating entities rather than at a recognized defensive aggregator (RPX/AST/LOT/Unified), I am invoking this verdict on its practical meaning — a non-asserting, operating-company-owned asset now expired — and I flag explicitly that the category's literal "terminates at an aggregator" definition is not met; the taxonomy offers no separate "operating-company ownership, no assertion" bucket.

Confidence qualifier: The verdict rests on the assignee/conveyance/date data, which is solid, and not on the reel/frame or correspondent evidence, which I could not retrieve. Signal 3 — the repeat-correspondent tell that most often exposes a coordinated NPE chain — is open, so a full troll-pattern clearance on this patent is not yet complete.

Verify at: https://assignmentcenter.uspto.gov/ (search patent 7,721,084) · https://assignment.uspto.gov/patent/index.html · litigation/assertion cross-checks at https://portal.unifiedpatents.com/litigation/caselist and https://insight.rpxcorp.com

Open items for a complete record

1. Pull all eleven reel/frame numbers and the correspondent for each from the Assignment Center; test for a recurring attorney/firm across links (signal 3).
2. Confirm the assignor's legal identity on the 2016-02-25 recording ("Stonesoft Oy dba Stonesoft Corporation") and reconcile why the chain runs to Websense/Forcepoint rather than to McAfee, which acquired Stonesoft in 2013–2014.
3. Confirm whether any reissue, reexamination certificate, or terminal disclaimer sits in the file (none surfaced here), which would alter the claim set.
4. Carry forward the priority-date discrepancy flagged in the earlier sections (Unified Patents lists 2001-11-28 / filing 2002-11-21 vs. authoritative 2001-11-29 / 2002-11-22) — immaterial to ownership but should be reconciled in any formal opinion.

I'll research the prior-art citations for US 7,721,084 as they appear in the USPTO record.

The search results didn't surface the front-page reference list directly. Let me target the patent's own citation record and its PDF front page.

I found a citation list from PubChem. Let me confirm the exact front-page "(56) References Cited" list from the patent PDF and the FPO record.

Scope note and sourcing

I searched specifically for US 7,721,084 (no variants, no auto-correction). Two important process caveats up front:

1. I could not retrieve the verbatim USPTO front-page "(56) References Cited" list for 7,721,084 within my available search steps (the USPTO Patent Center / PatFT full-text "References Cited" view did not render in my results). What follows is assembled from two authoritative secondary records that reproduce that data:

• PubChem/NCBI patent record for US-7721084-B2 — lists the document's citations (10 patent documents + 2 non-patent items). https://pubchem.ncbi.nlm.nih.gov/patent/US-7721084-B2
• EPO search report for the EP counterpart, EP 1 317 115 A3 (Stonesoft; same three inventors) — reproduces the examiner-cited art with relevance categories. https://patentimages.storage.googleapis.com/c3/47/bb/422ed23ad6aac0/EP1317115A3.pdf

1. Because the application was filed 2002-11-22 with a 2001-11-29 priority, the pre-AIA 35 U.S.C. §§ 102/103 framework governs. Relevant subsections are § 102(a) (known/used/published before invention), § 102(b) (publication more than one year before filing), and § 102(e) (earlier-filed US applications/patents). This matters for the dates below.

Discrepancy flagged (cross-sections): Note the PubChem citation list includes US 2003/0115328 A1 — which is this patent's own pre-grant publication. That is almost certainly a data artifact (family/self reference), not a genuine prior-art citation. I flag it rather than silently dropping it.

Prior-art references associated with US 7,721,084

A. Patent documents appearing in the citation list

(The trailing "[SEA]"/"[APP]" tags in the PubChem list appear to be that database's source labels — probably "search/examiner" vs. "applicant." I have not verified their meaning, so I do not rely on them.)

B. Non-patent literature

§ 102 claim-mapping analysis

Threshold point: All of the above were considered by the examiner/applicant and the patent still issued (2010-05-18) with all 16 claims. In the EP counterpart search report, the three most relevant items (US 6,178,505; US 5,898,784; Montenegro RFC 2356) were all tagged category "A" — "general state of the art, not considered particularly relevant." So on the face of the record, none of these references is an anticipating reference under § 102; they are at most § 103 combination material, and the examiner did not treat them as even that. I am flagging this because the honest answer to "which claims does X anticipate" is: as the record stands, none.

That said, mapping the references against the claim limitations (per the claim construction in the prior summary section):

Bottom line

• Most relevant prior art of record: US 6,178,505 B1 (Schneider et al., 2001-01-23) and US 5,898,784 A (Kirby, 1999-04-27) for the firewall-filtering claims, and Montenegro RFC 2356 (June 1998) for the Mobile-IP/tunnel-traversal aspects. All three were rated "A" (background) by the EPO examiner — i.e., considered but not deemed anticipatory or even rendering obvious.
• No § 102 anticipation is supportable from this record: the references were cited and the claims issued over them.
• US 2003/0115328 A1 in the citation list is the patent's own pre-grant publication — a data artifact, not prior art.
• Braun et al. (Oct. 14, 2002) postdates the priority/filing dates and is not § 102 prior art as cited — worth verifying against an earlier version.
• Caution / honesty flag: I could not verify the titles, inventors, or exact dates of US 5,444,782, US 5,602,920, US 6,738,909, US 7,139,792, US 2002/0038419, US 2002/0068584, and US 2002/0163920 from the sources I retrieved, and I am not going to fabricate those details. To finalize this analysis an analyst should pull the authoritative front-page (56) list directly from USPTO Patent Center for US 7,721,084, which would also confirm the complete citation set and the applicant-vs-examiner distinction.

I'll research the prior art cited on this patent's face and in its family before building the § 103 analysis.

I have the face-of-patent and EP-search-report prior art. Let me verify the key references I intend to rely on.

Obviousness Analysis — U.S. Patent No. 7,721,084 under 35 U.S.C. § 103

Scope note. Building on the claim summary in the prior sections, this memo assesses § 103 validity claim-by-claim using the art identified in the Prior Art portions of the Google Patents record for US 7,721,084 (prior-art keywords: data packet, filtering, tunnel, matching, tunneled), the search-report citations on the EP counterpart EP 1 317 115 A3, and the citation list on the PubChem record for US-7721084-B2. I have flagged every reference characteristic I could not independently verify this session and have not normalized any patent numbers or dates.

1. Analytical framework

The independent claims are 1, 10, 11, 12, 14, and 16. The analysis proceeds under the KSR framework (550 U.S. 398 (2007)), using the MPEP 2143 rationales: (a) combining prior-art elements by known methods to yield predictable results; (b) simple substitution of a known element; (c) use of a known technique to improve a similar device in the same way; (d) applying a known technique to a known device ready for improvement; and (e) "obvious to try" where the prior art identifies a finite number of identified, predictable solutions. A POSITA here is a network-security engineer with ~2–3 years' experience in firewall/packet-filter design plus familiarity with IP tunneling standards (GRE, IPsec, Mobile IP, GTP).

Threshold observation that drives much of the analysis: the '084 specification's own BACKGROUND admits a large body of the claimed environment as prior art — stateful firewalls with connection-state tables, rule bases with allow/deny/continue/jump actions, source/destination/port/service matching, IPsec and PPTP/L2TP tunneling, Mobile IP with home-address/care-of-address encapsulation, IPv6 Home Address and Routing Extension Headers, GPRS/GTP tunneling between SGSN and GGSN, and GRE tunnels. These admissions are § 103-relevant because they establish the knowledge base of the POSITA and eliminate any argument that the elements were unknown.

2. The prior art of record

Critical, verifiable fact about the EP search report. All three principal references (Schneider '505, Kirby '784, Montenegro RFC 2356) were categorized "A" — i.e., background art, not "X" (novelty-destroying) or "Y" (inventive-step-defeating). The EP examiner therefore did not treat them as rendering the claims unpatentable. Separately, the EP 1 317 115 B1 specification characterizes Schneider '505 itself as describing "a method of applying filtering rules to inner headers of messages after decription [sic — decryption] and restoration of the original messages." That is the applicant's own admissions-grade characterization of the closest art, and it maps almost directly onto independent claim 1's inner-packet filtering step.

3. Grounds of rejection

Ground A — Claim 1 (and claims 2, 3, 5–8) obvious over Schneider '505 in view of RFC 2356 (optionally with RFC 2401 and GRE RFC 2784)

Motivation. Schneider and RFC 2356 are in the same field (security gateways filtering IP traffic) and address the same problem the '084 BACKGROUND itself names — firewalls historically could filter only at the tunnel level because inner traffic was encrypted or unintelligible. RFC 2356 exists precisely because firewalls obstruct Mobile IP tunnels and operators wanted to admit legitimate tunneled traffic while screening it. A POSITA seeking to admit sanctioned inner traffic within an already-allowed tunnel — the GRE "backdoor" concern the '084 itself raises in its worked example — would predictably (i) match the outer header first (cheap, known), then (ii) reuse the existing rule engine on the inner header after locating it by a protocol-specific offset/module. Reusing a rule engine a second time on a decapsulated header is the "known technique to improve a similar device in the same way" rationale.

Ground B — Claims 4, 12, 13, 15 (dual connection-state tables, first-packet logic, forwarding) obvious over Schneider '505 + RFC 2356 + Shwed '726 / admitted stateful-firewall art

Claims 4 and 12–15 add: a first state table keyed on the outer header (tunnel state, carrying inner-filtering instructions) and a second table keyed on the inner header (connection state); first-packet-vs-subsequent-packet branching; and forwarding of packets that pass filtering.

• Stateful inspection with connection tables, first-packet rule lookup, and subsequent-packet table lookup is admitted prior art in the '084 BACKGROUND (and corroborated by Shwed '726).
• The '084 BACKGROUND itself articulates the problem the dual-table structure solves: where a firewall stores the combination of outer and inner header characteristics, a tunnel change inevitably fails the connection. Separating the two identifiers into independently matchable keys is the straightforward, predictable fix once inner filtering is adopted; MPEP 2143 rationale (d) applies ("known device ready for improvement").
• Instructions in the tunnel-state entry pointing to rules/a connection table to match the inner packet (§"jump" mechanism) is again the admitted "jump"/subrule technique.

Ground C — Claim 9 (IPv6 Extension Header as the "inner header") obvious over RFC 2460 + the Mobile IPv6 / Mobile IP art already discussed in the '084 BACKGROUND

Claim 9 recites that the packet is IPv6 and the "inner header" is an IPv6 Extension Header. The '084 BACKGROUND describes Mobile IPv6 Home Address and Routing Extension Headers as known mechanisms for carrying the static home address alongside the care-of address. Treating the Extension Header + payload as the "inner data packet" and the base IPv6 header as the "outer header" is a definitional, not inventive, step once the two-level filtering model of Ground A is adopted.

Ground D — Claim 16 (firewall between GGSN and SGSN) obvious over GTP/GPRS standards + Schneider '505 + RFC 2356

Claim 16's only structural particularity is placing the two-level firewall between a GGSN and an SGSN. The '084's own Fig. 3B/3D discussion concedes GTP tunnels between SGSN and GGSN as prior art, and inserting a security gateway into an operator's Gn/Gi path to inspect GTP-U payloads was a known deployment (the '084's Fig. 3B even shows firewall 305 and firewall 321 in exactly those positions). The GGSN/SGSN naming is a locus-of-implementation choice, not a technical contribution.

Grounds E/F — Claims 10, 11, 14 (apparatus/CRM counterparts)

Claims 10, 11, and 14 are the apparatus and computer-readable-medium recitations of the same limitations established under Grounds A and B. They rise or fall with claim 1 / claim 12 respectively.

4. Anticipated patent-owner rebuttals and my assessment of them

1. "The art does not teach non-endpoint, mid-tunnel interception." Weakest point for the owner: RFC 2356's whole purpose is a firewall that is not the IPsec/Mobile-IP endpoint, and Schneider's "first access filter in the path performs the access check" teaches a series of in-path filtering devices.
2. "The art decapsulates at an endpoint (Schneider/Fig. 2B)." Genuinely the strongest argument. Schneider's restoration of original messages is naturally done at an endpoint. The owner would argue the art does not fairly suggest locating the inner-packet filter at a transit node. RFC 2356 and the FR 2A/2B/3A discussion cut against this, but not decisively.
3. "No art teaches selecting only one second rule set and skipping the unselected sets." This is the limitation most likely added during prosecution (the "without searching among the other unselected ones" and "forwarding … without searching any of said plurality of second sets" language is unusual and reads as prosecution-driven narrowing — I state this as an inference; I do not have the US file wrapper in front of me.) Countervailing point for the challenger: the "jump" action the '084 admits as prior art does exactly this — it continues examination at a specified rule, skipping intervening rules.
4. Non-obviousness signal in the record: the EP examiner rated all three closest references category "A" and EP 1 317 115 B1 granted. That is affirmative evidence that at least one examiner, seeing Schneider + Kirby + RFC 2356 together, did not consider the claims obvious. A US § 103 ground would need to supply a motivation and a teaching of the selection architecture that the EPO search report did not develop.

5. Confidence, contradictions, and caveats

• Verified this session: US 6,178,505 B1 title/date/abstract and its EP "A" categorization; US 5,898,784 A date and EP "A" categorization; RFC 2356 author/date/EP "A" categorization; the EP 1 317 115 B1 characterization of Schneider '505 (inner-header filtering after restoration).
• Not independently verified: titles and specific teachings of US 5,444,782 A and US 5,602,920 A (PubChem citation list only); the exact content of Kirby '784 beyond its EP citation. Any ground built on these should await full-text confirmation.
• Do not use: Braun et al., "Secure Mobile IP Communication" (2002-10-14) — it post-dates the 2001-11-29 priority date and is unavailable as § 102/§ 103 prior art for this patent.
• Contradiction carried forward from the earlier sections: the Unified Patents portal lists priority 2001-11-28 and filing 2002-11-21, while the authoritative patent text states priority 2001-11-29 and filing 2002-11-22. Either date leaves Braun (Oct. 2002) outside the prior-art window, so the discrepancy does not change the analysis, but it is flagged rather than normalized.
• Practical relevance: the patent is Expired – Lifetime (adjusted expiration 2024-11-26), so this analysis is directed at portfolio/defensive value and historical claim strength, not at an extant infringement action.

Bottom line. A prima facie § 103 case exists against claims 1–16, and its center of gravity is Schneider '505 in view of RFC 2356 (Mobile IP firewall traversal), with stateful-firewall art (admitted; Shwed '726 corroborating) supplying the dual state-table limitations of claims 4 and 12–15 and IPv6/GTP standards supplying claims 9 and 16. The theory's weakest link is proving that the art suggests relocating the inner-packet filter from a tunnel endpoint to an in-path transit node while preserving the tunnel — the single limitation the reference set supports indirectly (RFC 2356, Schneider's in-path filter chain) rather than expressly. The EPO's "A" categorization of all three principal references is meaningful counter-evidence that should be weighed before relying on this ground.