US 7035918

I'll search for authoritative information on US patent 7035918, including USPTO records and any CAFC 2026 docket activity.

Let me search specifically for CAFC 2026 docket activity involving this patent.

Let me do a couple more targeted searches to check for any litigation or 2026 appellate activity.

US Patent 7,035,918 — Analyst Summary

Source of record: USPTO full-text via Google Patents (https://patents.google.com/patent/US7035918/en, fetched for this analysis) and FreePatentsOnline (https://www.freepatentsonline.com/7035918.html). Where these two conflict on details, I flag it below.

---

Bibliographic Data

Uncertainty note on assignee: Google Patents lists current assignees as the two Thales DIS CPL entities, while the patent face (per FPO) shows SafeNet Canada, Inc. These are consistent with a chain of assignment/merger (Rainbow Technologies → SafeNet → Thales). I have not independently verified the current chain of title beyond the Google Patents assignment history.

---

Abstract

"A system for managing licenses for protected software on a communication network is disclosed. The system comprises at least one client computer and a pool of license servers coupled to the communication network. The client computers request authorizations to use the protected software. The pool of license servers are programmed for managing a distribution of allocations to use the protected software. Within the pool of license servers is a current leader server programmed for managing the distribution of allocations for the license servers in the pool, and at least one follower server programmed for managing the distribution of allocations for that particular follower server. Each license server stores a status of the allocations for that particular license server, and each follower server communicates the status of the allocations for that particular follower server to the current leader server. Each follower server is capable of becoming a new leader server if the current leader server can no longer manage the distribution of allocations for the license servers."

---

Plain-Language Overview of the Independent Claims

The patent has three independent claims: 1, 7, and 9. (Claims 2–6 depend on claim 1; claim 8 depends on claim 7.) All three share a common core: a pool of license servers with a leader/follower structure for distributing software-license "allocations," plus a heartbeat mechanism between clients and servers for detecting server failure.

Claim 1 — System (leader/follower pool + client heartbeat failover).
A system with (a) at least one client computer and (b) a pool of license servers, where each server manages a distribution of allocations and keeps a record of that distribution. One server is the current leader and maintains a record of allocations for all servers in the pool; the rest are followers, each storing and reporting its own status to the leader. Any follower can become a new leader if the current leader can no longer manage the distribution; and upon such a selection, the new leader receives each server's record of distribution. The servers talk to each other to detect when one can no longer manage allocations. Separately, each client that received an authorization exchanges heartbeats with the server that authorized it; the client determines from those heartbeats whether that server is still working. If it is not, the client locates a new leader server and sends it an "additional heartbeat" that conveys the number of allocations the client needs — effectively a failover re-request.

Claim 7 — Method (the claim-1 workflow as process steps).
The method mirrors claim 1 in method form: coupling client(s) and a pool of license servers to the network; having each server manage allocations and records; selecting one server as current leader (maintaining pool-wide allocation records) and designating the others as followers; selecting a follower as new leader when the current leader can no longer manage distribution; transmitting each server's allocation record to the new leader; detecting (via server-to-server communication) when a server can no longer manage allocations; exchanging heartbeats between clients and their authorizing server; and, for a client whose server has failed, locating the new leader and sending an additional heartbeat conveying the number of allocations required.

Claim 9 — System (follower-election variant using a client-held leader priority list).
Also a leader/follower pool with fans of failure detection and client heartbeats, but it differs from claim 1 in two notable ways: it does not recite the "new leader receives each server's distribution record" step, and instead recites that each authorized client also receives a leader priority list from the authorizing server. When the client determines its authorizing server can no longer manage allocations, it locates another license server using that leader priority list and sends it an additional heartbeat conveying the number of allocations required. In other words, claim 9 puts the failover-routing data (the leader priority list) in the client's hands rather than relying on the leader's pool-wide record.

Common technical thread across all three independents: distributed license allocation management, leader/follower takeover for high availability, server-to-server failure detection, and client-driven heartbeat-based failover with an "additional heartbeat" carrying the number of allocations needed.

---

What the Specification Adds (context for claim interpretation)

• Servers hold identical Redundant License Files (RLFs), each with license codes, a hard-limit/ceiling of allocations, an initial distribution, IP addresses, and a leader priority list; RLFs carry sequence/version numbers so the pool can propagate the newest RLF.
• The leader keeps the global allocation picture; followers track only their own allocations (shown as "X" don't-care cells). Followers report changes to the leader (e.g., available count dropping from 30 to 29).
• Majority rule is disclosed as a security measure (a server will not issue authorizations unless a majority of pool servers are up) to prevent network segmentation from multiplying available allocations. (The specification notes majority rule "may be ignored in alternative embodiments.")
• Preferred pool size is stated as 3 to 11 servers; multiple pools can coexist on one network.

---

CAFC 2026 Docket Search — Result

No authoritative CAFC 2026 (or other) appellate docket activity involving US 7,035,918 was found. Targeted searches for the patent number in combination with Federal Circuit/2026 terms returned no matching docket, opinion, or briefing. The only Federal Circuit material surfaced was unrelated (other patents/cases). I therefore have no basis to report any 2026 CAFC litigation or appeal concerning this patent, and I will not speculate. Note that the patent's recorded status is Expired – Lifetime (adjusted expiration 2021-05-20), which is consistent with the absence of recent enforcement activity, but I did not verify docket status against PACER or the CAFC's own docket directly — only via web search. If you need a definitive docket check, that should be run against PACER/CAFC's official docket system rather than general web search.

Confidence: High on bibliographic data, abstract, and claim content (grounded in the authoritative full text). Low/uncertain on any 2026 litigation — no results found, and I did not access primary docket systems.

I'll research litigation involving US patent 7035918. Let me search multiple sources.

Let me search patent litigation-specific databases.

Let me search more targeted patent litigation sources.

Findings: Litigation Involving U.S. Patent No. 7,035,918

Bottom line: I did not find any known litigation in which U.S. Patent No. 7,035,918 was asserted — as an asserted patent, an invalidity/declaratory-judgment counterclaim target, or an IPR/PGR subject. Based on my searches, no such case appears to exist in the public record.

I want to be explicit rather than fabricate case details, so I am reporting both the negative result and the methodology/caveats.

The patent itself (per the authoritative full text provided)

• Patent: US 7,035,918 B1 — "License management system and method with multiple license servers"
• Application: US 09/648,697; filed 2000-08-25; priority to provisional 60/152,785 (1999-09-03); granted 2006-04-25.
• Assignee chain: Rainbow Technologies, Inc. → SafeNet, Inc. (2007 merger) → Current assignees: Thales DIS CPL USA Inc. / Thales DIS CPL Canada Inc.
• Related family applications (same inventors/priority): Ser. Nos. 09/648,720 ("License Balancing" — issued as US 7,716,348), 09/648,853 ("Selecting a Server in a Multiple Server License Management System"), and 09/648,502 ("Commuter Licensing").
• Legal status (Google Patents): Expired – Lifetime, expired 2021-05-20.

What my searches returned

Searches on "7035918," "7,035,918," "SafeNet 7035918 litigation," and general litigation databases did not surface any patent case. Notably, hits for the bare number "7035918" were unrelated items mistakenly matching the string — e.g., a Brazilian civil case number (7035918‑95.2016.8.22.0001, 8ª Vara Cível, Porto Velho), a Santa Catarina municipal contract ("Ato n.º 7035918"), and a Russian dog-pedigree registration (RKF 7035918). These are not the U.S. patent and should not be confused with it. No result tied the number to a federal district court, the Federal Circuit, the ITC, or the PTAB.

Why the negative result is plausible (context, not confirmation)

• This is a defensive/portfolio patent from a mainstream security vendor (Rainbow/SafeNet). Patents of this type are frequently held and cross-licensed rather than asserted, which is consistent with an absence of enforcement litigation.
• The patent expired on 2021-05-20, which reduces the likelihood of any recent assertion.

Caveats on confidence

• I could not complete exhaustive queries against subscriber-only litigation platforms (Unified Patents portal, RPX/Insight, Docket Alarm, Lex Machina, PACER full-text). My tool calls hit a step limit before I resolved everything.
• Because of those limits, I cannot rule out a low-profile case (e.g., a dismissed declaratory-judgment action, a case naming the patent only in an exhibit/claim chart, or a district-court suit where the patent was pled under the '918 number). My statement is limited to what the searches I ran could establish.
• The Google Patents "Cited By" list for this patent includes later license-management patents (e.g., Avaya, Adobe, Macrovision, Flexera/others), but being cited is not litigation and none of those cited-by entries represents a suit on the '918 patent.

To conclusively verify

A definitive answer would require full-text querying of PACER/Unified Patents/RPX for the literal strings "7,035,918" and "7035918" and the assignee names (SafeNet, Inc.; Rainbow Technologies; Thales DIS CPL USA/Canada) across district courts, the CAFC, and PTAB. If you'd like, I can attempt those specific source queries next (subject to the earlier step-limit issue).

If the goal behind the question is an invalidity/prior-art or freedom-to-operate analysis rather than litigation history, note that the patent expired in 2021, so infringement exposure is now time-limited to past acts — and the relevant file is the family (especially US 7,716,348, the "License Balancing" sibling) rather than this number alone.

I'll start by checking for any PTAB proceedings, then verify against public sources.

Let me run additional targeted checks to make sure nothing is missed.

One more check for reexamination or assertion history that could bear on PTAB exposure.

PTAB / AIA Trial Proceedings — U.S. Patent No. 7,035,918

Patent: U.S. 7,035,918 B1 — "License management system and method with multiple license servers"
Appl. No.: 09/648,697 · Filed: 2000-08-25 · Priority: 1999-09-03 (Prov. 60/152,785) · Granted: 2006-04-25
Assignee of record: SafeNet Canada, Inc. (now Thales DIS CPL USA/Canada Inc. per current-assignee listing)
Legal status per source: Expired – Lifetime, adjusted expiration 2021-05-20

---

Proceedings overview

Total AIA trial proceedings on file: 0 — the structured "PTAB proceedings on file" block (USPTO Open Data Portal, most recent ingest) returns no IPR, PGR, or CBM proceedings for U.S. 7,035,918; status breakdown is therefore 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denials, and my independent web searches (PTAB E2E filings, PTAB petition documents, litigation/PTO docket reporting, CourtListener-facing search) surfaced no proceeding number, petition, Final Written Decision, or Federal Circuit appeal naming this patent.

Bottom line for a defendant: there is no PTAB invalidity precedent on this patent at all — no claim has ever been canceled or sustained in an AIA trial, so you cannot inherit anyone else's work product (and no § 315(e)(2) estoppel helps you). The far bigger fact is that the '918 patent expired on 2021-05-20: as of today (2026-10-01) it cannot be asserted prospectively, so any remaining exposure is a backwards-looking damages theory limited to pre-expiration conduct and the 35 U.S.C. § 286 six-year recovery window — not a forward-running royalty demand. This is the opposite of a "hardened by surviving two IPRs" patent; it is an untested but aged-out patent.

Disclosure on sourcing: I will not manufacture proceeding numbers, petitioner names, panels, or dispositions. Because the canonical list is empty and searches corroborated that, the per-proceeding template below is intentionally not populated. Everything I could verify is stated; everything I could not is flagged.

---

Per-proceeding detail

None to report. There is no {PROCEEDING_NUMBER} to enumerate. Specifically, I found no evidence of:

• an Inter Partes Review petition or institution decision on the '918 patent (any IPR20xx-xxxxx number);
• a Post-Grant Review (PGR) — note the patent issued 2006-04-25, long before the AIA's PGR window, so PGR is unavailable in any event;
• a Covered Business Method review (CBM201x-xxxxx) — CBM review had to be filed while the patent was being asserted, and the program sunset for new petitions on 2020-09-16;
• an ex parte reexamination or supplemental examination of record;
• any Federal Circuit appeal arising from a Board decision on this patent.

Why the absence is plausible (not a data gap):

1. The patent was never (visibly) a serial-assertion asset. Searches for litigation tying "7,035,918" to a defendant returned nothing — no ED Tex / D. Del. / ITC campaign reported against this number. Well-asserted patents eventually attract IPRs; a 1999-priority license-server patent that is not in active assertion does not.
2. Timing. IPR became available 2012-09-16. The patent's enforceable life ended 2021-05-20. Any would-be petitioner had roughly a nine-year window and evidently filed nothing.
3. Family overlap. The disclosure is one of four sibling filings named in the cross-reference block (Ser. Nos. 09/648,720 — "License Balancing"; 09/648,853 — "Selecting a Server"; 09/648,502 — "Commuter Licensing"), and the "Cited By" listing shows U.S. 7,716,348 B1 claiming the same 1999-09-03 priority with SafeNet as assignee. Caveat and action item: before treating "no PTAB history" as family-wide, run the same check separately against 7,716,348 and the other siblings — I did not exhaustively verify each family member's trial history here, and a defendant's demand letter may well point at a sibling rather than the '918.

---

Strategic summary

Claim status — everything is UNTESTED; nothing is CANCELED or SUSTAINED.
The patent carries 9 claims. No AIA tribunal has ever construed or adjudicated them, so there is no claim-level disposition to report. For orientation (from the granted text, not from any FWD):

• Claims 1–6 — system claims built on the leader/follower pool, client↔server heartbeats, and heartbeat-conveyed allocation counts (claim 1 independent; claims 2–6 dependent on 1).
• Claim 7 — independent method claim mirroring claim 1's heartbeat/fail-over steps; claim 8 depends from claim 7.
• Claim 9 — independent system claim adding the element that a client "receives a leader priority list from that particular license server" and uses it to locate another license server after losing its original server.

Because there is no IPR, the presumption of validity is fully intact and the claims as issued are what a court would construe. There is no narrower, post-IPR claim set to litigate against.

Estoppel landscape — none, in either direction.
Section 315(e)(2) estoppel attaches only to a petitioner after a Final Written Decision. With zero FWDs on this patent:

• No petitioner is estopped from anything, and no prior-art ground has been "used up" on your behalf;
• correspondingly, you inherit nothing — no prior-art record, no expert testimony, no Board claim construction, no IPR invalidity finding to ride into § 282 or Rule 12(c) motions.
• The prior art cited on the face of the patent (e.g., U.S. 5,390,297 Barber; 5,579,222 Bains; 5,704,032 Badovinatz — group leader recovery in a distributed computing environment; 5,790,664 Coley; 5,865,348 Pedersen; 5,978,565 Ohran) is available to you as § 102/§ 103 art in court. Note that Badovinatz is squarely about leader election/failover in distributed systems, which maps uncomfortably closely onto the patent's stated point of novelty ("any license server may act as a leader server should the leader server go down") — that is the natural obviousness lynchpin if validity is ever put at issue.
• Non-prior-art defenses (§ 101 abstract-idea, § 112 on the functional "programmed for" claim style) were never tested in a CBM or PGR and remain fully open.

Pattern signals.

• No serial petitioner — no party has filed even once against this patent.
• No aggressive PTAB appellant patent owner — there is no Board decision, hence no appeal, which is consistent with the patent never being contested on the merits at the Office.
• No defensive aggregator in the chain — I found no Unified Patents, RPX, or similar filing naming this patent despite it sitting in the software-licensing/DRM class (G06F21/105) that aggregators target.
• Net read: the absence of activity is best explained by asset fatigue, not strategic strength. The patent's life simply ran out before it became a litigation target.

---

Recommended next steps

1. Lead with expiration, not invalidity. The adjusted expiration date is 2021-05-20. Request/produce the maintenance-fee and PTA/PTE record (Patent Center) to confirm no reinstatement or term extension revived it. If the demand letter asserts ongoing or prospective infringement, that demand is facially defective.
2. Scope the past-damages window. Even for pre-expiration conduct, recovery is limited by 35 U.S.C. § 286 to six years before the complaint (i.e., no earlier than roughly 2020 for a 2026 filing) and is cut off cold at the 2021-05-20 expiration. Price the exposure accordingly.
3. Address the sibling patents. Before resting, verify whether the demand actually targets U.S. 7,716,348 or another member of the Ser. No. 09/648,xxx family, and run the same zero-proceeding check on each. That is the single largest analytical gap in this report.
4. If you nonetheless want an AIA filing on record — an IPR against an expired patent is legally permissible (the Board issues an FWD for estoppel/collateral purposes; claim amendments are unavailable). But weigh it against: (a) no forward exposure to eliminate; (b) the absence of any FWD or estoppel you need; (c) current discretionary-denial practice (Fintiv/"settled expectations" — a 1999-priority patent will almost certainly draw a discretionary denial; see the Office's 2025 interim-workload-memorandum regime). Filing is difficult to justify economically here. Confirm the patent's status on the record first.
5. Verification links. If you want to confirm the null result yourself:
   • PTAB E2E / PTAB Center: https://ptacts.uspto.gov/ptabweb/
   • Patent Center (prosecution, maintenance fees, term adjustment): https://patentcenter.uspto.gov/
   • Google Patents record (source of the authoritative text above): https://patents.google.com/patent/[US7035918](/patent/US7035918)/en
   • CourtListener (search "7,035,918" / "7035918" for CAFC and district activity): https://www.courtlistener.com/

---

Honest-confidence statement: I have high confidence that no AIA trial proceeding exists on U.S. 7,035,918 as of the ODP ingest and as of my searches on 2026-10-01 — the negative result is corroborated, not merely absent, and the patent's 2021-05-20 expiration makes the null result unsurprising. I have lower confidence about the family-wide picture (7,716,348 and the three sibling applications), which I did not individually exhaust. I did not find—and therefore do not assert—any petitioner, panel, FWD, settlement, or appeal. If the ODP ingest is later refreshed and shows a proceeding, this report should be regenerated rather than patched.

I'll research the assignment record for US 7,035,918, cross-referencing the authoritative full text already provided with USPTO Assignment Center, Google Patents legal events, and corporate/M&A filings.

Let me pull the recorded assignment data and the corporate chain (Rainbow → SafeNet → Gemalto → Thales).

I hit the tool step-limit mid-research, so I'll report precisely what I could and could not verify. Critically: the authoritative source supplied for this analysis (the Google Patents full text) lists assignment events but does not carry USPTO reel/frame numbers, and my web searches did not surface them. I will not fabricate reel/frame values. Everything below is grounded in the recorded event list in that source plus corroborated corporate/M&A records.

One scoping note before the findings: the task asks me to reconstruct the Post-Issuance / Ownership chain and to flag NPE patterns. The events below come from the Google Patents legal-events block (the authoritative text) — those are effectively the USPTO assignment/recordation events. I flag the reel/frame gap at each entry rather than invent numbers.

---

Inventors

Notes / unusual patterns:

• The list blends five California-based inventors with three New Delhi-based inventors, consistent with Rainbow Technologies running a distributed engineering team (U.S. core + India development). Singapore/India offshore development was common for security-software firms of that era; this is a team-structure observation, not an ownership signal.
• No evidence of mass inventor departure within 12 months of filing. The task flags that pattern as a pre-fire-sale tell; I found nothing supporting it here, and I have not verified individual inventor employment histories. Treat this as unclear/unverified, not "not present."
• All eight are the assignors on the 2000-08-25 recordation to Rainbow Technologies, Inc. (see below) — i.e., they executed a standard employment/assignment instrument at filing, which is itself evidence of an operating-company R&D program rather than a lone-inventor asset.

---

Original assignee

There is a record-level discrepancy I must flag explicitly:

• The filer/applicant of record on 2000-08-25 is "SafeNet Canada Inc." (Google Patents "filed by" event), and the issued patent's assignee (73) is SafeNet Canada, Inc., Belcamp, MD (per FPO).
• Yet the 2000-08-25 recorded assignment is to "RAINBOW TECHNOLOGIES, INC.," with the eight inventors as assignors.

So the record shows (a) inventors → Rainbow Technologies, Inc. in 2000, and (b) the issued patent naming SafeNet Canada, Inc. Two reconciliations are plausible and I cannot confirm which from the sources I could reach: (i) an internal Rainbow → Rainbow-Canada/SafeNet-Canada intake not separately surfaced in the Google event list, or (ii) a name/entity change after the 2004 Rainbow/SafeNet merger. I am flagging this rather than resolving it.

• Primary line of business: Rainbow Technologies, Inc. (Irvine, CA) was a security-software and anti-piracy licensing company, best known for the SentinelLM™ license-management product line that the patent's own specification describes as the commercial embodiment. The assigned rights therefore covered a product that Rainbow actually shipped — the SentinelLM/multiple-server license manager is the very subject matter of FIGS. 2–11.
• Current status: Rainbow Technologies was acquired by SafeNet, Inc. in a stock merger that closed March 15, 2004 (>$450M, per the Rainbow Acquisition subclass allegations in the SafeNet securities litigation). SafeNet subsequently went private (Vector Capital, April 2007), was acquired by Gemalto (January 2015, ~$890M), and Gemalto was acquired by Thales Group (April 2019, ~€4.8bn), becoming Thales' Digital Identity and Security division. The Google Patents current-assignee field lists Thales DIS CPL USA Inc. and Thales DIS CPL Canada Inc. — consistent with the SafeNet Canada entity having been rolled into the Thales DIS chain.
• The original assignee is therefore HISTORICAL; the operating entity survives inside Thales (Sentinel software-monetization brand).

---

Assignment timeline

Reel/frame caveat: The Assignment Center exposes a reel/frame for each recordation. My search results and the supplied Google Patents text did not return reel/frame numbers, and I exhausted my step budget before querying Assignment Center directly (search page: https://assignmentcenter.uspto.gov/ ). Rather than invent NNNNNN/NNNN values, each entry is marked "Reel/frame: not retrieved." Dates below are as recorded.

• 2000-08-25 (executed/recorded same day as filing) — Reel/frame: not retrieved

  • Conveyance: Assignment ("ASSIGNMENT OF ASSIGNORS INTEREST — SEE DOCUMENT FOR DETAILS")
  • Assignor: Chopra, Sanjay; Handa, Sandeep; Tripathy, Ajay; Redding, Mark; Badia, Logan; Duvvoori, Vikram; Ramamoorthy, Shankar; Sharma, Hemant (all eight inventors)
  • Assignee: Rainbow Technologies, Inc.
  • Correspondent: not retrieved
  • Context: Intake / original assignment — inventors conveyed rights to the operating employer at filing.

• 2006-04-25 — (no reel/frame)

  • Conveyance: Issuance (not an assignment)
  • Context: Patent granted (US 7,035,918 B1) naming SafeNet Canada, Inc. as assignee.

• 2007-04-06 — Reel/frame: not retrieved

  • Conveyance: Merger ("MERGER — SEE DOCUMENT FOR DETAILS")
  • Assignor: Rainbow Technologies, Inc.
  • Assignee: SafeNet, Inc.
  • Correspondent: not retrieved
  • Context: Internal reorganization via the Rainbow→SafeNet merger. (Timestamp anomaly: the Rainbow/SafeNet merger closed in March 2004, but this recordation is dated 2007-04-06 — one week before Vector Capital's going-private closing on 2007-04-12. This looks like a clean-up recordation of the 2004 merger captured as part of the 2007 privatization paper trail. Flagging the 3-year lag as a discrepancy.)

• 2007-04-16 — Reel/frame: not retrieved

  • Conveyance: Security Agreement ("FIRST LIEN PATENT SECURITY AGREEMENT")
  • Assignor: SafeNet, Inc.
  • Assignee/Secured party: Deutsche Bank Trust Company Americas, as Collateral Agent
  • Correspondent: not retrieved
  • Context: Securitization / financing — lien granted incident to the Vector Capital going-private LBO.

• 2007-04-19 — Reel/frame: not retrieved

  • Conveyance: Security Agreement ("SECOND LIEN PATENT SECURITY AGREEMENT")
  • Assignor: SafeNet, Inc.
  • Assignee: Deutsche Bank Trust Company Americas, as Collateral Agent
  • Context: Securitization — second-lien layer of the same financing.

• 2014-03-12 — Reel/frame: not retrieved

  • Conveyance: Release ("FIRST LIEN PATENT SECURITY AGREEMENT RELEASE")
  • Assignor: Deutsche Bank Trust Company Americas, as Collateral Agent
  • Assignee: SafeNet, Inc.
  • Context: Loan payoff / lien release — clears existing encumbrance in conjunction with refinancing.

• 2014-03-12 — Reel/frame: not retrieved

  • Conveyance: Release ("SECOND LIEN PATENT SECURITY AGREEMENT RELEASE")
  • Assignor: Deutsche Bank Trust Company Americas, as Collateral Agent
  • Assignee: SafeNet, Inc.
  • Context: Loan payoff / lien release.

• 2014-03-13 — Reel/frame: not retrieved

  • Conveyance: Security Agreement ("FIRST LIEN PATENT SECURITY AGREEMENT")
  • Assignor: SafeNet, Inc.
  • Assignee: Bank of America, N.A., as Collateral Agent
  • Context: Refinancing — new first-lien secured party replaces Deutsche Bank. (Timed just ahead of the announced 2014-08-08 Gemalto acquisition.)

• 2014-03-14 — Reel/frame: not retrieved

  • Conveyance: Security Agreement ("SECOND LIEN PATENT SECURITY AGREEMENT")
  • Assignor: SafeNet, Inc.
  • Assignee: Bank of America, N.A., as Collateral Agent
  • Context: Refinancing — new second-lien layer.

• 2015-01-30 — Reel/frame: not retrieved

  • Conveyance: Release ("RELEASE OF SECURITY INTEREST IN PATENTS — SECOND LIEN")
  • Assignor: Bank of America, N.A.
  • Assignee: SafeNet, Inc.
  • Context: Lien release — post-Gemalto-acquisition debt payoff.

• 2015-01-30 — Reel/frame: not retrieved

  • Conveyance: Release ("RELEASE OF SECURITY INTEREST IN PATENTS — FIRST LIEN")
  • Assignor: Bank of America, N.A.
  • Assignee: SafeNet, Inc.
  • Context: Lien release — completes the 2014 refinancing unwinding.

• 2021-05-20 — (no reel/frame)

  • Conveyance: n/a — legal-status event: adjusted expiration (patent expired).

Ownership-chain note not reflected in the event list: No separately recorded assignment appears in the supplied text for the SafeNet → Gemalto (2015) or Gemalto → Thales (2019) steps, even though Google Patents lists Thales DIS CPL USA/Canada Inc. as current assignee. Those transitions were likely effected by upstream share/entity acquisitions or internal mergers recorded elsewhere (or captured via name changes not surfaced here). This is a data gap I am flagging, not evidence that no transfer occurred — the current-assignee field itself implies a recorded change I could not pull.

---

Timeline diagram

timeline
    title Ownership of US 7035918
    2000 : Filed by SafeNet Canada as applicant
         : Inventors assign rights to Rainbow Technologies Inc
    2006 : Patent issued naming SafeNet Canada Inc
    2007 : Recorded merger Rainbow into SafeNet Inc
         : Deutsche Bank first lien security
         : Deutsche Bank second lien security
    2014 : Deutsche Bank liens released
         : Bank of America liens granted
    2015 : Bank of America liens released
         : Gemalto completes SafeNet acquisition
    2019 : Thales Group closes Gemalto acquisition
    2021 : Patent term expires

---

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. Every recorded link runs between operating security companies (Rainbow Technologies, Inc. → SafeNet, Inc.) or institutional lenders (Deutsche Bank, Bank of America). No "IP / Patents / Licensing / Holdings / Ventures" entity; no single-purpose LLC; no registered-agent-service address appears. The 2007 merger recordation (Rainbow → SafeNet) ends at a named operating company.

2. Known asserter in the chain — Not present. No link matches Acacia, Marathon, Intellectual Ventures, IPNav, Wi-LAN, Conversant/Mosaid, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, or any Spangenberg entity. The known names in the chain — Rainbow Technologies, SafeNet, Gemalto, Thales (and lenders Deutsche Bank / Bank of America) — are operating companies and financial institutions. No Unified Patents / RPX high-frequency-plaintiff match surfaced.

3. Repeat correspondent across the chain — Unclear / not determinable. This is the single most valuable tell per the task, and I could not retrieve any correspondent-of-record for any entry (the Google Patents event block omits it; my searches did not surface it). I therefore cannot confirm or refute a repeat filer. This should be resolved by pulling each reel/frame directly from Assignment Center before any conclusion is drawn on this signal. Not a finding either way.

4. Cascading transfers (<24 months through chained LLCs) — Not present. The only clustered events are (a) the 2007-04-16 / 2007-04-19 first- and second-lien security agreements (3 days apart) and (b) the 2014-03-12→03-14 release/re-grant sequence — both are ordinary financing mechanics, not transfers to a chain of licensing shells, and neither involves common LLC principals or a shared correspondent address.

5. Pre-litigation transfer — Not present. The earlier litigation analysis in this file found no infringement suit naming this patent; with no suit, there is no pre-suit transfer to evaluate. The chain's anchor events (2000 assignment, 2007 merger) long predate and are unrelated to any assertion.

6. Bankruptcy fire-sale — Not present. SafeNet's near-death moment was the 2006–2007 options-backdating scandal and the 2007 going-private LBO by Vector Capital, which produced the secured-lien records above (Deutsche Bank, 2007) — not a Chapter 7/11 patent sale. The 2014 Bank of America liens/releases likewise reflect refinancing, not bankruptcy. The patents were never sold out of an insolvency estate.

7. Privateering — Not present. No NPE has surfaced asserting the '918 (or the sibling family) on the operating owner's behalf. The chain terminates inside Thales Group, a large publicly disclosed operating conglomerate; the Sentinel software-monetization line remains an operating product brand. No SEC/EFF/Patent-Progress privateering coverage tied to this patent was found.

8. Defensive aggregator (anti-NPE) — Not present. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. Thales is an operating acquirer, not a defensive aggregator.

---

Verdict

Defensive / non-asserting (with a definitional caveat — see below).

The recorded chain is a sequence of operating-company acquisitions and secured financings, not NPE activity: inventors → Rainbow Technologies (2000 assignment, reel/frame not retrieved) → SafeNet, Inc. (2007 merger recordation) with financing liens from Deutsche Bank (2007) and Bank of America (2014), all subsequently released (2014, 2015), terminating at the operating Thales DIS entities with the patent expired 2021-05-20. There is no shell-entity transfer, no known asserter, no cascading LLC chain, no bankruptcy sale, and no litigation — so none of the affirmative NPE triggers is present.

Caveat, stated honestly: the requested verdict menu defines "Defensive / non-asserting" as a chain terminating at a defensive aggregator (RPX/AST/LOT/Unified). Here the chain terminates at an operating conglomerate, which is the opposite of an NPE but is not literally a defensive aggregator either. On these facts the patent is best characterized as held (non-asserted) within an operating company's portfolio; the "Defensive / non-asserting" box is the closest fit, and I flag the mismatch rather than force it. The one signal I could not evaluate — repeat correspondent — is the standard NPE smoking gun, so if this chain were ever asserted, that is the check to run first.

Verification link: USPTO Patent Assignment Search — search patent number 7035918 at https://assignmentcenter.uspto.gov/ (or the legacy index https://assignment.uspto.gov/patent/index.html ) to obtain the reel/frame and correspondent fields this analysis could not retrieve.

---

Explicit confidence statement

• High confidence in the event sequence (Rainbow 2000 → SafeNet merger 2007 → Deutsche Bank liens 2007 → releases/re-grants 2014 → Bank of America releases 2015 → expiration 2021), because it is drawn from the authoritative Google Patents full text supplied.
• High confidence that no NPE / known-asserter entity appears, and that the corporate chain is Rainbow → SafeNet → Gemalto → Thales.
• Low / unresolved confidence on: (a) reel/frame numbers — not retrieved, not fabricated; (b) correspondent of record — the key repeat-filer signal, not retrievable here; (c) the exact instrument effecting SafeNet → Gemalto → Thales and the Rainbow↔SafeNet-Canada applicant/assignee reconciliation.
• I did not access Assignment Center or PACER primary systems directly; results are from web search plus the authoritative patent text.

I'll research the prior art cited against US 7,035,918. Let me run targeted searches.

I have the references-cited list from FreePatentsOnline. Let me verify the complete list and gather filing/publication details for the key references.

Prior Art Analysis — U.S. Patent No. 7,035,918 B1

Target confirmed (no similar-number substitution): U.S. 7,035,918 B1 — License management system and method with multiple license servers, Redding et al., Appl. No. 09/648,697, filed 2000-08-25, priority 1999-09-03 (Prov. 60/152,785), granted 2006-04-25, assignee SafeNet Canada, Inc. (chain: Rainbow Technologies → SafeNet → Thales DIS CPL USA/Canada). This is the Redding et al. license-server patent — not any similarly numbered document. The only references to the bare string "3918" that surfaced were (a) an IBM Technical Disclosure Bulletin page range "pp. 3918-3919" (which I treat literally as a page cite, not a patent), and (b) unrelated foreign contract/case numbers — none of which are this patent.

---

Important framing / flag before the citations

1. The authoritative full text provided for this patent contains no "(56) References Cited" section. The "Cited By (65)" list in that record is made up of forward citations (later patents citing the '918) — e.g., the Avaya, Adobe, Macrovision, Flexera-family items. Those are not prior art to the '918 and must not be mapped under § 102. The prior-art set is the examiner/applicant citation list on the patent face, which I retrieved separately.
2. I retrieved the (56) list from the FreePatentsOnline record (https://www.freepatentsonline.com/7035918.html). Confidence: moderate-high on the list contents; lower on completeness — I did not obtain a page-image of the front page, and my tool budget was exhausted before I could element-by-element read every reference's full text. The § 102 mappings below are therefore potential (title/abstract/claim-level), exactly as the task requests, not final element-by-element conclusions.
3. Legal standard applied: to anticipate under § 102, a single reference must disclose every element of a claim, arranged as claimed. None of the references below clears that bar against independent claims 1, 7, or 9 (explained at the end).

---

I. U.S. Patent Documents cited (18)

---

II. Foreign Patent Documents cited (4)

The two Korean entries appear to be the same document listed with a filing-style and a publication-style designation; treat as one item.

---

III. Other References cited (5)

---

IV. Bottom line on § 102 anticipation

No single cited reference discloses all elements of independent claim 1, 7, or 9. The claimed combination is:

• a pool of license servers with a current leader holding a pool-wide record of allocations and followers each holding their own record;
• server-to-server communication to detect that one can no longer manage allocations;
• client↔authorizing-server heartbeats;
• on failure, the client locates a new leader and sends an "additional heartbeat" that conveys the number of allocations required (claims 1, 7; claim 9 uses a leader priority list held by the client instead).

Mapping the closest art to that combination:

The realistic invalidity theory is § 103, not § 102: Badovinatz (leader election/recovery in distributed computing) as primary, in view of a license-management reference (Bains or Barber or Wyman), optionally with Pedersen (client-side server selection) and the SentinelLM Release Notes — which is precisely the "natural obviousness lynchpin" flagged in the earlier PTAB section of this analysis. Under § 102 alone, at best a narrowly drafted dependent claim touching only the leader-recovery or allocation-counting element might be met by one reference; the independent claims are not anticipated by anything in this list.

---

V. Caveats and integrity notes

• Source discipline: the (56) list came from the FreePatentsOnline record because the authoritative Google Patents text supplied for this analysis omitted the "References Cited" section. I could not reach Patent Center/PAIR to confirm the list against the front-page image before the tool budget terminated.
• What I verified vs. did not: I verified titles, assignees, and dates for Badovinatz (5,704,032) and Bains (5,579,222) from primary/text sources; for the rest I relied on the cited list itself. I did not read each reference's claims/specification element-by-element, so the § 102 "potential" labels are provisional.
• No auto-correction: all numbers are reported as they appear (note the 4,446,519 vs. 4,685,055 Thomas discrepancy and the "3918-3919" page cite).
• Date-sensitivity: the two Korean entries and GB 2346989 A postdate the 1999-09-03 priority and therefore should not be relied on as § 102 art absent a priority challenge; flag for verification.
• If the goal is a validity/FTO workup, verify the (56) list against the front page and run the same prior-art pass on the sibling U.S. 7,716,348 ("License Balancing") and the other Ser. No. 09/648,xxx family members, per the action item in the earlier section.

I'll research the prior-art references cited on the face of this patent and their technical content, then build the § 103 combinations.

Let me gather the remaining cited prior-art references and their technical disclosures.

I've hit the tool step limit. Below is the § 103 analysis based on the authoritative full text already provided plus the prior-art research I was able to complete. I flag sourcing limits where relevant.

---

Obviousness Analysis — U.S. Patent No. 7,035,918 under 35 U.S.C. § 103

Patent: US 7,035,918 B1 — "License management system and method with multiple license servers"
Appl. No.: 09/648,697 · Filed: 2000-08-25 · Priority: 1999-09-03 (Prov. 60/152,785, per the cross-reference block)
Claims analyzed: 1–9 (independents 1, 7, 9)
Analytical date: 2026-04-26 (task date)

Sourcing caveat (read first — applies to every mapping below)

The full text you supplied renders the "Cited By (65)" list but does not render the patent's own "Patent Citations" / "Prior Art" block (the references cited by the examiner/applicant on the face of the '918 patent). The observable prior-art universe in the supplied text is therefore (i) the admitted prior art in the patent's own Background, and (ii) the Cited-By listings. The list of on-face references I use below (Barber '297; Bains '222; Badovinatz '032; Coley '664; Pedersen '348; Ohran '565) is carried forward from the earlier-generated PTAB section of this analysis, which is authoritative for cross-reference but which I could not independently re-verify against the face of the patent in this session.
This is a real limitation, not a stylistic hedge. The strongest § 103 case is built from the examiner-cited references, and I could only fully confirm the technical content of Barber '297, Bains '222, and the Badovinatz family. Coley '664, Pedersen '348, and Ohran '565 I describe at a lower confidence level and flag accordingly. Before filing any invalidity contention, pull each face reference PDF.

---

1. Legal framework

Obviousness is assessed under Graham v. John Deere Co., 383 U.S. 1 (1966), as refined by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007). The four Graham factors: (1) scope and content of the prior art; (2) differences between the prior art and the claims; (3) level of ordinary skill; (4) secondary considerations. Critically for this patent, KSR authorizes these rationales, each of which I invoke below:

• Combining known elements according to known methods to yield predictable results (KSR, 550 U.S. at 416).
• Simple substitution of one known element for another to obtain predictable results (id. at 416).
• Use of a known technique to improve similar devices in the same way (id. at 417).
• "If a technique has been used to improve one device, and a person of ordinary skill in the art would recognize that it would improve similar devices in the same way, using the technique is obvious unless its actual application is beyond his or her skill." (id.)

Pre-AIA § 103(a) governs (effective filing 2000; priority 1999), so the references need only be analogous art and available as § 102(a)/(b)/(e) art.

---

2. The person of ordinary skill in the art (PHOSITA)

Based on the patent's own field (network license management), its cited art, and the claimed subject matter, a PHOSITA as of 1999-09-03 would possess:

• A bachelor's degree in computer science or electrical engineering (or equivalent experience), plus 2–3 years of experience designing networked client/server software or distributed/high-availability systems; or a master's degree with 1 year of relevant experience.
• Working knowledge of: (a) floating/concurrent software licensing (license servers, allocation counts, check-out/check-in, borrowing); (b) distributed-system failover primitives — leader election, membership, heartbeat/keep-alive, quorum/majority; and (c) socket-level network programming over IP.

This matters because the patent's asserted novelty sits at the seam between two mature 1990s fields — license management (Barber, Bains, Coley, Globetrotter) and distributed-systems high availability (Badovinatz, Ohran). A PHOSITA at that seam is precisely the artisan KSR expects to combine the two.

---

3. Prior-art reference inventory

3.1 License-management references (the "allocation" side)

US 5,390,297 — Barber et al. ("System for Controlling the Number of Concurrent Copies of a Program in a Network Based on the Number of Available Licenses"), filed 1990s, issued 1995-02-14. (Confirmed content.)
Teaches a network license server with a license manager that tracks the set of nodes currently using a licensed program, holds license data on conditions of use, and determines whether the conditions would still be satisfied if a given node is added. In operation it returns the license if the request is denied, and increments/decrements counts as authorizations issue. Directly teaches: a client requesting authorization; a server checking an allocation count; granting/denying based on availability; and maintaining a record of concurrent usage. (Element set of claim 1, clauses (a) and (b).)

US 5,579,222 — Bains et al. ("Distributed license administration system using a local policy server to communicate with a license server and control execution of computer programs"), issued 1996-11-26. (Confirmed content; the '222 is a well-known asserted patent — cf. the Uniloc campaigns reported by Mandour Law.)
Teaches distributed license administration in which a local policy server communicates with a license server and governs execution; the license server tracks concurrent usage, evaluates conditions and licenses available, and supports borrowing/"checking out" of licenses. Teaches a license request that specifies the number of licenses sought, and a server that grants or withholds based on remaining allocations. (Clauses (a)–(b); also the "number of allocations required" payload in clauses (i).)

US 5,790,664 — Coley et al. ("Automated system for management of licensed software"), issued 1998-08-04, Network Engineering Software, Inc. (Content confirmed only at the abstract/citation level — lower confidence.)
Disclosed as an automated management system for licensed software, i.e., server-mediated control of licensed application usage across a network. As a license-management reference it reinforces the "one server stores and manages the licenses" model the '918 patent's own Background describes under SENTINEL™. Treat as cumulative to Barber/Bains; verify before relying on it as a primary reference.

US 5,865,348 — Pedersen et al. (Content NOT verified in this session.) Flagged. Do not rely on this reference in a contention without pulling the document.

US 5,555,143 — Novell ("Method and apparatus for electronic licensing") and US 5,671,412 — Globetrotter Software ("License management system for software applications") appear in the art cited by related family members (surfaced via the cited-by/citation graph). Both are representative of the mature electronic-licensing art in the same pre-1999 window. Available as § 102/§ 103 art if needed as secondary references.

3.2 Distributed leader/follower + failover references (the "pool" side)

US 5,704,032 — Badovinatz et al. ("Method for group leader recovery in a distributed computing environment"), filed 1996-04-30, issued 1997-12-30, IBM. (Content fully confirmed — this is the linchpin.)
Teaches, essentially element-for-element in the distributed-computing domain:

• A group of processors with a group leader ("the group leader is responsible for controlling activities associated with its processor group(s)"); all others are members — i.e., a leader/follower designation. → Claim 1 clause (c)–(d).
• Leader failure recovery: "If the group leader is removed from the processor group for any reason … then group leader recovery takes place. In particular, a new group leader is selected" → clause (e) (first half) and claim 7's "selecting one of the follower servers as a new leader."
• Selection by a membership list ordered in sequence of joins — i.e., a priority list for who becomes next leader — and in one embodiment "the membership list is stored in memory of each of the processing nodes," with "each processor to join the group receiv[ing] a copy of the membership list from the current group leader." → Claim 9's "leader priority list" received by a member from the server (see §7.3).
• The new leader acquires state before/because of assuming the role: claim 8 of '032 recites "receiving, by said new group leader, prior to said new group leader being selected … any messages previously sent to said group of processors," and claim 9 recites the new leader "providing … any messages missed by any processor." In the description, after a leader change "the group leader ensures that it has all of the messages by communicating with the processing nodes of the group," and then synchronizes the members. → Clause (e) (second half: "upon selecting a new leader server from the pool, the new leader server … receiv[es] from each license server the record of distribution for that license server") and claim 6 (new leader amends its record to become pool-wide).
• Failure detection by signaling with timeout: "The subsystem sends a signal to at least the nodes in the membership list, and if there is no response from a particular node, it assumes the node is inactive." → Clause (f) ("license servers … communicating with each other and determining when a particular license server can no longer manage a distribution").
• Responsiveness monitoring / ping: Group Services "monitor[s] the responsiveness of the processes … in a similar fashion as to a ping mechanism used in computer network communications." → the heartbeat concept.
• Name server that stores the list of group leaders for all groups and, on a leader change, is informed and informs the other members (atomic multicast). → claim 4 (election) and the "locating the new leader" step.

US 5,696,896; 5,787,249; 5,790,788; 5,799,146 — the Badovinatz/IBM "Group Services" family. (Confirmed as a family.)
These siblings teach the surrounding cast: membership management, name-server-mediated leader identification, message ordering/sequence numbers, and failure-cleanup. They support the dependent-claim mappings (leader notifying members, ack-based membership updates).

US 5,978,565 — Ohran. (Content NOT verified in this session; likely the Ohran high-availability/fault-tolerance work.) Flagged — likely a heartbeat/backup-server-takeover reference. Do not over-rely without verification.

3.3 The patent's own admitted prior art (35 U.S.C. § 301-style admission)

The '918 specification admits as prior SENTINEL™ systems that:

• "a shell program or library of API functions could be configured to send a general poll to all servers coupled to the communication channel", that servers reply, and that the client "respond[s] to the first reply received from a license server having a license file storing license information for the protected software program"; and
• "If the primary server cannot be reached by a user … the user may then communicate with a backup server to obtain an authorization message."

This admission is highly probative: it establishes that client-driven migration to another/backup license server and client-side selection among multiple license servers were known. It supplies much of the "client locates another server and re-requests" step of claim 1(i).

---

4. Claim 1 — element-by-element mapping

Observation: every limitation has a home in the art. The only element that is arguably not verbatim in a single reference is the specific packaging choice in clause (i) — that the failover message is styled an "additional heartbeat" that piggybacks the allocation count. That is a message-format design choice, and it is precisely where the § 103 case is won.

---

5. The combinations and the motivation to combine

Combination A — the primary case (renders claims 1 and 7 obvious)

Barber '297 (or Bains '222) in view of Badovinatz '032, further in view of the admitted SENTINEL failover.

What the combination yields: Barber/Bains supply the license-management substrate (clients request authorizations; a server tracks an allocation count and a record of concurrent usage; grants/denies based on availability). Badovinatz supplies the high-availability overlay (a pool with one leader and members; leader election on failure; the new leader informs/synchronizes members and acquires the state it needs). Layering Badovinatz's leader/follower failover onto Barber/Bains' license servers yields claim 1's (a)–(f) essentially as claimed. The admitted SENTINEL poll/backup technique supplies the client-side migration to a backup server; heartbeat/keep-alive detection (Badovinatz ping; well-known in the art) supplies (g)–(h); and routing the client to the elected new leader with the allocation count supplies (i).

Motivations (any one suffices under KSR):

1. Same field of endeavor / analogous art. Both references address multiple cooperating networked computers providing a service to clients with failure recovery. The license servers of Barber/Bains are the "group of processors/service nodes" of Badovinatz. Applying group-leader recovery to a server pool is not a leap across disciplines.
2. The problem is expressly identified in the '918 Background. The patent states the single-server model means "failure of that server can result in a failure of the entire license management system." Badovinatz's stated purpose is to keep an application "highly-available … able to continue to execute after a failure." A PHOSITA confronting the single-point-of-failure problem in a license server has an explicit, ready-made reason to import Badovinatz's leader-recovery mechanism — this is the "known technique to improve similar devices in the same way" rationale (KSR).
3. The prior art itself motivates the state-transfer step. Badovinatz teaches the new leader obtaining prior/missed messages and syncing members. Once license allocations live on distributed servers, a PHOSITA would recognize the new leader must collect each server's allocation record to reconstruct the pool-wide picture — the '918 patent's own claim 6. This is the same step Badovinatz already performs, applied to a different data payload (allocations vs. ordered messages).
4. Predictable results. Combining a working pool-failover scheme with a working allocation-tracking scheme yields nothing more than the expected union of their functions; no new or unpredictable interaction is required.

Combination B — the "additional heartbeat" limitation

Badovinatz '032 (ping/timeout monitoring) in view of Bains '222 (license request specifying the number of licenses) and/or the admitted SENTINEL poll.

• Badovinatz teaches periodic responsiveness monitoring in the manner of a ping and treats absence of a response as a failure. A PHOSITA would naturally use the same periodic message that detects failure to carry the failover payload — because a keep-alive is idle otherwise, and piggybacking the allocation count (Bains) eliminates an extra round trip and lets the contacted server immediately evaluate availability. This is a textbook "known technique … to improve similar devices in the same way" / "predictable variation."
• The '918 specification's own description confirms the triviality of the step: "it will convert the heartbeat to a request, and issue an authorization to client computer" — i.e., the patent describes the heartbeat→request conversion as a mechanical operation, not an inventive one.

Combination C — the alternative (renders claim 9 obvious)

Badovinatz '032's distributed membership/priority list (or the '918 admitted SENTINEL leader priority list) in view of Bains/Barber.
Badovinatz explicitly stores the ordered membership list at each node and distributes it from the current leader to joining members, enabling a member to determine the new leader itself. Substituting a license server for a processor and a leader priority list for the membership list is a simple substitution of one known element for another (KSR). The only departure in claim 9 — providing the list to the client rather than keeping it server-side — is an obvious design convenience: the client is the party that must "locate another license server" after failure, so giving it the routing data already used pool-wide eliminates a lookup step.

---

6. Dependent claims

Modern PTAB/§ 282 practice requires each dependent claim to be separately addressed; a well-pleaded contention must not rely on the independent-claim mapping alone.

• Claim 2 / Claim 8 (new leader checks whether it already issued an authorization; converts heartbeat to a request only if it had not): Rendered obvious by Barber '297 and Bains '222, both of which have the license server track which nodes hold licenses and avoid double-counting — combined with the well-known distributed-systems principle that a retried/reconnect request must be made idempotent to prevent duplicate resource allocation. A PHOSITA implementing failover would, as a matter of routine, guard against the failover target double-granting to a client it already authorized. Motivation: preserve the hard limit (the '918 "ceiling") that Barber/Bains exist to enforce.
• Claim 3 (leader heartbeats followers; follower acks; leader marks follower down on missing ack): Badovinatz '032 teaches exactly a signal pushed to members with absence of response ⇒ node inactive, and ack-based membership updates appear throughout the Group Services family ('249, '896, '788, '146). Classic heartbeat/ack failure detection.
• Claim 4 (follower missing heartbeat sends a check message; if no reply, starts election): Badovinatz '032 teaches a member requesting a new group leader from the name server and the full leader-election flow, and teaches failure detection by signal/no-response. The "check message" is the ordinary two-phase confirmation a PHOSITA would add to avoid a false election on a single dropped packet — an obvious design refinement (KSR, "predictable variations").
• Claim 5 (new leader heartbeats remaining followers; followers report their allocation status): Badovinatz '032 teaches the new leader informing/querying members and syncing their state after takeover; Badovinatz's goal of "count[ing] on the group leader to control and manage the group" supplies the motivation for the new leader to poll members for their current state — the license equivalent being the allocation record. Also supported by Behbehani/KR-family '032 description of membership-list updates to all members.
• Claim 6 (new leader amends its record to include each server's record, creating a pool-wide record): Badovinatz '032 — the new leader "ensures that it has all of the messages … communicat[es] with the processing nodes," then "ensures that all of the other processing nodes … also have those messages." Merging each member's record into a single pool-wide record is the direct implementation of Badovinatz's "new group leader ensures it has all the data" step, applied to allocation records (see Combination A, motivation 3).
• Claim 7 (method mirroring claim 1): Obvious for all the reasons in Combination A; the method steps track the structural limitations nearly one-to-one, so the same combination disposes of claim 7 under § 103.
• Claim 8 (method counterpart of claim 2): see Claim 2.
• Claim 9: see Combination C.

Summary claim-status table (all "obvious" — none "anticipated," because the combination is required):

---

7. Rebuttal considerations a validity analyst must anticipate

1. "Teaching away"? Weak. If anything, the prior art points toward the invention: the '918 Background itself recites the failure problem and the SENTINEL backup-server workaround, and Badovinatz supplies the fix. There is no reference that disparages combining leader election with license serving.
2. "Different field"? Not viable. Both are network service-distribution systems; the Federal Circuit routinely finds license-management and cluster/ha references analogous to one another (cf. the later citations in this very patent's "Cited By" list — Avaya, Adobe, Macrovision, Flexera-family patents for license balancing / distributed license management).
3. "Unexpected results"? None disclosed. The specification claims ordinary benefits (continued operation on leader failure, client re-authorization) that are the expected product of Badovinatz applied to Barber/Bains.
4. Secondary considerations (objective indicia). ⚠️ This is the principal factual gap. I have no evidence of commercial success, long-felt need, failure of others, copying, or industry praise tied to the '918 claims, and — consistent with the earlier Litigation and PTAB sections of this analysis — no litigation or IPR record exists to have surfaced such evidence. For an expert report, an opposing expert may still proffer secondary-consideration testimony (e.g., the SENTINEL product line's market acceptance). The patent's expired status (2021-05-20) makes that largely academic for prospective relief but not for a past-damages validity fight.
5. § 103 counter-risk — over-aggregation. Because the only genuinely "new" wording sits in claim 1(i)/claim 9's "additional heartbeat conveying the number of allocations," a court could find that, absent a clean showing that some reference teaches a client-server heartbeat and that piggybacking the allocation count is a design choice within skill, the record is vulnerable. Mitigation: bolster Combination B with an express keep-alive/PING reference and pull Ohran '565 (unverified above) to confirm it teaches heartbeat-based failover.

---

8. Contradictions / flags against the earlier-generated sections

• No substantive contradiction found between this § 103 analysis and the previously generated Patent Summary, Litigation, or PTAB sections. The prior sections' factual predicates (priority 1999-09-03; claims 1–9; three independents; Badovinatz as an on-face reference about leader recovery/failover; expiration 2021-05-20) are consistent with what I used here.
• One cross-reference to strengthen: the earlier PTAB section named Badovinatz US 5,704,032 as "the natural obviousness lynchpin if validity is ever put at issue." This analysis confirms and operationalizes that flag — '032 is indeed the closest single reference for the leader/follower + election + state-sync core, and it is not limited to that role: it also supplies the priority-list-to-members teaching that is the heart of claim 9.
• One uncertainty restated: the earlier sections relied on the on-face reference list without a rendered "Patent Citations" block. I could not fully re-verify Coley '664, Pedersen '348, and Ohran '565 here (tool limit). Do not treat those three as verified. The § 103 case in §5–§6 does not depend on them; it rests on Barber '297, Bains '222, and the Badovinatz family, all of which I confirmed.

---

9. Conclusion

Every claim of US 7,035,918 is vulnerable to a § 103 challenge, with the strongest case being Barber '297 and/or Bains '222 (license management with allocation tracking and client-issued authorization requests) in view of Badovinatz '032 (leader/follower recovery, election, distributed priority list, and new-leader state acquisition), further in view of the client-side heartbeat/failover art that the patent itself admits (the SENTINEL poll/backup-server technique) and, for the "additional heartbeat" limitation, the ordinary keep-alive- as-message design choice.

The motivation to combine is unusually strong because (i) the single-point-of-failure problem is expressly stated in the '918 Background, (ii) Badovinatz expressly targets that exact problem in the same class of networked multi-server systems, and (iii) the combination produces only predictable benefits. The principal uncertainty is evidentiary, not legal — it requires (a) verification of the three unconfirmed face references and (b) any secondary-considerations evidence, of which I found none.

Confidence: High on the Barber '297 / Bains '222 / Badovinatz '032 mappings and the motivation-to-combine analysis (grounded in confirmed reference content). Low on Coley '664, Pedersen '348, and Ohran '565 (unverified — flagged). No assertion is made that the claims are anticipated by any single reference; the analysis is a combination (§ 103) analysis.