US 7587512

I'll search for authoritative information on US 7587512 and any related litigation.

Let me search for specific litigation and PTAB activity involving this patent.

Let me look for the granted claim set and any CAFC/PTAB proceedings.

US Patent 7,587,512 — Summary and Docket Search

Caveat on citations: The full text I was given is authoritative for the specification and abstract but is truncated before the issued claims. My independent-claim overview below is therefore grounded in the patent's own "Summary of the Invention" (which states that the described embodiments correspond to the claimed subject matter) and is flagged where uncertain. I also could not locate an authoritative source contradicting the record below.

1. Bibliographic data (from the patent text and Google Patents record)

Ownership trail recorded in the assignment data: individuals → Rocksteady Networks, Inc. (2005) → Eric White (Asset Purchase Agreement, 2005) → Rocksteady Technologies, LLC (2011) → RPX Corporation (2012) → Netskope, Inc. (July 5, 2024). Various security interests/releases (Jefferies Finance LLC 2018; Barings Finance LLC 2020) also appear in the chain.

2. Abstract (verbatim)

"One embodiment of the present invention provides a device for allocating bandwidth on a per user basis. The device can be a computing device that comprises a processor, a first network interface coupled to the processor, a second network interface coupled to the processor, and a storage medium accessible by the processor that contains a set of computer instructions. The computer instructions can be executable by the processor to retrieve a set of user profiles. Based on the user profile for each user, the computer instructions can be executable to establish at least one bandwidth limit for each user. For each user, the computer instructions can be further executable to regulate bandwidth usage associated with that user based on the at least one bandwidth limit established for that user. The computer instructions can also be executable to update the at least one bandwidth limit."

3. Independent-claim overview (plain language)

The Summary of the Invention describes four embodiments, which correspond to the operative independent claims. Using the granted specification's own wording:

1. "Device" claim (allocating bandwidth on a per-user basis). A computing device with a processor, two network interfaces (e.g., Ethernet, T1, or wireless — one facing the users, one facing the controlled network such as the Internet), and a storage medium holding computer instructions. The instructions: (a) retrieve a set of user profiles, each corresponding to a specific user and containing attributes specifying bandwidth limitations; (b) establish at least one bandwidth limit per user based on that user's profile; (c) regulate each user's bandwidth usage against that limit; and (d) update the limit(s) for one or more users. In practice this is implemented via an IP-table-indexed user-specific rule that references a traffic-control rule (e.g., the Linux "Traffic Control" facility), keyed on MAC address and/or IP address.

2. Computer-readable-medium claim (allocation authoring). The same functional sequence — retrieve profiles → establish per-user limits → regulate per-user usage → update limits — expressed as computer instructions stored on a computer-readable medium executable by a processor.

3. Method claim. A method comprising: retrieving a set of user profiles; establishing at least one bandwidth limit for each user based on the corresponding profile; for each user, regulating bandwidth usage against the established limit; and updating the limit for at least one user.

4. Computer-readable-medium claim (enforcement/oversubscription). Instructions executable to: establish a bandwidth limit for a user based on the user's profile; receive a first network communication; determine whether that communication causes the limit to be exceeded; drop (or queue) the communication if it does; and update the bandwidth limit for the user.

Scope notes drawn from the specification and dependent-claim families visible in the record:

• The limits can be upload and/or download, and apply regardless of the application generating the traffic (per-application prioritization is an alternative embodiment).
• "Updating" expressly covers dynamic reallocation to account for new users, excess capacity, time of day, usage patterns, and utilization averaging, plus prompted re-provisioning (e.g., a user pays for more bandwidth mid-session, and the traffic-control rule is modified without requiring re-authentication).
• Dependent claims visible in the family address indexing rules by MAC address and/or IP address, metering bandwidth on a per-user basis, and session monitoring.
• A weighted-competition formula appears in the specification (Eq. 1: W = Σwᵢ; Eq. 2: eᵢ = aᵢwᵢ/W) for fairly compressing nominal allowances, including a "service factor" and an "incompressible" designation per user.

Uncertainty flag: I did not retrieve a verbatim reproduction of the issued 60-claim set, so I cannot attest to the exact claim numbering of the four independents, nor rule out additional independent claims beyond these four. The overview above is faithful to the patent's own Summary; anyone relying on claim scope should verify against the granted claims (US 7,587,512 B2 col. 10 et seq.).

4. Litigation / CAFC 2026 docket search — results

• No CAFC 2026 docket for US 7,587,512 was found. I retrieved the Federal Circuit's published March 2026 oral-argument calendars and a July 8, 2026 Notice of Docketing (Fed. Cir. No. 2026-2012, Contour IP Holding LLC v. GoPro, Inc.). Neither mentions patent 7,587,512. I cannot state that no such appeal exists — only that my searches did not surface one.
• Google Patents flags the family as having litigation (Darts-IP family 32110205) and notes "First worldwide family litigation filed." I could not retrieve the specific case names/courts from that link.
• The PTAB hits for "7587512" that appeared in results are prior-art exhibit lists in unrelated Fortinet and Portsmouth proceedings (e.g., PTAB Petition 1558605/1520957), not a post-grant proceeding against 7,587,512 itself.
• The later Netskope, Inc. assignment (July 5, 2024) suggests the patent's current holder is a commercial entity; I found no 2026 complaint or appeal by Netskope asserting it.

Bottom line: The bibliographic and technical record for US 7,587,512 is well-supported; the litigation record is not — treat any statement about 2026 CAFC activity as unconfirmed, and note that unsourced assertions about this patent's docket should be verified directly against the Federal Circuit's PACER/CM-ECF docket before reliance.

I'll search multiple litigation databases for US 7,587,512.

Let me search more targeted sources.

Let me search for the specific litigation campaign and docket records.

Litigation Search — US Patent 7,587,512

Date note: The task header says April 26, 2026, while my operating environment reports today as September 30, 2026. I flag the discrepancy rather than silently pick one; nothing in my findings turns on it.

Bottom line

I could not identify any confirmed, docketed litigation involving US 7,587,512 with a verifiable plaintiff, defendant, court, case number, and filing date. I am reporting this as an absence of retrieved evidence, not as affirmative proof that no suit exists. There is, however, a strong indication in the patent record that family litigation exists, which I could not resolve to case-level detail.

This is consistent with — and does not contradict — the previously generated section, which likewise found the litigation record "not" well-supported and flagged it as unconfirmed.

1. What the patent's own record shows (affirmative evidence of some litigation)

The authoritative Google Patents record for US7587512 contains a family-litigation badge:

"Family has litigation — First worldwide family litigation filed — Critical — https://patents.darts-ip.com/?family=32110205&utm_source=google_patent..."

• Family ID: Darts-IP 32110205
• What this establishes: A third-party litigation database associates this patent family with at least one filed court proceeding ("First worldwide family litigation filed").
• What this does NOT establish: The patent number, plaintiff, defendant, court, case number, filing date, or outcome. The Darts-IP link is a gated commercial database; my searches did not surface its contents, and the badge does not say which family member was asserted. Note that the family members are US 7,587,512, US 8,224,983 (from US 12/753,390) and US 8,661,153 (from US 12/506,140) — a suit asserting any of these could trigger the family-level flag.

Because the badge is family-level, do not treat it as proof that 7,587,512 itself was asserted. It is a lead, not a case citation. This is the single most important caveat in this report.

2. Negative results (searched, not found)

3. Ownership history as litigation-context evidence (circumstantial only)

The assignment chain in the patent record is a recognizable enforcement-portfolio pattern:

• 2005 — Individual inventors → Rocksteady Networks, Inc.
• 2005 — → Eric White (Asset Purchase Agreement)
• 2011–2012 — → Rocksteady Technologies, LLC (assignments/confirmatory assignments tied to Eric White and Kelly Looney)
• 2012 — → RPX Corporation (Assignment of Interest, Aug. 13, 2012)
• 2024 — → Netskope, Inc. (July 5, 2024)

Interpretation, expressly flagged as inference: The 2011 creation of Rocksteady Technologies, LLC as a holding vehicle and the 2012 sale of the portfolio to RPX Corporation — a defensive patent aggregator — is a pattern frequently associated with a short-lived assertion campaign terminated by an aggregator acquisition. That pattern is consistent with the Darts-IP family-litigation badge. However, I did not retrieve any case name, defendant, court, or case number corroborating it, so I cannot state that Rocksteady Technologies (or any other party) ever sued anyone on 7,587,512. Do not treat this paragraph as a litigation finding.

Note also that a 2012 "Separation Agreement" naming Kelly Looney and a 2012 "Confirmatory Assignment" naming Eric White appear in the chain; these are assignment-record documents, not litigation.

4. What I cannot tell you

• Whether 7,587,512 itself was ever asserted (as opposed to a family member).
• Plaintiff(s), defendant(s), jurisdiction, case number, filing date, or outcome for any proceeding.
• Whether the Darts-IP "first worldwide family litigation" is a US district court case, an ITC action, or a foreign proceeding.
• Whether any 2024–2026 assertion exists by Netskope, Inc. (the current assignee). I found no complaint or appeal by Netskope asserting this patent. Given the acquisition appears defensive and the patent is "Expired – Fee Related," adjusted expiration 2025-10-10 (now past), an assertion campaign in 2026 would be unusual — but I did not verify this.

I will not supply case numbers or party names I did not retrieve. Anything not sourced above would be fabrication.

5. Recommended verification steps (the records that would settle this)

1. Darts-IP family 32110205 — the exact link in the patent record: https://patents.darts-ip.com/?family=32110205. This is the authoritative source for the badge and, almost certainly, lists the case(s) directly.
2. PACER / CM-ECF party search for "Rocksteady Networks," "Rocksteady Technologies," and "Eric White" as plaintiff, 2005–2015 — this is the most likely window given the assignment timeline.
3. RPX Insight (insight.rpxcorp.com) — search the patent number; RPX's own portfolio-litigation database would show the assertion history behind its 2012 acquisition.
4. Lex Machina / Unified Patents Portal patent-level litigation view for 7,587,512 (family-level flag vs. patent-level assertions).
5. USPTO Assignment records for reel/frame detail on the 2005 Eric White asset purchase — the APA schedule often names the asserted patents and any pending enforcement.

If any of those surfaces a case, the elements you asked for (plaintiff, defendant, jurisdiction, case number, filing date, outcome/status) would be reportable directly from the docket.

Summary: One credible family-level litigation indicator (Darts-IP 32110205); zero confirmed case-level records for US 7,587,512 retrievable from the sources I searched. Treat the existence of litigation on this patent as unconfirmed pending a Darts-IP/PACER check.

I'll start by checking the canonical structured source and then verifying with targeted searches for any PTAB or Federal Circuit activity.

Let me dig deeper with more targeted searches on the specific patent number and its family.

The direct-number hits so far are all spurious (a Japanese patent, prior-art citation lists). Let me verify from the PTAB docket side and check whether this patent was ever asserted.

Proceedings overview

Zero. The canonical structured source for this analysis — the USPTO Open Data Portal "PTAB proceedings on file" block — returns no AIA trial proceedings (IPR, PGR, or CBM) for US 7,587,512, and my independent web searches on 2026-09-30 surfaced no petition, institution decision, or final written decision naming the patent. Bottom line for a defendant: no claims have been canceled and no claims have been upheld, because no claim has ever been tested at the Board. This is a blank-slate patent at the PTAB, not a hardened one — but note the patent is also expired (see "Timing" below), which materially changes what a PTAB challenge is worth to you.

Because the prompt format asks me to enumerate proceedings "most-impactful first," and there are none, the section below is necessarily a null-result explanation plus the adjacent-proceeding landscape that a practitioner actually needs.

No proceedings to enumerate — and why the search hits are false positives

Several search results contain the string "7587512." None is a PTAB proceeding against this patent. Explicitly:

Conclusion: the structured-data "no AIA trials" answer is corroborated, not contradicted, by the open web. If you are being told this patent "has been through IPR," that claim is unsupported.

Adjacent proceedings worth knowing about (NOT against 7,587,512)

These involve the same owner and, in two cases, the same patent family specification. They are informational, not estoppel-creating for this patent.

IPR2023-00030 — Netskope, Inc. v. Fortinet, Inc. (patent 10,826,941)

• Type: Inter Partes Review
• Status: Final Written Decision issued; claims 1–22 held unpatentable on all grounds. (FWD, oral hearing 2024-02-06; source: Banner Witcoff copy of the FWD)
• Relevance to 7,587,512: none on the merits — this shows Netskope as a successful IPR petitioner against Fortinet, i.e., the two companies are in a two-front patent war, and Netskope is a sophisticated PTAB player on offense.

IPR2025-01115 — Netskope, Inc. v. K.Mizra LLC (patent 8,234,705)

• Type: IPR, filed 2025-08-13, filing date accorded 2025-08-21; institution decision expected ~2026-02, FWD ~2027-02. (Source: W.D. Tex. notice of IPR filings)
• Relevance: again shows Netskope's offensive PTAB posture.

IPR2026-00031 — Fortinet, Inc. v. Netskope, Inc. (patent 8,635,697)

• Type: Inter Partes Review; filed 2025-10-08
• Status: Discretionary denial of institution, 2026-02-03 (petition fee refunded 2026-03-04). Netskope had filed a POPR and a separate discretionary-denial brief. (Source: PTAB docket summary)
• Relevance: the inverse posture — Fortinet attacking Netskope-owned patents. A companion petition, IPR2026-00042, challenges Netskope's 8,543,710 ("Network Access Control"). Neither targets 7,587,512.

PGR2021-00091 / PGR2021-00092 and IPR2021-01045 / IPR2021-01046 — Netskope, Inc. v. Bitglass, Inc.

• FWD in IPR2021-01045 (2022-12-09) determined all challenged claims (1–5, 8–13, 16) of the 10,757,090 patent unpatentable; panel: APJs Mayberry, Trock (author), McShane. (docketalarm copy of FWD)
• Relevance: unrelated patents, but confirms Netskope's track record of winning full-invalidation FWDs.

Strategic summary

Claim status: 100% UNTESTED. No claim of US 7,587,512 has been canceled, confirmed, or even subjected to an institution decision. The four independent claims described in the patent's own Summary (device; CRM-allocation; method; CRM-enforcement — see the earlier summary section, with the caveat that the verbatim 60-claim set was not retrieved) remain exactly as issued on 2009-09-08. Contrast this with a patent that "survived IPRs and is hardened": there is no PTAB record to harden it, and equally no PTAB record to attack.

Estoppel landscape: wide open — but see timing. Because there is no IPR that resulted in a § 318(a) final written decision on any claim of 7,587,512, no § 315(e)(2) estoppel attaches to any party as to this patent. Every prior-art ground — § 102, § 103, and to the extent available § 112 — remains available to a defendant, whether in a district court invalidity defense or in a first-filed IPR. Conversely, the absence of a prior FWD also means there is no petitioner-side benefit to free-ride on: nobody has already paid the cost of proving these claims unpatentable. One caveat: if you are in privity with a party that has already run an IPR on a related family member (e.g., Fortinet's challenges to the Netskope continuations 8,661,153 and 8,224,983), analyze § 315(e)(2) privity carefully — but estoppel is claim-by-claim and patent-by-patent, so an FWD on 8,661,153 does not by itself estop grounds against 7,587,512.

Pattern signals. (i) The current owner, Netskope, Inc. (assignment recorded 2024-07-05 from RPX Corporation), is an aggressive and competent PTAB participant on both sides of the "v." — it has won full-invalidity FWDs as petitioner (Bitglass) and is actively asserting a large portfolio, including 7,587,512's family, against Fortinet in Netskope, Inc. v. Fortinet, Inc., No. 4:25-cv-02360-HSG (N.D. Cal.) (CourtListener docket). (ii) RPX was in the chain (2012–2024). Note that Fortinet has argued in its Netskope IPRs that RPX is "a defensive patent aggregator—its business model is to effectively take patents off the market," so Netskope's 2024 acquisition and rapid assertion cuts against any "settled expectations" discretionary-denial argument. (iii) No defensive aggregator appears to have challenged 7,587,512 — I found no Unified Patents or similar filing. (iv) Notably, Netskope's Fortinet complaint lists asserted patents including 8,224,983 and 8,661,153 — both continuations of 10/687,002 — but not 7,587,512. That is consistent with 7,587,512 being at/near the end of its term.

Timing — the dispositive practical point. Per the patent record, US 7,587,512 was Expired – Fee Related, with an adjusted expiration of 2025-10-10. As of today (2026-09-30) the patent has expired. An expired patent can still be the subject of a PTAB trial on claims that could support past damages, but the recovery window is compressed by 35 U.S.C. § 286 (six years pre-complaint), and the Netskope/Fortinet litigation has already seen arguments that certain family patents "were expired at the time Netskope notified it of these patents in a November 2024" letter. Before spending on a petition, confirm (a) the precise expiration/terminal-disclaimer status on the face of the granted patent and in PAIR, and (b) whether any live assertion of 7,587,512 actually exists. I could not confirm that 7,587,512 has ever been asserted in litigation — Google Patents flags the family as having litigation (Darts-IP family 32110205), but I could not retrieve case names tying that flag to this specific patent.

Recommended next steps

1. State the null result plainly in any opinion or memo: "US 7,587,512 has no AIA trial history. No IPR, PGR, or CBM petition has ever been filed against it; no claim has ever been canceled or confirmed by the Board." Do not let a demand letter imply otherwise, and do not assert it has "survived challenges."

2. Run the authoritative confirms yourself, because my search hit its step limit: search PTAB E2E / the PTAB Decisions page and PatentCenter for application 10/687,002 and patent 7,587,512; cross-check the ODP API result returned in the structured block (no proceedings). Also check the Federal Circuit docket and CourtListener for any appeal — with no FWD there can be no appeal of an FWD, so any CAFC hit would necessarily arise from the district court case, not the Board.

3. If you are a defendant facing assertion: there is no FWD to link to and no canceled claim to quote — the "sanction-bait" scenario does not exist here, but neither does a free win. Your defenses are (a) ordinary district-court invalidity, with the entire prior-art universe open and no § 315(e)(2) estoppel, and (b) expiration / damages-window arguments under § 286, which may be the cleanest disposition given the 2025-10-10 adjusted expiration. If you file an IPR, the § 315(b) one-year bar runs from service of the first complaint asserting this patent, and the § 316(a)(11) one-year FWD clock runs from institution — but weigh that against the limited remaining damages exposure on an expired patent.

4. If no IPR exists and you were hoping one would define the claim scope: the absence is itself the signal — this patent was never commercially significant enough, or was too close to expiry, to attract a Board challenge. But note the family is being actively litigated (Netskope v. Fortinet, N.D. Cal. 4:25-cv-02360-HSG), so the same specification's claim construction is being developed — monitor that docket for constructions that could bear on the 7,587,512 claims if it is ever asserted.

Confidence and caveats: I have high confidence in the null result (both the canonical ODP block and my searches agree) and high confidence that each "7587512" search hit is a false positive (I read each and confirmed the mismatch). I have lower confidence on: the exact issued-claim numbering of the four independents (inherited caveat from the earlier summary), whether 7,587,512 has ever been asserted in litigation, and the current live status of the Netskope/Fortinet proceedings beyond the documents quoted. Treat items 2 and 4 above as work still to be verified against primary sources.

I'll attempt to verify the assignment record against live sources before reconstructing the chain.

Excellent — this surfaced a Netskope→Fortinet assertion campaign. Let me dig into the specifics.

The Netskope→Fortinet campaign is confirmed. Now I need the actual reel/frame records. Let me search further.

Assignment Record Reconstruction — US 7,587,512

Method note / material limitation (read first). The USPTO Assignment Center (assignmentcenter.uspto.gov) is an interactive JavaScript application; I could not execute a live patent-number query against it, and no indexed mirror I reached exposes the reel/frame numbers or the correspondent of record for this patent. What I do have is (a) the assignment legal-events feed reproduced in the Google Patents record, and (b) PTAB filings in Fortinet v. Netskope that quote USPTO assignment records for sibling patents in this same transaction. Those sources give me conveyance type, assignor, assignee and recording dates — but no reel/frame and no correspondent. I am flagging that gap rather than inventing reel numbers. Signal 3 (repeat correspondent) therefore cannot be scored and is reported as unverified, not as absent.

Inventors

Basis for the employer attribution: all four executed the assignment of interest to Rocksteady Networks, Inc. (recorded 2005-07-21), and the specification names "the Rocksteady NSA Server, from Rocksteady Networks, Inc. of Austin, Tex." as the exemplary control device. The application was filed 2003-10-16 with the inventors as the original applicant ("Individual" per Google Patents), not the company — the company assignment was not recorded until July 2005, ~21 months after filing.

Unusual patterns — two, both meaningful:

1. The inventor→company assignment and the company's asset sale were recorded on the same day (2005-07-21). On that date Rocksteady Networks, Inc. took the inventors' rights and conveyed its assets to Eric White under an Asset Purchase Agreement. Papering the in-bound and out-bound legs simultaneously is the signature of a wind-down/sale closing, not of routine employee onboarding. Any due-diligence file should treat the July 2005 date as the effective end of Rocksteady Networks as an operating patent holder.

2. A seven-year title defect involving Kelly Looney. Looney — an inventor — had to be cleaned out of the chain twice in 2012: a Separation Agreement recorded 2012-06-15 (Looney → Rocksteady Networks, Inc.) and a Confirmatory Assignment recorded 2012-07-16 (Looney → White). A confirmatory assignment from an inventor seven years post-issue indicates the original 2005 conveyance did not capture his interest. This is a classic pre-sale title cure.

Low-confidence side note: Patent Leaderboard groups Clendinning's eight patents (including 7587512) under PayPal — I could not verify why, and it appears inconsistent with the recorded chain (current assignee is Netskope). Treat as unverified; it may be a leaderboard attribution artifact.

Original assignee

Rocksteady Networks, Inc., Austin, Texas — maker of the Rocksteady NSA Server, a network access-control / per-user bandwidth appliance. The patent's own specification points to that product as the commercial embodiment, so the claims were product-backed at the original assignee (not a paper-only origin).

• Primary line of business: network access control and bandwidth-shaping appliances for public wired/wireless LANs (the café/hotspot and enterprise-guest-access use case recited in the Background).
• Current status: no evidence of continued operation. Its patent assets were sold to Eric White under an Asset Purchase Agreement recorded 2005-07-21. I found no SEC filing (it was private), no bankruptcy docket, and no dissolution record — so "dissolved/defunct" is a reasonable working conclusion but is not independently confirmed. Call it assets sold; status unverified.

Discrepancy flag (cross-reference to the earlier section): the prior section's table lists the assignee as printed on the granted face as "Eric White, Austin, TX," while Google Patents' structured field says original assignee = "Individual" and current assignee = Rocksteady Networks Inc / Netskope Inc. These are reconcilable (the inventors were the original applicant; White was assignee of record by the 2005 APA by the time of the 2009 issue), but I could not inspect the printed front page directly. Minor unresolved inconsistency — verify against the granted face before quoting either version.

Assignment timeline

Dates below are recording dates as published in the Google Patents legal-events feed. Execution dates were not retrieved and may precede them by days to weeks. Reel/frame values and correspondent names were not obtainable — no values are asserted for them.

• rec. 2005-07-21 — Reel NNNNNN/NNNN — not retrieved

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Clendinning, Kerry; Ta, Tuan; Turley, Patrick (and Looney, Kelly, per the 2012 cure records)
  • Assignee: Rocksteady Networks, Inc.
  • Correspondent: not retrieved — this is the entry to pull first; it identifies the firm that ran Rocksteady's original paper.
  • Context: In-bound IP conveyance from the founding inventors to the operating company, recorded at the same closing as the company's asset sale.

• rec. 2005-07-21 — Reel NNNNNN/NNNN — not retrieved

  • Conveyance: Asset Purchase Agreement
  • Assignor: Rocksteady Networks, Inc.
  • Assignee: Eric White (Austin, TX)
  • Correspondent: not retrieved
  • Context: Fire-sale / asset wind-down of the original operating company — the patent leaves the entity that built and sold the product.

• rec. 2011-01-27 — Reel NNNNNN/NNNN — not retrieved

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Eric White
  • Assignee: Rocksteady Technologies, LLC
  • Correspondent: not retrieved
  • Context: Internal reorg / holding-entity placement — White moves the asset from personal name into a company of near-identical name. Note "Rocksteady Technologies, LLC" is a different legal entity from "Rocksteady Networks, Inc."

• rec. 2012-06-15 — Reel NNNNNN/NNNN — not retrieved

  • Conveyance: Separation Agreement
  • Assignor: Kelly Looney
  • Assignee: Rocksteady Networks, Inc.
  • Correspondent: not retrieved
  • Context: Title-defect cure part 1 — an inventor's interest belatedly conveyed, executed against an entity whose assets had already been sold seven years earlier.

• rec. 2012-06-28 — Reel NNNNNN/NNNN — not retrieved

  • Conveyance: Confirmatory Assignment
  • Assignor: Eric White
  • Assignee: Rocksteady Technologies, LLC
  • Correspondent: not retrieved
  • Context: Title-defect cure part 2 — confirms the 2011 internal transfer in anticipation of sale.

• rec. 2012-07-16 — Reel NNNNNN/NNNN — not retrieved

  • Conveyance: Confirmatory Assignment
  • Assignor: Kelly Looney
  • Assignee: Eric White
  • Correspondent: not retrieved
  • Context: Title-defect cure part 3 — back-fills Looney's chain so the seller's title runs clean to White.

• rec. 2012-08-13 — Reel NNNNNN/NNNN — not retrieved

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: Rocksteady Technologies, LLC
  • Assignee: RPX Corporation
  • Correspondent: not retrieved — priority pull; RPX's recording counsel identifies the aggregator's standard outside firm.
  • Context: Defensive aggregation — sale of the family to RPX, a defensive patent aggregator.

• rec. 2018-06-29 — Reel NNNNNN/NNNN — not retrieved

  • Conveyance: Security Interest
  • Assignor: RPX Corporation
  • Assignee: Jefferies Finance LLC
  • Correspondent: not retrieved
  • Context: Securitization / credit facility collateral — portfolio pledged against RPX corporate debt. Not a change of ownership.

• rec. 2020-10-23 — Reel NNNNNN/NNNN — not retrieved (appears twice in the feed, two entries)

  • Conveyance: Patent Security Agreement
  • Assignor: RPX Clearinghouse LLC; RPX Corporation
  • Assignee: Barings Finance LLC, as Collateral Agent
  • Correspondent: not retrieved
  • Context: Securitization / refinancing — new collateral agent replaces Jefferies. Duplicate feed entries are typical of multi-document collateral filings.

• rec. 2020-10-26 — Reel NNNNNN/NNNN — not retrieved

  • Conveyance: Release of Security Interest
  • Assignor: Jefferies Finance LLC
  • Assignee: RPX Corporation
  • Correspondent: not retrieved
  • Context: Lien release — discharge of the 2018 Jefferies security interest at refinancing.

• rec. 2024-05-31 — Reel NNNNNN/NNNN — not retrieved

  • Conveyance: Release of Security Interest in Specified Patents
  • Assignor: Barings Finance LLC
  • Assignee: RPX Corporation
  • Correspondent: not retrieved
  • Context: Lien release on specifically identified patents — the "specified patents" carve-out signals a portfolio carve-out sale was in motion; this release clears the encumbrance on the patents being sold.

• rec. 2024-07-05 — Reel NNNNNN/NNNN — not retrieved

  • Conveyance: Assignment of Assignors' Interest
  • Assignor: RPX Corporation
  • Assignee: Netskope, Inc.
  • Correspondent: not retrieved — highest-value pull in this chain; the recording attorney here is the counsel for Netskope's assertion program.
  • Context: Transfer out of a defensive aggregator to an operating-company asserter. Corroborated by PTAB exhibits in IPR2026-00031 / IPR2026-00042, which enter "July 1, 2024 Assignment of the '697 ['936] patent from RPX to Netskope" into evidence. The execution date is July 1, 2024; the recording date is July 5, 2024 — a batch sale of multiple patents from this same Rocksteady/Netskope family on one date.

Chain-of-title summary: inventors → Rocksteady Networks, Inc. (2005) → Eric White (2005 APA) → Rocksteady Technologies, LLC (2011) → RPX Corporation (2012) → [Jefferies 2018 → Barings 2020 → releases 2020 & 2024] → Netskope, Inc. (exec. 2024-07-01 / rec. 2024-07-05).

Timeline diagram

timeline
    title Ownership of US 7587512
    2002 : Provisional filed by Clendenning et al
    2003 : Nonprovisional filed
    2005 : Inventors assign to Rocksteady Networks Inc
         : Rocksteady sells assets to Eric White
    2009 : Patent issues
    2011 : White assigns to Rocksteady Technologies LLC
    2012 : Looney separation and confirmatory assignments
         : Rocksteady Technologies sells to RPX Corporation
    2018 : Jefferies Finance security interest recorded
    2020 : Barings collateral security recorded
         : Jefferies security interest released
    2024 : Barings release for specified patents
         : Netskope Inc acquires the family from RPX
    2025 : Netskope sues Fortinet over family patents

NPE / troll-pattern signals

Documentary corroboration for the 2024 leg (worth citing in any file): PTAB petition papers in IPR2026-00031, IPR2026-00042 and petitions 1558590 / 1558594 enter USPTO assignment records into evidence and state that Netskope "acquired the patent on July 1, 2024 to assert against Petitioner shortly thereafter" and that Netskope "has readily admitted in district court that it does not practice" the acquired patents and "has not licensed or otherwise commercialized" them. Source: https://ptacts.uspto.gov/ptacts/public-informations/petitions/1558594/download-documents — and the parallel district-court docket at https://www.courtlistener.com/docket/69716023/1/netskope-inc-v-fortinet-inc/

Verdict

Operating-company assertion.

The chain terminates at Netskope, Inc. (executed 2024-07-01, recorded 2024-07-05), a large operating cloud-security vendor — not an NPE — and Netskope is presently litigating the same patent family against a named competitor, Fortinet, in N.D. Cal. 4:25-cv-02360-HSG with parallel IPRs (IPR2026-00031, IPR2026-00042). That is the operating-company-assertion fact pattern, not a troll pattern. Two qualifications that materially weaken the clean verdict, and that any reader should carry forward: (i) US 7,587,512 is not itself an asserted patent — only its continuations '983 and '153 are — so the assertion activity reaches this patent only through family lineage; and (ii) the twelve-year RPX holding (2012-08-13 → 2024-07-05) was a defensive-aggregation period that ended when RPX carved out "specified patents" and sold the family to an acquirer that, by its own litigation admissions, does not practice these acquired patents. If signal 3 later resolves to a repeated correspondent tying the 2011-01-27, 2012-08-13 and 2024-07-05 recordings together, the verdict should be revisited toward NPE — moderate confidence.

Verify against: USPTO Assignment Center, https://assignmentcenter.uspto.gov/ (query patent number 7587512; also mirrored at https://assignment.uspto.gov/patent/index.html). Request the assignment abstracts of title for application 10/687,002 and the continuations 12/506,140 and 12/753,390, and capture reel/frame + correspondent for each of the 13 events above — that is the missing input this reconstruction could not obtain.

I'll search for the USPTO record and the cited prior art references for US 7,587,512.

Let me get the actual cited-references list from the patent's own front-page record.

Prior-Art Analysis — US 7,587,512 B2

Search performed: USPTO / Google Patents / uspto.report / FreePatentsOnline / Justia for the literal identifier 7587512 (and, where necessary, its application number 10/687,002). Results for numerically similar but distinct patents (e.g., 7,587,124 / 7587124 — Horiuchi et al., which coincidentally issued the same day, Sept. 8, 2009) were excluded, as instructed. Family members 8,661,153 and 8,224,983 are continuations of '512, not prior art, and are excluded from the anticipation analysis.

0. Up-front accuracy statement (important)

I must be explicit about the limits of what I retrieved, per the operating rule against fabrication:

• ✅ I confirmed the patent exists and its bibliographic data (US 7,587,512 B2, "System and method for dynamic bandwidth provisioning," App. 10/687,002, filed Oct. 16, 2003, issued Sept. 8, 2009, priority to provisional 60/418,968 of Oct. 16, 2002).
• ⚠️ I did NOT retrieve a complete, verbatim copy of the front-page "References Cited — U.S. Patent Documents" list for '512. My searches returned citation tables belonging to other patents in the same field (which merely happen to cite '512 in their "Cited By" columns). I flag this because the citation tables I surfaced are easy to misattribute.
• ⚠️ I did NOT retrieve the issued 60-claim set verbatim. Claim-number mapping below is therefore expressed in terms of the four independent-claim families described in the patent's own Summary of the Invention (device / CRM-allocate / method / CRM-enforce), consistent with the previously generated sections. Do not treat the claim numbers as verified.
• ⚠️ One retrieved "References Cited" listing (via uspto.report) contains documents that postdate the Oct. 16, 2002 priority date — including the application's own PCT publication, WO 2004/036371. That is a hallmark of a foreign search report / family annex, not a front-page US reference list. I therefore treat that listing as provisional and possibly belonging to a family member rather than to '512 itself.

Because of these gaps, Section 3 distinguishes (A) references I can tie to the '512 record with reasonable confidence from (B) field-relevant art that I believe is the strongest §102 candidate material but that I could not confirm is cited on the face of '512.

1. The §102 legal frame specific to this patent

This matters for grading each reference, and it is easy to get wrong here:

• Critical date: the provisional (60/418,968) was filed Oct. 16, 2002; the non-provisional/PCT was filed Oct. 16, 2003. Any reference relied on for §102(a)/(b) must predate Oct. 16, 2002 (or Oct. 16, 2003 under §102(b) for the actual filing).
• Consequently, the foreign documents dated 2003–2005 in the retrieved list (WO 03/021890 [Mar 2003], WO 03/098461 [May 2003], WO 04/034229 [Apr 2004], WO 04/036371 [Apr 2004], WO 05/020035 [Mar 2005]) cannot be §102(a)/(b) art against '512. Their presence reinforces that this listing is not a clean front-page art list for '512.
• The PCT publication WO 2004/036371 A2 is this very application's own publication (PCT/US2003/032912) and is a family member, not prior art.

2. References I could tie to the '512 record (Section A)

A-1. Foreign patent documents appearing in the retrieved "References Cited" block

Caveat: I did not retrieve the subject matter of EP 0 587 522 or the 2001–2002 WO documents, so I cannot substantively map them to claims. I am reporting that they appear as cited documents and their dates, nothing more.

A-2. "Other References" (non-patent literature) — these are the strongest verifiable §102(b) printed publications

Anticipation assessment for Section A: None of these references, as retrieved, discloses the full combination recited in the independent-claim families — i.e., (i) retrieve a set of user profiles → (ii) establish per-user bandwidth limits → (iii) regulate each user's usage against the limit → (iv) update the limit. The 2003 trade-press items disclose public wireless LANs and wireless gateways, i.e., the deployment context, but not per-user dynamic bandwidth reallocation. On the retrieved text, no Section-A reference is a clean §102 anticipation of the device/method/CRM claims; several are relevant only under §103 or as background.

3. The strongest §102 candidate art for '512 (Section B — inferred, NOT confirmed as cited on the face)

Because I could not retrieve '512's U.S. reference list, the following are the references I judge most likely to be the substantive §102 art for a patent of this scope, based on the field. I explicitly flag each as unconfirmed as a citation on '512. They surface repeatedly in the citation neighbourhood of the '512 family and of contemporaneous bandwidth-provisioning patents (e.g., they appear in the citation tables of US 2009/0064252 and US 2010/0002723, both of which cite '512):

Anticipation analysis (if these are indeed the cited art): Even these references are unlikely to be clean §102 anticipations, because the '512 claims require updating the bandwidth limit dynamically (new users, excess capacity, time-of-day, utilization averaging, or mid-session re-provisioning without re-authentication). The more probable attack posture is §103 (e.g., Byers' per-subscriber control + an admission-control reference such as Bradd). I emphasize: I could not verify that any of these four is cited on the face of '512, and I could not verify the issued claim language. Treat them as leads for a validity study, not findings.

4. Mapping to claims (with the required caveat)

Using the four independent-claim families from the patent's own Summary (claim numbers unverified — I did not retrieve the 60-claim set):

Bottom line on anticipation: On the record I could retrieve, I did not identify a single reference that anticipates any independent claim of '512 under §102. Every candidate is missing at least the dynamic-update / per-user-reallocation element that the specification treats as the point of novelty (FIG. 5–6D; Eq. 1–2; the "update the at least one bandwidth limit" language in every Summary embodiment). Any realistic invalidity theory would be a §103 combination, not §102.

5. Cautions and verification steps

1. Do not attribute the citation tables I surfaced to '512. Tables containing US 5,920,701 / US 6,975,594 / US 7,397,763 that also list '512 are the citing patents' tables (Embarq/CenturyLink documents), not '512's own reference list.
2. Excluded by instruction: US 7,587,124 (Horiuchi, same issue date) and other near-numbered patents.
3. To get an authoritative reference list, the authoritative sources are: the USPTO PatentCenter / Patent Full-Text (USPAT) record for 10/687,002, the scanned front page of US 7,587,512 B2, and PAIR "References Cited". I could not open those directly in this session.
4. Verify the issued claims at col. 10 et seq. of US 7,587,512 B2 before relying on any claim-number mapping. My claim mapping is by independent-claim family only.

If you can supply (a) the scanned front page / "References Cited" section of US 7,587,512, or (b) the issued claim set, I can convert the low-confidence section above into a reference-by-reference, claim-by-claim §102 table with specific column/line citations.

I'll research the prior-art landscape for US 7,587,512 before constructing the § 103 combinations.

Key new material surfaced — the granted claims and cited references. Let me dig into the prior-art citations and the PTAB proceedings.

Let me verify the cited references and the full claim set.

Obviousness Analysis under 35 U.S.C. § 103 — US 7,587,512 B2

Analyst note on sources. The "Prior Art section of this page" is taken to be (a) the face-of-patent "References Cited" list retrieved from the granted document (https://patentimages.storage.googleapis.com/62/9a/4f/209e3fb6df34cd/US7587512.pdf, which prints the U.S. patent citations and EP 0587522 B1, plus the International Search Report for PCT/US03/32912), and (b) the specification's own admissions of known art (https://patents.google.com/patent/US7587512/en). I could retrieve only partial reference disclosures; where I attribute disclosure to a reference, I say whether it is grounded in retrieved text or in general knowledge of the art, and I flag every item needing full-text verification. This is an analytical work product, not a validity opinion, and every ground must be re-verified against the reference texts and an expert declaration before filing.

1. Governing law and date framework

Application 10/687,002 was filed October 16, 2003, with provisional priority to October 16, 2002 (App. 60/418,968). This is a pre-AIA case (AIA §§ 102/103 apply only to applications filed on/after March 16, 2013). Accordingly:

• Prior art must predate Oct. 16, 2002 (§102(a)/(b)/(e)), or Oct. 16, 2003 for §102(e) art claiming earlier priority.
• Pre-AIA § 103(c) disqualifies, for obviousness purposes, art that is §102(e)/(f)/(g) art and commonly owned at the time of invention. This matters for the incorporated "Access Control Application" (U.S. App. 10/683,317, Mackinnon et al., filed Oct. 10, 2003), which the '512 expressly incorporates by reference. Technically it pre-dates the '512 filing by six days and could qualify as §102(e) art, but it is a Rocksteady-family application and should be treated as §103(c)-disqualified absent evidence the common-ownership condition fails. Do not build a primary ground on it — at most it evidences the state of the art if an unbroken chain of public availability can be shown.

I could not retrieve the full file wrapper; the granted PDF shows an "Office Action issued in U.S. …" passage, so a file history exists and should be pulled (see §9).

2. Level of ordinary skill (PHOSITA)

A person having ordinary skill in the art at the 2002 priority date would hold a B.S. in computer science or electrical engineering (or equivalent) plus roughly 2–3 years of experience in IP network operations, QoS/traffic engineering, or network access control — or a master's degree with less experience. That person would be familiar with:

• IP packet forwarding, MAC/IP addressing, and header-based classification;
• Authentication/authorization infrastructure: RADIUS (RFC 2865/2866, June 2000) and LDAP, and the fact that these return per-user authorization attributes;
• Traffic conditioning primitives: token-bucket/leaky-bucket policing and shaping, Weighted Fair Queueing (WFQ), Class-Based Queueing (Floyd & Jacobson, 1995), and the Linux tc/iproute2 toolset with iptables — which the '512 specification itself names as known art;
• Commercial per-flow/per-class bandwidth managers (e.g., the Packeteer PacketShaper class of appliances) and WLAN hotspot gateways (Bluesocket, Vernier, ReefEdge class products).

This is a "combination of known elements" case. Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), the question is not whether each limitation is separately novel but whether the claimed combination was predictable in view of the prior art and the design incentives confronting the artisan.

3. The claims at issue (as retrieved)

The granted document's claims include:

• Claim 1 (device): processor; first and second network interfaces; storage medium with instructions to (i) retrieve a set of user profiles, each corresponding to a specific user; (ii) establish at least one network bandwidth limit per user based on that user's profile; (iii) regulate network bandwidth usage per user against that limit; (iv) retrieve a first user profile from an authentication database based on user credentials; (v) initiate a control session; (vi) establish user-specific rules and conditions bound to the user during the control session based on the user device and the user credentials; and (vii) dynamically update the limit for at least one user to account for the first user gaining access to the second network.
• Claims 2–3: dynamic update for each user / to account for a new user connecting.
• Claim 19 (device, separate independent): includes prioritiz[ing] network bandwidth allocations for networked applications based on the user profile.
• Dependent claims visible: 20 (dynamic update for each user), 22 (time of day), 25 (meter bandwidth per user), 28–30 (indexing by MAC address and/or IP address), 31/33 (accessing a traffic control rule with upload / download limit; determining if exceeded), 32/34 (wireless network), 35 (per-user session monitoring), 36 (application prioritization).
• Claim 37 (method): the same sequence in method form ("at a control device … retrieving a set of user profiles from an authentication database … based on user credentials … establishing user specific rules and conditions bound to each user during a control session … dynamically updating").
• Claims 63–66: further method claims including "determining if a network communication is associated with an authenticated user."

Contradiction flag: the earlier generated summary states "60 claims," but the retrieved record shows claim language and claim numbering running through claim 66 ("The method of Claim 63, further comprising determining if a network communication is associated with an authenticated user…"). Either the '512 has ~66 claims (and the "60" figure is wrong), or the claim-66 text belongs to a different family member (US 8,224,983 / US 8,661,153 share this specification). This must be resolved against the granted document before any claim-specific reliance. Also, the earlier summary's statement that no PTAB proceeding involves this family is now in tension with retrieved PTAB petition documents (1558604, 1558605) that reproduce this specification verbatim and list "7587512" in an exhibit list (see §9).

4. Ground of rejection #1 — AAPA (admitted prior art) + RADIUS/directory per-user attributes

References combined:

1. Applicant Admitted Prior Art ("AAPA") from the '512 specification itself: use of "the Linux based Traffic Control application" configured to access "traffic control rules through an IP table," with rules "indexed" by MAC address and IP address and associated with a user "through any arbitrary identifier." The specification states this is an existing facility ("One example of a traffic conditioning module that can be configured to access traffic control rules through an IP table is the Linux based Traffic Control application"). It also admits "IP tables are essentially tables of rules that can be accessed by applications, such as a firewall," and that "Any bandwidth metering scheme known in the art can be used."
2. RADIUS (RFC 2865 / RFC 2866) and directory services (LDAP, Active Directory, TACACS+) — named in the specification as known "example authentication technologies," each of which returns per-user authorization attributes (e.g., RADIUS Filter-Id and vendor-specific rate attributes).
3. Optionally, US 6,130,892 (Short et al.) — a per-subscriber data-transfer-management patent cited on the '512 face, directed to "associating a data transmission parameter with the user device," receiving a packet, and delaying/dropping based on that parameter (grounded in the retrieved record of the Short/Nomadix family, e.g. https://patentimages.storage.googleapis.com/d6/40/37/36fa46d8767cd0/US8626922.pdf, which cites 6,130,892).

Mapping to claim 1:

Motivation to combine. Both references are in the same field (IP access control and QoS) and address the identical problem the '512 identifies in its own Background: a shared uplink where one user starves the others. A POSITA already using an AAA server to authenticate users has an express design incentive (and effectively no technical barrier) to carry the user's authorization attributes — including a bandwidth entitlement — from the same server into a shaping rule, because the AAA protocol already returns per-user attributes and the shaper already keys rules on MAC/IP. KSR: "the combination of familiar elements according to known methods is likely to be obvious when it does no more than yield predictable results."

5. Ground of rejection #2 — per-user shaping + dynamic reallocation upon admission of a new user

References combined: AAPA + US 6,130,892 (Short et al.) + US 5,953,506 (Kalra et al., Sept. 7, 1999) and/or the other bandwidth-allocation references of record on the face (US 6,108,782 (Fletcher et al.), US 6,157,953 (Chang et al.), US 6,092,200 (Muniyappa et al.), US 6,088,451 (He et al.), EP 0587522 B1 — the last cited via the International Search Report for PCT/US03/32912).

What these supply (subject to full-text verification — I retrieved the citation list, not the disclosures): the concept of allocating/reallocating bandwidth dynamically among competing flows or subscribers, and of queue management/policing to enforce an allocation (drop or queue). This is the very problem the '512 concedes was unsolved only "on a per-port basis": the Background admits prior systems provisioned by port and could not "reprovision bandwidth to particular users as more users are added to the same port."

Motivation. Once per-user (rather than per-port) identities are available — which Ground #1 supplies — the remaining step is arithmetic bookkeeping over a known resource pool, i.e., re-computing each user's share when a new user is admitted. This is the classic admission-control operation. The '512's own "weighted competition" formula (Eq. 1: W = Σwᵢ; Eq. 2: eᵢ = aᵢwᵢ/W) is an ordinary proportional/fair-share allocation; weighted fair sharing was well known (WFQ, CBQ). A POSITA implementing dynamic admission re-allocation would predictably arrive at claims 2 and 3 ("update … to account for a new user connecting to the device").

Teaching away? None identified. The prior art pointed toward finer-grained (per-subscriber, per-flow) enforcement, i.e., toward the claimed solution.

6. Ground of rejection #3 — dependent claims

7. Reasons to combine, stated in KSR/Ball Aerosol form

1. Common field and common problem. All references are in IP bandwidth management/access control and address link congestion/fairness — the same problem the '512's own Background frames.
2. Combination of known elements with predictable results. Authentication infrastructure (per-user attributes) + address-keyed packet classification + token-bucket shaping + proportional re-allocation. The result — one user cannot starve the link — is precisely the predictable outcome.
3. Finite, identified, predictable solutions. For enforcing a per-user rate cap, the art recognized essentially a closed set: drop, mark/downgrade, or queue/delay. The '512 selects drop-or-queue, both expressly conceded as known in its own text.
4. Design incentive / market pressure. Public wireless LANs (cafés, hotels, campuses) create a direct commercial need to meter and cap per-patron bandwidth and to re-sell upgraded tiers mid-session — the very "pays for more bandwidth during a session" example in the '512. This supplies a concrete motivation to (a) attach bandwidth to the user account and (b) let the AAA/backend system push an updated value without re-authentication.
5. Reasonable expectation of success. Because tc rules could be modified at runtime and were referenced (not embedded) in the iptables rule, a POSITA would expect to change a user's cap without disturbing the rest of the ruleset — the '512 treats this as an advantage, but it is a straightforward consequence of the referenced-rule architecture the specification concedes as prior art.

8. Secondary considerations / objective indicia

I found no evidence in the retrieved record of nexus-bearing objective indicia (unexpected results, industry praise, copying, licensing-due-to-merit, long-felt but unsatisfied need, or failure of others). The Background's "long-felt need" narrative is applicant's own attorney argument and is contradicted by the specification's simultaneous admission that shapers and per-user AAA existed — it tends to cut against non-obviousness. Likewise, the admitted "advantage" of updating limits "without requiring User A to reauthenticate" is an expected benefit of referencing, rather than embedding, the rule.

The RPX portfolio report (https://www.rpxcorp.com/wp-content/uploads/sites/6/2018/10/RPX-Patent-Portfolios-Report_October-2018.pdf) lists US 7,587,512 in the Rocksteady portfolio (NAC/IDS/identity-based QoS). Portfolio aggregation is not secondary-considerations evidence of non-obviousness.

9. Weak points, and what a Patent Owner would argue

Be candid about where the claims are strongest:

1. The "bound to the user … based on the user device and the user credentials during a control session" limitation (claim 1 element (vi); claim 37). A patent owner will argue this is a specific binding of the rule to a mobility-independent user identity, deliberately decoupled from the physical port — precisely the deficiency the Background attacks. The obviousness case here must show that binding AAA session state to a packet-classifier rule keyed on device address was itself known or obvious (Ground #1's AAPA does much of this, since the spec admits rules indexed by MAC + IP + session username).
2. Claim 37's "from an authentication database" recitation narrows the claim relative to the profile-only Summary. Any ground must map credentials → authentication database → returned profile, which RADIUS does, but the mapping should be documented with the RFC text and a POSITA declaration.
3. Claim-construction questions (Do the "first/second network interface" elements require distinct physical interfaces? Does "dynamically update … to account for the first user gaining access" encompass updating other users' limits?) should be resolved before relying on any ground.
4. Pre-AIA §103(c) knocks out the most convenient Rocksteady-internal art (the '317 Access Control Application). Don't build on it.

Verification steps I could not complete (and which materially affect this analysis):

• Pull the full granted claim set (the retrieved record shows claims 1–3, 19–38, 63–66 in fragments; the previously stated "60 claims" conflicts with claim-66 text — resolve via https://patents.google.com/patent/US7587512/en and the granted PDF).
• Pull the prosecution history ("Office Action issued in U.S. …" appears in the granted PDF) to see what art the Examiner applied and what overcame it.
• Pull the International Search Report for PCT/US03/32912 (cited on the face) — its citations (e.g., EP 0587522 B1) reflect the ISA's closest-art view and are the natural starting references.
• Obtain full texts of US 6,130,892; 5,953,506; 6,108,782; 6,157,953; 6,092,200; 6,088,451 — I retrieved the citation list, not the disclosures, and I have not attributed specific passages to them beyond their evident subject matter.
• Resolve the PTAB question. PTAB petition 1558604 reproduces this specification's "Disclosure of the Invention" verbatim alongside a claim 66, and petition 1558605 contains an exhibit page listing "7587512" with a Fortinet exhibit (EX1002). This is in tension with the earlier generated section's statement that the PTAB hits are only unrelated prior-art exhibit lists, and it may indicate a post-grant proceeding touching this family (or that the '512 is cited as art in a Fortinet proceeding). Retrieve petition 1558604/1558605 from https://ptacts.uspto.gov/ptacts/public-informations/petitions/1558604/ and .../1558605/ to identify the challenged patent and the art relied on.
• PTAB/litigation outcome risk: if a prior PTAB or court decision already addressed the validity of these claims, that record — not this desk analysis — is the controlling starting point.

10. Bottom line

On the retrieved record, the claims of US 7,587,512 are vulnerable to § 103. The patent's own specification concedes the core mechanical elements as known art — address-keyed IP tables, the Linux Traffic Control facility, drop-or-queue enforcement, RADIUS/LDAP/TACACS+ authentication, and per-port bandwidth provisioning. The asserted point of novelty is therefore narrow: placing the bandwidth entitlement in the per-user authentication profile and dynamically re-computing users' limits as the population of connected users changes. Both halves of that proposition were known (per-subscriber data-transfer parameters; dynamic/admission-controlled bandwidth allocation), the combination is of familiar elements performing their known functions with predictable results, and the commercial context (public WLAN hotspots) supplied a clear motivation — so the combination would have been obvious to a PHOSITA under KSR. The two limitations that require the most careful evidentiary development are (i) the session binding of rules to user and device and credentials, and (ii) the "authentication database"-sourced profile in claim 37; those are where a Patent Owner would concentrate its rebuttal.

(Reminder: everything above is grounded in the retrieved record and general knowledge of the art; the reference-disclosure attributions in Grounds #2–#3 require full-text confirmation, and this analysis is not a legal opinion on validity.)