US 7610621

I'll run targeted searches for this specific patent number across USPTO and litigation sources.

Now let me check litigation/docket sources, including CAFC 2026 activity.

US 7,610,621 B2 — Analyst Summary

Search scope note: I queried for the literal string "7610621" / "7,610,621" against Google Patents, USPTO-adjacent databases (uspto.report, PatentCenter/assignment data as surfaced), Unified Patents portal, PTAB/PTAB-related document repositories, and Federal Circuit / CourtListener docket material. I did not find any CAFC 2026 docket entry naming this patent, and no district-court case naming it directly. I did find that the patent's family carries a litigation flag (see Uncertainty section).

1. Bibliographic data (from the authoritative patent text)

Ownership chain (per Google Patents reassignment records): Individual (2005) → Rocksteady Technologies, LLC (2011-01-27) → RPX Corporation (2012-08-13) → security interests to Jefferies Finance LLC (2018-06-29) and Barings Finance LLC (2020-10-23), with releases (2020-10-26; 2024-05-31) → Netskope, Inc. (2024-07-05).

Family / continuations: US 12/579,566 → US 8,032,933 B2 ("Dynamically adaptive network firewalls…", filed 2009-10-15) and US 13/092,488 → US 8,397,282 B2 (filed 2011-04-22), both claiming the same 2004-03-10 priority.

2. Abstract (verbatim)

"One embodiment of the present invention creates a model of the traffic through a network firewall and uses that model to dynamically manipulate the network firewall based on human intervention or based on the automatic invocations of processes and protocols that implement firewall policy. Another embodiment of the invention creates a model of the physical and virtual network interfaces that a firewall system controls and presents abstracted entities representing both the interface abstractions and the processing nodes (network segments or network client devices) to and through which network traffic flows."

3. Plain-language overview of the independent claims (20 claims total)

The patent has three independent claims — claim 1 (method), claim 10 (computer program product), and claim 16 (system) — which are substantively parallel. All three require the same three-part rule-tree architecture; claim 1 is the only one that expressly recites the receiving/conditioning/accepting-or-dropping steps as method acts.

Claim 1 — Method for controlling data flow through a firewall

1. Build a model of the firewall. The model defines (a) nodes, (b) connections between nodes, and (c) a set of firewall rules that can be applied to nodes, to connections, or both. Each node is both a source and a destination for packets (not merely one or the other).
2. The rules must form a tree graph with three sub-trees:
   • an arriving sub-tree — rule chains that condition packets (e.g., mark, de-NAT, de-MASQUERADE, redirect) but are not permitted to accept or drop them;
   • a matrix sub-tree — rule chains that accept or drop packets but do not modify them; and
   • an extensible sub-tree — rule chains that give the rule set dynamic extensibility.
3. Deploy the firewall on machine(s) connected to the network segments where the nodes live.
4. Receive a packet at an arriving node, condition it using the arriving sub-tree chains associated with that node.
5. Accept or drop the packet using the matrix sub-tree chains associated with the arriving node, with an inter-node connection, or with a combination of the two.

Commercial gist: an operator describes desired behavior in terms of abstract nodes and connections; the system expresses that as a structured rule tree in which modification-style rules and permit/deny-style rules are segregated into different sub-trees.

Claim 10 — Computer program product

Same architecture and same functional requirements, but claimed as a computer-readable storage medium storing executable instructions: establish the model (nodes / connections / rules, nodes as simultaneous source-and-destination, rules as a tree graph with arriving, matrix, and extensible sub-trees), and implement the firewall on machine(s) at the network segments — such that when a packet arrives at a node it is conditioned per the arriving sub-tree rules and accepted/dropped per the matrix sub-tree rules associated with the node, the inter-node connection, or both.

Claim 16 — System

Same architecture claimed as an apparatus: at least one processor plus a computer-readable storage medium accessible by the processor storing instructions that perform the identical establishing/implementing/conditioning/accepting-or-dropping functions.

Key dependent-claim coverage

• Node composition (claims 2, 11): nodes comprise a firewall-defined service and/or device.
• Departing sub-tree (claims 3, 12): rules may further include a sub-tree for post-processing packets at their destination node(s) — notably, this is not required by any independent claim.
• Behaviors attach to the right layer (claims 4, 5, 17, 18): arriving-sub-tree rules implement node behaviors; matrix-sub-tree rules associated with an inter-node connection implement connection behaviors.
• Live reconfiguration (claims 6–9, 13, 14, 19): reconfiguring the firewall while it is executing, by extending, pruning, or modifying serialized rule sequences (claim 8 = inserting rules; claim 9 = deleting rules).
• Node-object semantics (claims 15, 20): device = source/sink of traffic mapped to a physical interface or virtual device; service = node- or connection-specific behavior; and a "network operating environment change" expressly includes moving devices/services from one node to another.

4. Uncertainty and data-integrity flags

1. Litigation status is not confirmed for this specific patent. The Google Patents record for family ID 34922296 displays a "First worldwide family litigation filed" flag linking to a Darts-ip family report. That establishes that some member of the family has been litigated, but the flag is attached to the family, not to US 7,610,621 individually, and I was unable to retrieve the Darts-ip record to identify the case. Treat "7610621 has been litigated" as unverified.

2. No CAFC 2026 docket activity found for 7,610,621. Searches of Federal Circuit / docket-aggregator material returned no appeal naming this patent. I cannot rule out an unindexed or very recent filing; I found none in the sources searched.

3. The current owner's active assertion campaign does not appear to include 7,610,621. In Netskope, Inc. v. Fortinet, Inc., No. 4:25-cv-02360-HSG (N.D. Cal.), the asserted Netskope patents are identified as U.S. Patent Nos. 8,356,336; 8,543,710; 8,117,639; 8,224,983; 8,327,426; 7,593,936; 8,397,282; 8,661,153; and 8,635,697 — 7,610,621 is not on that list. (Related sibling patents from the same 2004-03-10 family, e.g., 8,397,282 and the '983/'639 family, are involved, and parallel PTAB proceedings exist, e.g., IPR2026-00042 / IPR2026-00031 / IPR2026-00474 between Fortinet and Netskope.) I found no IPR, PGR, or district-court assertion naming 7,610,621 itself.

4. Claim-set discrepancy across sources — flagged, not auto-corrected. The uspto.report page for publication 20050204402 lists a 5-claim set (e.g., claim 1 reciting "associating node-specific rules with each node that govern whether a packet sent to that node and from that node is blocked"). That claim language does not match the granted 20-claim set in the authoritative patent text, which instead recites the arriving/matrix/extensible sub-tree tree-graph architecture. This is consistent with the uspto.report page reproducing the pre-grant publication's claims rather than the granted claims. The granted 20-claim set reproduced in the patent text is used throughout the overview above.

5. Assignee field inconsistency. One aggregated source (Unified Patents portal) lists the assignee for US-7610621-B2 as "Cisco Technology Inc," and another snippet shows a 2004-03-09 priority date. Both conflict with the authoritative Google Patents reassignment record (Netskope Inc, priority 2004-03-10) and with the patent text. I regard those as aggregator artifacts.

6. One incidental "7610621" hit is unrelated to the patent's status. The number appears in an IPR exhibit (file history of U.S. Patent No. 9,917,856, IPR2022-01199) as a cited reference — i.e., the '621 patent is prior art in that proceeding, not the patent under challenge.

Sources consulted: Google Patents record for US7610621B2 (https://patents.google.com/patent/US7610621B2/en, retrieved 2026-09-24); uspto.report application page https://uspto.report/patent/app/20050204402; Justia patent page https://patents.justia.com/patent/20050204402; PTAB filings in Netskope, Inc. v. Fortinet, Inc., No. 4:25-cv-02360-HSG; CourtListener docket 69716023; PTAB case pages IPR2026-00031, IPR2026-00042, IPR2026-00474; IPR2022-01199 Exhibit 1002-4.

I'll search for litigation involving US patent 7610621 across patent litigation databases.

Let me search more specifically for this patent's family litigation and its prior owners.

Let me dig into specific case databases and the Netskope v. Fortinet docket.

Summary of Findings — US Patent 7,610,621

Patent: US 7,610,621 B2, "System and method for behavior-based firewall modeling"
Application: 11/076,719 · filed 2005-03-10 · priority 2004-03-10 · granted 2009-10-27
Inventors: Patrick Turley, Eric White
Assignment chain: Individual → White, Eric (2005) → Rocksteady Technologies, LLC (2011) → RPX Corporation (2012) → Netskope, Inc. (2024-07-05)
Status: Expired – Fee Related (adjusted expiration 2027-04-12)

Answer: No litigation asserting US 7,610,621 itself was located.

Based on the searches performed, I could not identify any district court, ITC, or Federal Circuit case in which US 7,610,621 was asserted as a patent-in-suit, nor any PTAB proceeding challenging it. I did not find a plaintiff, defendant, jurisdiction, case number, or filing date for a case specifically involving this patent number. I want to be explicit that this is a "not found" result rather than a confirmed negative, given the search limitations described below.

What I did find (related but distinct — do not conflate with '621)

1. Google Patents family flag. The authoritative patent page (https://patents.google.com/patent/US7610621/en) displays a "Family has litigation — First worldwide family litigation filed" link pointing to a Darts-IP record for family ID 34922296. That flag indicates at least one member of the '621 patent family has been litigated somewhere. The page does not identify the case, the parties, or whether the '621 patent itself (as opposed to a sibling) was the asserted patent.

2. Family siblings (same priority, 2004-03-10) — these are different patents, not '621:

   • US 8,032,933 B2 ("Dynamically adaptive network firewalls…") — continuation of 11/076,719
   • US 8,397,282 B2 ("Dynamically adaptive network firewalls…")

3. The '282 sibling appears in active litigation. In Netskope, Inc. v. Fortinet, Inc., the complaint lists US 8,397,282 among "Netskope's Patents" (alongside '336, '710, '639, '983, '426, '936, '153, and '697). See the complaint excerpt at the PTAB filing (https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1558590](/patent/1558590)/download-documents...). US 7,610,621 is not listed among the asserted patents. Related active matters:

   • Netskope, Inc. v. Fortinet, Inc., No. 4:25-cv-02360-HSG (N.D. Cal.) — ongoing; see the March 6, 2026 order on motion to dismiss at https://www.courtlistener.com/docket/69716023/149/netskope-inc-v-fortinet-inc/
   • The earlier declaratory-judgment action, No. 3:22-cv-01852 (N.D. Cal.) (Netskope's DJ/antitrust complaint against Fortinet)
   • Parallel PTAB IPRs (e.g., IPR2026-00031 on the '697 patent; IPR2023-00030 on the '941 patent) — none on the '621 patent.

4. RPX ownership. Transaction records show RPX Corporation acquired the patent in 2012 and held it until assigning it to Netskope in 2024. RPX has publicly represented that it does not assert the patents it acquires, so the 2012–2024 period is unlikely to include assertion of '621.

Caveats and limitations

• I was unable to complete a direct query of the Unified Patents litigation portal (https://portal.unifiedpatents.com/litigation/...) or PACER/CAFC dockets specifically filtered to "7610621" before reaching my search-step limit. The Unified Patents page for the patent (https://portal.unifiedpatents.com/patents/patent/US-7610621-B2) was returned but did not expose case data in the snippet.
• Patent litigation databases are incomplete for older, pre-2011 suits involving the prior owner Rocksteady Technologies, LLC, and old Darts-IP family-level records are not fully public. The "family has litigation" flag could correspond to a Rocksteady-era suit, a later Netskope suit, or litigation over a sibling patent.

Recommendation

To obtain a definitive litigation list for this specific patent, the next step would be a targeted Docket Navigator / LexisNexis PatentStrategies / Unified Patents search on the exact string "7,610,621" and on the Darts-IP family ID 34922296, plus a PACER party search for "Rocksteady Technologies" in 2011–2013. I cannot confirm from the results obtained that any such case exists — so on the present record, the correct answer is that no known litigation specifically asserting US 7,610,621 was identified.

I'll verify the canonical "no proceedings" signal against public sources before finalizing.

Let me run a couple more targeted checks on litigation/PTAB history and the family.

Let me check the litigation history flagged by Google Patents ("Family has litigation") and confirm no PTAB case numbers exist anywhere.

Proceedings overview

Total AIA trial proceedings on file against US 7,610,621: ZERO. The USPTO Open Data Portal structured block returns no IPR, PGR, or CBM proceedings, and repeated web searches surfaced no petition, institution decision, or final written decision naming this patent. That gives a defendant essentially a blank slate: no claim of the '621 patent has been canceled, narrowed, or construed by the PTAB, and — critically — no petitioner has triggered the § 315(e)(2) estoppel bar, so every prior-art ground remains available to you. The corollary is that the patent is untested rather than "hardened": you would be the first challenger, which cuts both ways (no roadmap, but also no adverse precedent against you).

No proceedings to report

I found no proceeding to list. Search hits that appeared to reference "7610621" were false positives and I am flagging them so they aren't mistaken for '621 proceedings:

• IPR2014-00178 (the "'761 patent") concerns U.S. 7,136,761 — a Coriolis flowmeter patent, unrelated. Not this patent.
• IPR2022-01199, Keysight Technologies — the number "7610621" appears only in an exhibit listing '621 as a cited reference in the file history of U.S. 9,917,856. Not a proceeding on '621.
• Netskope, Inc. v. Fortinet, Inc. (the parallel PTAB papers referencing '936, '697, '426, '153) — family-adjacent topic matter, but those petitions target different Netskope-owned patents, not '621.

The one litigation datapoint worth noting: the Google Patents family record carries a "Family has litigation" flag (Darts-IP family ID 34922296, https://patents.darts-ip.com/?family=34922296). That indicates district court activity somewhere in the family, not a PTAB trial. I could not, within the search budget for this task, confirm the specific case(s), and I will not guess at docket numbers.

Strategic summary

Claim status (all 20 claims). Because no AIA trial has ever been instituted against US 7,610,621, all claims 1–20 remain alive and untested at the PTAB. There are no canceled claims, no surviving-in-narrowed-form claims, and no claim constructions adopted in any Final Written Decision. Independent claims 1 (method), 10 (computer program product), and 16 (system) — each reciting the arriving / matrix / extensible sub-tree architecture — have never been construed by the Board. For a defendant, this means there is no PTAB record to disarm a demand letter; if Netskope (current assignee as of the 2024-07-05 assignment from RPX, per the Google Patents assignment record) asserts the '621 patent against you, the invalidity fight starts from scratch.

Estoppel landscape. § 315(e)(2) estoppel is triggered only by a petitioner who obtains an instituted IPR that reaches a final written decision. Here there are no petitioners and no FWDs, so zero estoppel attaches to anyone. All prior-art grounds under §§ 102/103, and any § 112 defenses in district court, are fully preserved. Conversely, no third party's prior petition gives you a free ride — there is no Board-tested art you can adopt.

Provenance / pattern signals. The portfolio history is a classic defensive-aggregator chain: inventors Turley & White → Rocksteady Technologies, LLC (2011/2012) → RPX Corporation (2012-08-13) → held by RPX for ~12 years → Netskope, Inc. (2024-07-05). RPX is a defensive aggregator whose stated model is to take patents out of assertion; Netskope's post-2024 acquisition of this and other RPX-family patents (the same July 1–5, 2024 RPX→Netskope assignments appear in the Fortinet petitions for the '936 and '697 patents) signals a shift from defensive to assertion posture. That dichotomy is itself a Fintiv / "settled expectations" argument you can deploy against discretionary denial (as Fortinet has argued in the parallel Netskope petitions): a patent held off-market by RPX and recently flipped to an asserting NPE-style posture undercuts any "settled expectations" narrative Netskope might offer. Notably, no defensive aggregator has ever filed a preemptive IPR on '621 — Unified Patents' portal lists the patent (https://portal.unifiedpatents.com/patents/patent/US-7610621-B2) but I found no Unified-filed challenge.

Recommended next steps

• No PTAB activity exists on US 7,610,621 — say it plainly to your client. The absence is a signal in itself: this patent, despite being in an actively litigated portfolio (the Netskope v. Fortinet campaign in N.D. Cal., Case No. 4:25-cv-02360-HSG, https://dockets.justia.com/docket/california/candce/4:2025cv02360/[446034](/patent/446034)), has not drawn a petition. That may mean it is not the asserted patent — check the operative complaint before investing in invalidity work.
• If you receive a demand citing '621, you are the first mover. Because no FWD exists, there is nothing to link to and no disposition to quote. Build your § 102/§ 103 grounds from primary art (the specification's own cited references — e.g., US 6,212,558; US 6,243,815 to Antur on firewall configuration/management; the Rocksteady/RPX prior-art set) without the benefit of any Board construction.
• Watch for a first petition. If Netskope adds '621 to the Fortinet complaint or a new suit, expect a defensive IPR to follow. Once instituted, the statutory clock is 1 year from institution to FWD (35 U.S.C. § 316(a)(11)); institution decisions are due within 6 months of the petition (§ 314(b)).
• Preserve your filings. If you file, note that a § 315(b) one-year bar runs from service of a complaint alleging infringement of '621 — track service dates in any Netskope complaint naming this patent.

Confidence / caveats: I am highly confident there is no AIA trial proceeding on US 7,610,621, based on the canonical ODP block plus multiple public searches. I could not independently verify the Darts-IP family litigation reference or confirm whether '621 is among the patents asserted in the 2025 Netskope v. Fortinet complaint — do not treat the litigation flag as a confirmed assertion of this specific patent without pulling the complaint from the docket above.

I'll start by hunting for the assignment records, corporate history, and any litigation/NPE signals tied to this patent and its family.

Excellent — I've found the core reel/frame chain. Let me verify the specifics and dig into the corporate history and litigation.

Ownership Reconstruction — US 7,610,621 B2

"System and method for behavior-based firewall modeling"
App. No. 11/076,719 · Filed 2005-03-10 · Priority 2004-03-10 (Prov. 60/551,698) · Issued 2009-10-27
Family ID 34922296 · Status: Expired – Fee Related (adjusted expiration 2027-04-12)

Sourcing note / confidence bounds. Google Patents' legal-events timeline exposes the reel/frame data for this family, and I recovered the key reels from cross-indexed family pages (US 7,590,728, US 7,665,130, US 7,624,438) plus a PTAB exhibit reproducing the USPTO assignment abstract for the sibling '697 patent. I could not reach assignmentcenter.uspto.gov directly in this session. Where I could not verify a reel/frame or a correspondent, I say so rather than guess. Correspondents of record are the weakest link here — see §Assignment timeline.

Inventors

Both are Austin-based and were co-founders/principals of Rocksteady Networks, Inc., the applicant named on the PCT counterpart (WO2005/020035A3) and the vendor of the "Rocksteady NSA Server" referenced by name in this family's own specification.

Unusual pattern — worth flagging. The PCT counterpart was filed in Rocksteady Networks' corporate name, but US 11/076,719 was filed with no corporate assignee — Google Patents renders the original assignee as "Individual." The patents then sat with the inventors personally for ~5.7 years (filed 2005-03-10; corporate assignment executed 2010-12-14). A second oddity: co-inventor Turley assigned his entire interest to co-inventor White alone on 2005-06-22, consolidating ownership in a single natural person rather than in the company. That is not the shape of a normal venture-backed startup's IP hygiene, and it is the kind of divergence that precedes a portfolio sale. However — the founders did not depart within 12 months of filing; they consolidated and later moved the asset corporately, so the "inventors bail early" signal is not present on the facts I can verify.

Original assignee

On the face of the issued patent: individual (Turley / White). Google Patents' bibliographic record lists Original Assignee: Individual for US 7,610,621.

De facto operating entity behind the invention: Rocksteady Networks, Inc. (Austin, TX), which:

• was the applicant on the PCT counterpart;
• shipped a commercial product embodying the family's technology — the Rocksteady NSA Server, a network access gateway / captive-portal appliance, cited by name in the family's specification (e.g., US 8,060,607);
• appears to have operated in the network-access-gateway space in the 2003–2005 window.

Current status: not determinable from the sources I reached. I could not confirm whether Rocksteady Networks was acquired, wound down, or dissolved. ⚠️ Do not conflate with the unrelated "Rocksteady Networks" sign/branding company (founded 2013, signage technology, rocksteady.com) that surfaced in a company-data search — same name, different business, no connection to this chain.

The patent-holding entity is a separate Texas vehicle, Rocksteady Technologies, LLC (Austin, TX per the sibling patent front pages), which took title only in December 2010.

Assignment timeline

Ten USPTO-recorded events appear on this patent. Reel/frame is confirmed for the three core 2010–2012 links and for the 2024 outbound transfer's correspondent; I did not verify reels for the 2005, 2018, 2020, or 2024 links.

• 2005-06-22 (executed/recorded) — Reel not verified

  • Conveyance: Assignment of assignors' interest
  • Assignor: Patrick Turley (inventor)
  • Assignee: Eric White (inventor)
  • Correspondent: not captured — Google Patents does not expose the correspondent field.
  • Context: Intramural consolidation — one co-inventor hands his whole interest to the other, before any corporate assignment exists.

• 2010-12-14 (executed) / recorded 2011-01-27 — Reel 025715/0123

  • Conveyance: Assignment (assignment of assignors' interest)
  • Assignor: Eric White
  • Assignee: Rocksteady Technologies, LLC (Texas)
  • Correspondent: not captured
  • Context: First corporate assignment — the inventors' personally-held application is moved into the IP-holding LLC, 5.7 years after filing. Reel 025715/0123 is a batch reel covering the whole Rocksteady family (same reel cited on US 7,665,130, US 7,624,438, US 7,590,728).

• 2012-06-25 (executed) / recorded 2012-06-28 — Reel 028457/0012

  • Conveyance: Confirmatory Assignment
  • Assignor: Eric White
  • Assignee: Rocksteady Technologies, LLC
  • Correspondent: not captured
  • Context: Curing/confirmatory filing — typically recorded to clean chain-of-title immediately before a sale. Six weeks later the asset was sold (below).

• 2012-08-02 (executed) / recorded 2012-08-13 — Reel 028774/0036

  • Conveyance: Assignment
  • Assignor: Rocksteady Technologies LLC
  • Assignee: RPX Corporation (California)
  • Correspondent: not captured
  • Context: Transfer to a defensive aggregator. Reel 028774/0036 is likewise a batch reel covering the entire Rocksteady portfolio (also cited on US 8,010,000-series siblings). RPX confirms in SEC filings that it does not assert the patents it acquires.

• 2018-06-29 (recorded) — Reel not verified

  • Conveyance: Security Interest
  • Assignor: RPX Corporation
  • Assignee: Jefferies Finance LLC
  • Correspondent: not captured
  • Context: Securitization — collateral pledge over RPX's patent assets as part of corporate financing. Not a title transfer of the invention.

• 2020-10-23 (recorded) — Reel not verified — two entries of the same date are listed on Google Patents

  • Conveyance: Patent Security Agreement
  • Assignor: RPX Clearinghouse LLC and RPX Corporation
  • Assignee: Barings Finance LLC, as Collateral Agent
  • Correspondent: not captured
  • Context: Securitization — replacement/expansion of the secured debt over the RPX asset pool.

• 2020-10-26 (recorded) — Reel not verified

  • Conveyance: Release of Security Interest
  • Assignor: Jefferies Finance LLC
  • Assignee: RPX Corporation
  • Correspondent: not captured
  • Context: Securitization unwind — the 2018 Jefferies lien is discharged.

• 2024-05-31 (recorded) — Reel not verified

  • Conveyance: Release of Security Interest in Specified Patents
  • Assignor: Barings Finance LLC
  • Assignee: RPX Corporation
  • Correspondent: not captured
  • Context: Lien release on specified patents — clears encumbrances on the specific assets being sold five weeks later. Standard pre-sale cleanup.

• 2024-06-30 (executed) / recorded 2024-07-05 — Reel not confirmed (a reel 67596/0606 appears in the same recording batch on the sibling '697 patent's USPTO assignment abstract, PTAB Ex. 1016 in IPR2026-00031; I could not confirm it maps to US 7,610,621 — verify in Assignment Center)

  • Conveyance: Assignment of interest
  • Assignor: RPX Corporation
  • Assignee: NETSKOPE, INC., 2445 Augustine Drive, Suite 301, Santa Clara, CA 95054
  • Correspondent: PHOEBE ANN YOUNG, 1500 NW Bethany Blvd., Suite 200, Beaverton, OR 97006 (attorney docket "RPX ASSIGNMENT"). Flag: recurring. The identical correspondent and address appear on the parallel RPX→Netskope recordings in the same June/July 2024 batch (same exhibit, the '697 patent). This looks like RPX's outbound-transfer handler executing a bulk portfolio sale, not an NPE's attorney running a shell chain — one correspondent, many assignees/purchasers.
  • Context: Transfer out of a defensive aggregator to an operating company. Executed 2024-06-30, recorded 2024-07-05 — the same window in which Netskope took the '697 and '936 patents from RPX.

Litigation context (family): Google Patents flags this family with "Family has litigation" (first worldwide family litigation; Darts-IP family 34922296). In parallel, Fortinet v. Netskope, Inc. (PTAB IPR2026-00031 and companion petitions) records that Netskope "acquired the patent on July 1, 2024 … for purposes of asserting it against Petitioner shortly thereafter," and that RPX had held those patents 2020/2021–2024 as a defensive aggregator that "does not assert the patents it acquires." I could not confirm that US 7,610,621 itself is in any pleaded case.

Timeline diagram

timeline
    title Ownership of US 7610621
    2004 : Provisional filed by Patrick Turley
    2005 : US application filed by inventors as individuals
         : Turley assigns interest to Eric White
    2009 : Patent US 7610621 issues
    2010 : White assigns to Rocksteady Technologies
    2012 : Confirmatory assignment to Rocksteady
         : Rocksteady assigns to RPX Corporation
    2018 : Security interest to Jefferies Finance
    2020 : Security agreement with Barings Finance
         : Release of Jefferies security interest
    2024 : Lien release by Barings Finance
         : RPX transfers patent to Netskope Inc
         : Netskope asserts RPX patents vs Fortinet

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. The LLC that took title (Rocksteady Technologies, LLC, 025715/0123, 2010-12-14) does not carry an "IP / Patents / Licensing / Holdings / Ventures" suffix and is addressed in Austin, TX on the sibling front pages, not at a registered-agent service in Wilmington or Dallas. It is the affiliated IP-holding vehicle of the operating Austin vendor (Rocksteady Networks, Inc.), not a newly minted licensing shell. Caveat: operating company and IP holder are separate legal persons, which is mildly notable but far short of a shell finding.

2. Known asserter in the chain — NOT PRESENT. No Acacia, Marathon, IV, IPNav, Wi-LAN, Conversant/Mosaid, Vringo, Pendrell, Uniloc, MPHJ, or Spangenberg entity appears. The intermediate holder is RPX Corporation (028774/0036, 2012-08-02) — the archetypal defensive aggregator — and the current owner, Netskope, Inc., is a large operating security vendor (2,910 employees per its investor filings), not a listed NPE.

3. Repeat correspondent across the chain — WEAK / UNVERIFIED. Only one correspondent is recoverable: Phoebe Ann Young, Beaverton, OR — on the RPX→Netskope 2024 recording, and on the identical recordings in the same batch. That is recurrence within a single bulk transfer, i.e. one handler processing one deal, not a repeated lawyer shepherding a shell chain link-by-link. I could not recover correspondents for 025715/0123, 028457/0012, 028774/0036, or the 2005 Turley→White filing, so a genuine repeat-correspondent pattern across the 2005–2012 links cannot be ruled out — mark unclear.

4. Cascading transfers (<24 months) — PARTIALLY PRESENT. Three recorded links inside ~20 months: 025715/0123 (2010-12-14) → 028457/0012 (2012-06-25, confirmatory) → 028774/0036 (2012-08-02). But two of the three are White→Rocksteady (original + confirmatory), and the third flips the whole batch to RPX; there is no chain of successive distinct LLCs and no shared-principal pattern. This reads as pre-sale title cleanup ahead of a portfolio sale, not as an NPE cascade.

5. Pre-litigation transfer — PRESENT for the batch, UNCLEAR for this patent. The RPX→Netskope assignment executed 2024-06-30 was recorded 2024-07-05, and Netskope moved to assert against Fortinet "shortly thereafter" (per the IPR2026-00031 record). That is a textbook buy-to-sue window. I could not verify a 6-month complaint date tied specifically to US 7,610,621, so treat as unclear on this patent, strong on the sibling '697/'936 patents from the same batch.

6. Bankruptcy fire-sale — NOT PRESENT (no evidence). Nothing in the record shows a Rocksteady bankruptcy sale. Note: the Nortel → Rockstar → RPX bankruptcy auction (RPX Clearinghouse, 2014, ~$900M; Asset Purchase Agreement 2014-12-22) is a different transaction and does not touch this chain — RPX acquired this patent from Rocksteady in 2012, two years earlier. Do not attribute the Nortel sale to this family.

7. Privateering — NOT PRESENT. No operating company is using an NPE front to attack competitors here. If anything the vector runs the other way: the patent was pulled out of a defensive aggregator in 2024 and now supports the operating buyer's own assertion campaign.

8. Defensive aggregator (anti-NPE) — PRESENT 2012–2024, BUT SUPERSEDED. The chain parked at RPX Corporation for ~12 years (028774/0036, 2012-08-02 → 2024-07-05), which would ordinarily be the "neutralized" outcome. Critically, the chain does not terminate at RPX — RPX sold out in 2024, reversing the defensive effect. The inverse signal therefore no longer holds.

Verdict

Operating-company assertion

Justification: The chain ends at an operating security vendor, not a shell: Netskope, Inc. acquired the patent from RPX (executed 2024-06-30, recorded 2024-07-05, correspondent Phoebe Ann Young), and the PTAB record in Fortinet v. Netskope (IPR2026-00031 / Ex. 1016) shows Netskope taking the same June–July 2024 RPX batch "for purposes of asserting it" against a direct competitor. There is no shell-entity transfer, no known NPE asserter, and no cascading LLC chain — the only intervening holder, RPX Corporation (reel 028774/0036, 2012-08-02), is a defensive aggregator, and the original corporate owner, Rocksteady Networks, Inc. (Austin), shipped a gateway product embodying the family. The one genuinely notable pattern is the 2012 title-cleanup sequence (reels 025715/0123 → 028457/0012 → 028774/0036 in 20 months) followed, twelve years later, by the 2024 extraction from RPX — i.e., a defensive aggregator's "shelf" patent re-entering circulation as an assertion asset. Caveat: I could not confirm that US 7,610,621 itself is in a pleaded complaint, only that its acquisition batch is being asserted.

Verify (reels, correspondents for the 2005/2018/2020/2024 links):

• USPTO Assignment Center — https://assignmentcenter.uspto.gov/
• Legacy Assignment Search — https://assignment.uspto.gov/patent/index.html (search "7610621")
• Google Patents legal events — https://patents.google.com/patent/US7610621/en
• Darts-IP family/litigation record (family 34922296) — https://patents.darts-ip.com/?family=34922296

Unverified items — do not treat as findings: the 2005, 2018, 2020 and 2024 reel/frame numbers; the correspondents of record for every link except the 2024 Netskope transfer; whether Rocksteady Networks was acquired, wound down, or dissolved; and whether US 7,610,621 is asserted in any live case.

I'll research US patent 7610621 and its prior-art citations. Let me start with targeted searches.

Let me pull details on the most relevant prior-art references cited on the face of the patent.

Patent Analyst Report — US 7,610,621

1. Patent Identification (literal)

Source: https://patents.google.com/patent/[US7610621B2](/patent/US7610621B2)/en

2. Scope note on "each patent citation" — important caveat

The face of US 7,610,621 lists 160 citations ("Citations (160)"), plus 32 "Cited By" and multiple family references. I was able to retrieve and verify the patent itself and full text for the most material references, but I could not individually verify all 160 in this session. I therefore cover the references with the greatest bearing on the independent claims (1, 10, 16) and the key dependent features, and I identify the remainder by class. I do not fabricate detail for entries I could not confirm.

Critical analytic point on § 102: Under 35 U.S.C. § 102, a single reference must disclose every limitation of the claim, arranged as claimed. Almost all of the 160 face citations were applied by the examiner as background or as § 103 art, not as anticipatory art. As shown below, no cited reference appears to disclose the full independent claim 1 combination — specifically the three-part rule-tree architecture (arriving sub‑tree that only conditions, matrix sub‑tree that only accepts/drops, extensible sub‑tree) applied to a node/connection model. I flag genuine § 102 candidates for narrower claims and label the rest accurately as § 103/background.

3. The claim features § 102 analysis must track

• Claim 1 (independent, method): firewall model defining nodes, connections between nodes, and rules; each node simultaneously a source and a destination; rule set = tree graph with (a) arriving sub‑tree = "conditioning the data packets without accepting or dropping," (b) matrix sub‑tree = "accepting or dropping … without changing," (c) extensible sub‑tree for dynamic extensibility; implement on machines at the network segments where nodes reside; receive packet at arriving node; condition via arriving sub‑tree; accept/drop via matrix sub‑tree (node, inter‑node connection, or combination).
• Claims 6–9 (dependent): reconfigure while executing; extend/prune/modify serialized rule sequences; insert rules; delete rules.
• Claims 2, 4, 5, 15, 20: nodes = services/devices; arriving rules = node behaviors; matrix rules = connection behaviors; moving devices/services between nodes as a runtime change.
• Claims 10–15, 16–20: computer-program-product and system counterparts of the above.

4. Most relevant cited prior art (full citation, date, description, § 102 assessment)

A. Closest "firewall architecture" references

US 5,878,231 A — Baehr et al., Sun Microsystems
"System for packet filtering of data packets at a computer network interface." App. 08/795,374, filed 1997-02-04; granted 1999-03-02 (EP 0743777 counterpart, priority US 444,351, 1995-05-18).
URL: https://patents.google.com/patent/US5878231
Description: A dedicated screening system with three port types (private/public/proxy network). Packets are filtered on contents, state and criteria; the screen acts by allowing through (with or without alteration of address/data), dropping, or redirecting to a proxy host. (Companion: US 5,884,025, same family.)
§ 102 assessment: Potential partial anticipation of the generic "condition/modify vs. accept/drop" concept, but does not disclose the claimed node model where each node is simultaneously source and destination, the arriving/matrix/extensible sub‑tree split, or a rule tree graph. Anticipation of claims 1/10/16 is not supportable; at most relevant to the "conditioning" and "change vs. drop" distinction as § 103 art.

US 6,219,706 B1 — Cisco Technology
"Access control for networks." Filed 1998-10-16; granted 2001-04-17.
Description: Stateful access control/filtering for network traffic.
§ 102 assessment: Relevant to the "accept or drop" function of the matrix sub‑tree, but silent on the node/connection model and the three sub‑tree structure. § 103/background only.

B. Firewall configuration/reconfiguration (strongest § 102 candidate for claims 6–9, 13–15, 19–20)

US 6,212,558 B1 — Antur, Anand K.
"Method and apparatus for configuring and managing firewalls and security devices." Priority 1997-04-25 (Prov. 60/044,853); granted 2001-04-03.
URL: https://patents.google.com/patent/US6212558
Description: Configuring/managing a plurality of network security devices via network directory services, implementing a security policy centrally and pushing configuration data (firewall rule/policy configuration) to the devices; supports IP/IPX, NAT, VPN, DMZ, transparent proxying.
§ 102 assessment: Discloses centralized, policy-driven firewall configuration and dynamic updating of security-device configuration, which maps to the reconfiguration concepts in claims 6–9/13–15/19–20. However, it does not disclose the node/connection + A/M/D/X sub‑tree model of claim 1, nor "extending/pruning/modifying serialized sequences of firewall rules while executing." Best characterized as § 103 art against the reconfiguration-dependent claims.

US 6,243,815 B1 — Antur et al.
"Method and apparatus for reconfiguring and managing firewalls and security devices." App. 08/998,313, filed 1997-12-24; granted 2001-06-05.
URL: https://patents.google.com/patent/US6243815 ; https://www.freepatentsonline.com/[6243815](/patent/6243815).html
Description: Reconfiguring network security devices from a single administration point using a hierarchical directory structure of sub-directories; configuration data copied down the hierarchy and installed/reconfigured on devices (including upon disruption). Explicitly hierarchical/recursive.
§ 102 assessment: This is the closest cited reference to the reconfiguration/hierarchy aspects (claims 6–9 and 13–15/19–20, and the "clone-n-hone"/system-wide-policy discussion in the spec). Its hierarchical directory tree of configurations distributed to devices is conceptually adjacent to the claimed hierarchical rule-chain tree — but it is a configuration-distribution tree, not the claimed packet-path rule tree (arriving/matrix/extensible), and it lacks the simultaneous source‑and‑destination node abstraction. Not a full anticipation of claim 1; credible § 103 combination art.

C. Policy-management / directory-enabled references

US 6,502,131 B1 — Novell, Inc.
"Directory enabled policy management tool for intelligent traffic management." Priority 1997-05-27; granted 2002-12-31. § 102: directory-driven policy for traffic management; no node/connection packet-path tree. § 103/background.

US 6,535,879 B1 — Netscape Communications
"Access control via properties system." Filed 2000-02-18; granted 2003-03-18. § 102: property-based access control; not firewall node modeling. Background.

US 6,092,200 A — Novell, Inc.
"Method and apparatus for providing a virtual private network." Filed 1997-08-01; granted 2000-07-18. § 102: VPN provisioning; relevant as background to the "VPN node" in Fig. 1 but not anticipatory.

D. Authentication / captive-portal references

US 6,324,648 B1 — GTE Service Corporation
"Secure gateway having user identification and password authentication." Filed 1999-12-14; granted 2001-11-27. § 102: authentication gateway; relates to the spec's "capture unauthorized clients / force authentication" behavior, not to the claimed model. Background.

US 6,463,474 B1 — Cisco Technology
"Local authentication of a client at a network device." Filed 1999-07-02; granted 2002-10-08. § 102: client authentication at a network device; background to the "client mark / authorization" discussion.

E. Bandwidth/QoS/roaming references (background)

• EP 0 587 522 B1 — IBM, "Rate-based congestion control in packet communications networks," 1992-09-10, granted 2000-01-26 — QoS/bandwidth, no firewall node model.
• WO 2002/009458 A2 — Bluesocket, "Method and system for enabling seamless roaming in a wireless network," priority 2000-07-24, pub. 2002-01-31 — wireless access control; background.
• Numerous Nomadix, Bluesocket, Reefedge, Cisco (6463474), and QoS/authentication references (e.g., US 5,673,393; 5,748,901; 6,178,183; 6,088,451; 6,199,113; 6,332,133) — all pre‑2004 and cited as background to the network‑access‑gateway context.
• US 2001/0038639 A1 (McKinnon), and the incorporated US 10/683,317 → US 8,117,639 B2 ("System and Method for Providing Access Control," Rocksteady, priority 2002-10-10) — this is related art (same inventor family, expressly incorporated by reference), not third‑party anticipation.

F. Executed Art in the child/continuation (relevant to US 8,392,282, informing the family)

The examiner in the continuation 13/092,488 relied on:

• US 7,146,639 B2 — Bartal et al. ("firewall with at least one node," §102/103 basis)
• US 2004/0236963 A1 — Danford et al. (runtime reconfiguration without operator interaction)
• US 7,634,805 — Aroya (rewriting a portion of a packet header)
• US 7,836,496 — Chesla et al.; US 7,540,025 — Tzadikario; US 2002/0083175 A1 — Afek et al.
  These are the references the USPTO actually treated as the closest art for the family's broader "dynamically adaptive network firewalls" claims and are more probative than most of the 160 face citations.

5. Bottom line

1. No single cited reference discloses all limitations of independent claims 1, 10, or 16. The distinguishing combination — a firewall model of simultaneously-source-and-destination nodes plus inter-node connections, implemented as a rule tree graph whose arriving sub‑tree only conditions, whose matrix sub‑tree only accepts/drops, and which includes a dynamically extensible (X) sub‑tree — is not present in any one face citation as verified.
2. Strongest § 102 candidates for the narrower claims:

• US 6,243,815 B1 and US 6,212,558 B1 (Antur) — for the reconfiguration features of claims 6–9, 13–15, 19–20 (centralized/hierarchical, dynamic firewall reconfiguration). Read alone, each is closer to § 103 art against those claims than a clean § 102 anticipation, but they are the most on‑point.
• US 5,878,231 A (Baehr/Sun) — for the generic "condition/modify vs. drop" packet-handling concept underlying claim 1's arriving/matrix distinction (partial, at most).

1. Everything else in the 160-citation list is properly characterized as § 103 / general-state-of-the-art background, chiefly in the areas of (i) directory/policy-driven firewall management, (ii) stateful packet filtering and access control, (iii) client authentication/captive portals, and (iv) bandwidth/QoS/roaming — none of which supplies the claimed node/connection + sub‑tree architecture.

6. Explicit limitations of this analysis

• I verified full text for the references in Sections 4.A–4.E but did not individually retrieve/verify all 160 face citations; entries not enumerated above (largely pre‑2004 Nomadix/Bluesocket/QoS/authentication art appearing in the truncated citation table, ending at US 2003/0059038 A1) are reported by class, not itemized.
• Any assertion of actual § 102 anticipation requires an element‑by‑element comparison of the issued claim text against the reference's enabled disclosure; the assessments above are preliminary and should be confirmed against the reference full texts (e.g., via USPTO Patent Center / Patent Public Search) before being relied upon.
• US 7,610,621's own claims use "the data packets" (claim 1) vs. "the in data packets" (claim 2) and "farther stores" (claim 13) — apparent typos in the granted text; I have interpreted identifiers literally and not corrected them, per instruction.

I'll ground a few key prior-art references from the citation list before building the § 103 analysis.

§ 103 Obviousness Analysis — US 7,610,621 B2

Source of prior art: the "Citations (160)" section of the patent record at https://patents.google.com/patent/[US7610621B2](/patent/US7610621B2)/en, plus the specification's own admitted prior art. The full citation list as supplied is truncated (it runs through US 2003/0059038 A1), so this analysis is limited to references visible on the page plus those the patent text itself admits. The "Cited By (32)" list is not used — those documents post-date the March 10, 2004 critical date and are not prior art.

Data-integrity note: the system clock reads 2026-09-30 while this task header reads April 26, 2026. Neither date affects the pre-AIA § 103 framework below, but I flag the discrepancy rather than silently reconciling it.

1. Legal framework and critical date

• Application 11/076,719 was filed 2005-03-10, claiming § 119(e) benefit of provisional 60/551,698 filed 2004-03-10. Because the filing date precedes 2013-03-16, pre-AIA 35 U.S.C. § 103(a) governs, with §§ 102(a), (b), (e) and (f) defining the prior-art universe. The effective critical date for § 102(a)/(b) purposes is 2004-03-10.
• The Graham v. John Deere factors apply: scope/content of the art, differences from the claims, level of ordinary skill, and secondary considerations. Under KSR Int'l v. Teleflex, a combination of known elements is obvious where it yields no more than predictable results, and "a court must ask whether the improvement is more than the predictable use of prior art elements according to their established functions."

Level of ordinary skill (proposed): a person with a B.S. in computer science or electrical engineering (or equivalent) and 2–4 years of experience designing or administering network firewalls and gateway appliances, including working knowledge of IP filtering, NAT, and at least one rule-engine implementation (e.g., Linux netfilter/iptables or an equivalent commercial ACL engine). The claimed subject matter is entirely within such a person's working competence — the specification itself says the invention "permits the deployment of unsophisticated, general implementation technologies (i.e., off-the-shelf hardware)."

Important admission on the face of the patent: the specification states that "the Linux operating system has a subsystem known as 'iptables' (for Internet Protocol Tables) that offers a 'rule' syntax for representing the logic of packet handling through the Linux system," and then reproduces working iptables syntax (iptables -t filter -A ExampleChain -j TestA:Accept). That is an applicant admission that chain-based, target-based firewall rule engines — with named chains, jump targets, and per-chain policies — antedate the invention (MPEP § 2129). It is the single most damaging piece of art in this record because it is not merely cited but adopted by the applicant.

2. Prior art references from the page's Citations list

3. Claim 1 — element-by-element mapping

Claim 1 requires (a) a firewall model defining nodes, connections, and rules applicable to nodes/connections; (b) each node simultaneously a source and destination; (c) rules as a tree graph with an arriving sub-tree (condition only, no accept/drop), a matrix sub-tree (accept/drop only, no change), and an extensible sub-tree; (d) deployment on machines at the network segments where the nodes reside; and (e)–(g) receive at an arriving node, condition, then accept/drop per node/connection rules.

Result: every element of claim 1 is disclosed or rendered obvious by Antur '558 in view of Baehr '231 and the admitted iptables/netfilter art, with Courtney '370 supplying the explicit "model the device abstractly, then generate the implementation" teaching, and Antur '815 supplying dynamic reconfiguration. The only arguably novel-sounding term — "matrix sub-tree" — is a label for the filter function that netfilter's filter table performs.

4. Motivation to combine (the KSR rationales)

This is the strong part of the rejection, because the motivation is supplied by the references themselves rather than by hindsight:

1. Same field, same problem. Antur '558 and '815 are directed to firewall configuration and management. Antur '558 states outright that "ease of use and ease of management are essential to providing a security system that will not be abandoned because it is too hard to use or too expensive to manage," and criticizes the need to "log into each firewall server and modify the security policy individually." That is precisely the problem the '621 specification identifies ("Firewalls are potentially complicated structures that are generally maintained manually by a skilled professional… the skilled firewall professional provides the intelligence… lacking in static firewall technology").

2. The '621 patent's own background supplies the motivation. The specification frames the invention as the answer to a known need in the known art: abstract firewall behavior so that "the firewall owner [can] generally describe how the firewall should behave, and the invention can automatically produce the requisite, specific firewall configuration, without detailed manipulation by a human operator." Framing the problem that way is itself an admission that the combination is the natural next step.

3. Predictable use of known elements. Separating a packet-mutating phase from a permit/deny phase, and placing a mutable "extension" region off the main path, are the established functions of netfilter's mangle/nat versus filter tables and user-defined chains. Arranging Antur's abstract node/connection model over that mechanism is "the predictable use of prior art elements according to their established functions" (KSR).

4. Design incentive / market pressure. Antur '558 documents the multi-platform, multi-protocol firewall problem; Courtney '370 documents the incentive to abstract away vendor-specific command interfaces. A POSITA building a policy-driven gateway on commodity hardware had strong reason to (i) model the device abstractly (Courtney), (ii) drive the model from a central policy (Antur '558/'815), and (iii) implement it on the then-standard Linux rule engine (admitted iptables art) rather than write a bespoke packet classifier.

5. Reasonable expectation of success. Each reference was a working, deployed system; nothing in the combination requires unpredictable technology. The '621 specification concedes the implementation is "existing operating system mechanisms."

5. Dependent claims

Claim 16 (system: processor + computer-readable medium) deserves separate emphasis: Antur '558 claims 15–20 claim exactly that structure — "a processor; and a computer readable media including code that directs the processor to…" — for the same firewall-modeling function. Claim 16's only additional requirement is the tri-partite tree graph, which fails for the reasons in § 3.

6. Rejection-ready combination statements

An examiner could reasonably write:

• Claims 1–5, 10–12, 16–18 — obvious over Antur (US 6,212,558) in view of Baehr (US 5,878,231) and the iptables/netfilter rule-chain engine admitted at page 8 of the specification. Antur teaches the abstract node/connection firewall model, centrally described and applied to individual firewall nodes on their respective network segments; Baehr teaches multi-homed screening in which packets are filtered on source/destination and then allowed-through-with-alteration or dropped; and the admitted iptables art teaches a hierarchical, serialized rule-chain structure with a modifying table that precedes a filtering table and an extension mechanism via user-defined chains. Motivation: Antur's own stated need to make firewalls easier to configure and manage.

• Claims 6–9, 13–14, 19 — further in view of Antur (US 6,243,815), which teaches dynamically reconfiguring and re-installing security-device configuration from a central point, in combination with the live rule insertion/deletion capability of the admitted iptables art. Motivation: timely policy updates without touching each device.

• Claims 2, 11, 15, 20 — further in view of Antur '558's disclosure of per-interface entities, service-level configuration, VPN and multi-platform support, and Courtney (US 2003/0046370 A1) for the teaching that a device configuration may be reduced to an abstract model and regenerated to native form.

• Claims 3, 12 — the departing sub-tree is taught by the POSTROUTING mangle/nat chains of the admitted art and by Baehr's outbound alteration of packet addresses.

Secondary considerations: I found no evidence in the record of unexpected results, industry praise, licensing-nexus, or copying tied to these claims. The specification's framing of the benefit as enabling "off-the-shelf hardware" is an engineering-convenience argument, not a non-obviousness argument, and "clone-n-hone" deployment is a management convenience.

7. Where an applicant could push back (and why it probably fails)

1. "The references do not teach a single tree graph with three named sub-trees." True as a matter of literal labelling, but KSR forecloses requiring the reference to disclose the claim's particular organization where the functions are separately known and their combination is predictable. netfilter's tables/chains supply both the separation and the ordering.
2. "The extensible sub-tree is a distinct architectural contribution." The '621 specification concedes that :X chains "may be provided, a priori… or may be dynamically loaded," and the admitted iptables art's user-defined chains plus -N/-A/-I/-D accomplish the same tap-based extensibility.
3. "Each node is simultaneously a source and a destination." Trivially met by any bidirectional interface model (Antur's public/private IP interfaces; Baehr's private/public/proxy ports).
4. Claim 15/20 "moving devices between nodes" is the only limitation where a genuine (if narrow) non-obviousness argument could be made on a literal reading, because Antur's directory-structure reclassification is arguably a different operation from moving a live Device object between firewall nodes. That is a limitation-by-limitation fight, not a defense of the independent claims.

8. Caveats and limitations of this analysis

• I am working from the citation list and abstracts/specification excerpts surfaced in search, not from a full read of every full-text reference. For Antur '558 I retrieved the complete claims, description, and figure list; for Antur '815 the abstract and claims; for Baehr '231 the abstract; for Courtney '370 the description of the modeling approach. Conclusions about references I have only seen by title are flagged as inferential.
• The supplied page text truncates the 160-reference citation list at approximately US 2003/0059038 A1. A complete citation list may contain still-closer art (for example, art directed specifically to packet-mark-based firewall rule trees).
• Unrelated but potentially relevant art sitting outside the '621 citation list: search results surfaced a USPTO final Office action in sibling application 13/092,488 (same 2004-03-10 family) rejecting claims over Bartal (US 7,146,639) in view of Danford (US 2004/0236963) and Aroya (US 7,634,805). In that action the examiner characterized Bartal as disclosing "defining at least one node… associating a set of firewall rules with the at least one node… receiving a packet at a first node… accepting or denying the packet based on the set of firewall rules," plus per-node rule subsets, and Danford as teaching runtime reconfiguration. That characterization maps almost line-for-line onto '621 claim 1. These references are not in the '621 citation list, and I have not verified their effective dates against the 2004-03-10 critical date, so I do not rely on them — but they indicate an examiner-facing art set that overlaps heavily with the '621 claims. If their dates hold, they would materially strengthen a § 103 rejection.
• The iptables traversal details (table ordering, user-defined chains) are corroborated by Linux documentation dated after the critical date. I rely on the applicant's own admission in the '621 specification that iptables existed and used a chain/target rule syntax, plus general knowledge that netfilter shipped with Linux 2.4; the later web documentation is cited only as corroboration of traversal order, not as the § 102(b) publication.
• No litigation or validity challenge to the '621 claims was identified (see the earlier litigation section), so there is no adversary's obviousness record to draw on and no secondary-considerations evidence either way. This analysis is a technical prior-art assessment only, not an invalidity opinion or a freedom-to-operate conclusion.

Bottom line: On the prior art cited on the face of this patent, independent claims 1, 10, and 16 appear obvious over Antur '558 + Baehr '231 + the applicant-admitted iptables/netfilter art, with Courtney '370 and Antur '815 supplying express motivation and the reconfiguration limitations; dependent claims 2–9, 11–15, and 17–20 are likewise obvious in further view of those references, with claims 15 and 20 being the only limitations susceptible to a genuinely narrow non-obviousness argument.