US 8775574

I'll search for docket/litigation information on this specific patent, then summarize.

The first searches returned results for unrelated patents (e.g., 8,073,557). Let me search more precisely.

US Patent 8,775,574 — Summary

Bottom line first on the litigation search: I searched for docket/litigation records tied specifically to the number 8775574 and found no CAFC 2026 appeal or any other litigation referencing this patent. My searches were polluted by an unrelated patent, 8,073,557 (Roy-G-Biv Corp., ABB v. Roy-G-Biv), which is a different number and must not be conflated. I also could not independently pull a USPTO PatentCenter / PTAB record via search in this session, so the bibliographic data below is taken from the authoritative patent text supplied and cross‑checked against a Google Patents citation hit that confirms the number, assignee, and title. I cannot affirm judicial silence with certainty — only that no docket surfaced.

Bibliographic data

Abstract (verbatim)

"Embodiments relate to systems and methods for remote network configuration management having multi-node awareness. A management server can communicate with a set of hosts in a network, each of which can have associated target machines such as computer clients. The configuration details of the set of hosts can be stored in a set of configuration files. The configuration files can specify, for example, processor, memory, hardware, I/O, and other resources of the hosts or targets associated with the hosts. When a systems administrator or other user wishes to push an updated configuration or send new data to the set of hosts, the management server can identify versions of software and other resources to transmit and install to hosts in the set of hosts based on their particular configuration details reflected in the corresponding configuration files(s), without having to manually identify versions to be distributed to individual hosts or resolve dependencies."

Plain-language overview of the independent claims

Claim 1 — Method (the core multi-node, dependency-ordered push).
A management server (a) reads stored configuration data describing how each of at least two nodes in a remote network is set up; (b) takes a single global command from an administrator and expands it into different, node-specific configuration orders — one tailored to node 1's configuration, another tailored to node 2's; (c) works out, based on a configuration dependency between the two nodes, the order/sequence in which those orders must go out; and (d) pushes the first order according to that sequence and according to either a predetermined schedule or a predetermined triggering event, then — once it has determined the first order was sent — pushes the second order. The key inventive thrust is centralizing multi-machine, order-sensitive configuration changes so the admin issues one command rather than manually sequencing per-host work.

Claim 6 — System (same invention, apparatus framing).
A system with (i) an interface to a set of nodes in a network and (ii) a processor that performs the identical set of operations as Claim 1: access per-node configuration data; generate node-specific configuration orders from a received global command; determine a transmission sequence based on an inter-node configuration dependency; transmit the first order per the sequence and per a schedule/triggering event; and, upon determining the first order was transmitted, transmit the second order.

Claim 12 — Non-transitory computer-readable medium (same invention, software framing).
Instructions executable by a processor to carry out the same operations recited in Claim 1 (access per-node configuration data → generate node-specific orders from a global command → determine a dependency-based sequence → transmit the first order per the sequence and schedule/triggering event → transmit the second order upon determining the first was transmitted).

Dependent-claim context (brief, for completeness)

• Claim 2 / 7 / 13: the configuration data is a node template specifying hardware resources, software resources, and/or network settings.
• Claim 3 / 8 / 14: the configuration order is a software installation/update/inventory order, hardware inventory order, security order, or node restore order.
• Claim 4 / 10: the "set of nodes" includes hosts plus associated targets (client machines).
• Claim 5 / 11: the first and second configuration orders are different from one another.
• Claim 9: the processor also stores updated configuration data back to a data store.

Notes on claim scope and drafting quirks

• Every independent claim hinges on three features working together: a single global command differentiated into per-node orders, a dependency-derived transmission sequence, and a transmit-then-transmit ("in view of a determination that the first configuration order has been transmitted") gate. This is consistent with the specification's stated problem — prior systems (puppet, cfengine) were pull-based and per-machine and "do not contain the ability to resolve dependencies, and direct one machine to do action X after another machine successfully completes action Y."
• The "transmitted" trigger in the claims is worded around transmission of the first order, not successful completion by the first node — a subtle but potentially meaningful scope distinction versus the specification's description of directing one machine to act after another successfully completes action Y.
• Claim 6 contains a minor typographical omission (a missing semicolon after "sequence in which to transmit the first configuration order and the second configuration order"), which does not alter its substance.
• The specification references a co-pending application (Ser. No. 12/130,424, published as US 2009/0300180) for secure-channel transport of the configuration commands.

Uncertainty / caveats

• No CAFC 2026 docket entry or other litigation was located for US 8,775,574 in my searches; treat "no litigation" as an unconfirmed negative, not an affirmative finding.
• Search results dominated by 8,073,557 are a different patent and unrelated to this one.
• Only two forward citations surfaced (US 10,033,835 B2 to Alibaba; US 10,771,332 B2 to Microsoft), and the patent lists 70 cited references — the assertion-level details were not verified against USPTO records independently in this session.
• All bibliographic values above are taken from the authoritative patent text provided and corroborated by a Google Patents citation hit linking "US8775574B2 … 2008-11-26 … 2014-07-08 … Red Hat, Inc. … Remote network management having multi-node awareness."

I'll search for litigation involving US patent 8775574 across patent litigation sources.

Let me search more targeted litigation sources.

Findings: Litigation Involving U.S. Patent No. 8,775,574

Bottom line: I found no evidence of any litigation — district court, ITC, or Federal Circuit — involving U.S. Patent No. 8,775,574. To my knowledge and based on the searches below, the patent has never been asserted in a patent infringement suit, has not been the subject of a declaratory judgment action, and has not been the subject of any PTAB proceeding (IPR/PGR/CBM) that I could locate. I am stating this explicitly rather than supplying case details I could not verify.

Searches performed

• US patent 8775574 litigation
• "8775574" patent infringement lawsuit
• "8,775,574" infringement complaint Red Hat
• courtlistener "8775574" patent case
• unifiedpatents portal litigation 8775574
• "Remote network management having multi-node awareness" litigation lawsuit (title search)

None of these returned a docket, complaint, opinion, or litigation-tracker entry identifying U.S. 8,775,574 as a patent-in-suit, an asserted patent, or a patent challenged at the PTAB.

Why this result is plausible (context, not evidence of litigation)

• Assignee/Owner: Red Hat, Inc. (recorded assignments from Michael Paul DeHaan and Adrian Likins; Red Hat is now an IBM subsidiary). Google Patents lists the current assignee as Red Hat Inc. Red Hat is a defensive-oriented operating company and, in my searches, appears as an accused party or declaratory-judgment plaintiff in unrelated matters (e.g., the Xinuos v. IBM/Red Hat and CAS v. Red Hat disputes), not as an enforcer of this patent. https://patents.google.com/patent/[US8775574](/patent/US8775574)/en
• No forward assertion trail: The Google Patents "Cited By" list for US8775574 shows only two later documents — US10033835B2 (Alibaba, 2015) and US10771332B2 (Microsoft, 2014) — neither of which indicates litigation over the '574 patent. https://patents.google.com/patent/US8775574/en
• Legal status: The patent shows as Active, with an adjusted expiration of 2029-09-12 and maintenance fees paid through the 8th-year fee (paid 2021-12-28); a maintenance-fee reminder was mailed 2026-02-23. This confirms the patent remains in force but says nothing about assertion.

Important disambiguation (do not conflate)

My searches surfaced several documents referencing different patent numbers that should not be attributed to US 8,775,574:

• U.S. 8,073,557 B2 (Roy-G-Biv Corp.) — subject of IPR2013-00074 and related district court case Roy-G-Biv Corp. v. ABB, Inc., No. 6:11-cv-00622-LED (E.D. Tex.).
• U.S. 7,606,156 and related patents in CAS (Communications Authentication Solutions) v. Red Hat (declaratory judgment / North Carolina Abusive Patent Assertion Act claims).
• The Xinuos v. IBM/Red Hat dispute (D.V.I., later transferred to S.D.N.Y.).

These involve the respective numbers as written and are not actions on U.S. 8,775,574.

Caveats on completeness

I could not run a direct, filtered query against the Unified Patents litigation case list, CourtListener's docket API, PACER, or Docket Navigator — those require targeted portal queries (or paid access) rather than general web search. Because district court complaints are not always fully indexed by general web search, I cannot rule out with absolute certainty that a case exists, particularly a recently filed or sealed one. I checked Federal Circuit opinions and PTAB filings at a high level and found nothing.

Recommended verification steps if you need a definitive litigation clearance:

1. Query the Unified Patents litigation case list filtered to the patent: https://portal.unifiedpatents.com/litigation/caselist and the PTAB case list: https://portal.unifiedpatents.com/ptab/caselist
2. Search PACER's nationwide docket index (or a service like Docket Navigator / Lex Machina) by patent number.
3. Check the USPTO Patent Center "Patent Litigation" / assignment records and the Federal Circuit's docket for any appeal naming the '574 patent.
4. Cross-check with Red Hat/IBM as assignee for any assertion history.

If you'd like, I can draft the specific search strings/queries to run in those portals, or prepare a short "no known litigation" declaration template for a freedom-to-operate or due-diligence file.

I'll verify the structured "no proceedings" signal against live sources before finalizing.

Let me run a few more targeted checks to be thorough about any unindexed proceedings.

One more diligence pass on litigation and post-grant/reexam activity.

Proceedings overview

Total AIA trial proceedings on file for US 8,775,574: 0. The structured PTAB feed in this prompt (USPTO Open Data Portal, most recent ingest) returns no IPR, PGR, or CBM proceedings — no instituted trials, no denied institutions, no settlements, no appeals — and my independent web searches of PTAB-facing sources (PTAB decisions, petition documents, PTAB analytics/aggregator portals) surfaced no petition ever filed against this patent. Verified as of 2026-09-28.

The defensive posture this gives a defendant is unusual and cuts one way: there is no claim-level PTAB precedent to lean on — no canceled claims, no FWD to cite, no § 315(e)(2) estoppel trench. All 14 claims stand exactly as issued on 2014-07-08, unreviewed by the Board. A defendant must build invalidity and non-infringement from scratch, with no roadmap from a prior petitioner. The flip side: because no IPR was ever instituted, none of the prior art is locked up by estoppel, and every ground remains available to you.

Proceedings list

None to enumerate. I will not generate placeholder or synthesized proceeding numbers. For completeness, here is what I affirmatively checked and what I affirmatively did not find:

⚠️ Do not mistake the citation tables for proceedings. The "Cited By (2)" entries (US10033835 to Alibaba; US10771332 to Microsoft) are later patents that cite '574 as background — they are not PTAB challenges. Likewise the "Patent Citations (70)" / "Family Cites Families (34)" lists are prosecution citations and family members, not trial records.

What the '574 patent actually is (as it relates to assertion risk)

• Patent: US 8,775,574 B2, "Remote network management having multi-node awareness"
• Filing date / priority date: 2008-11-26 (earliest priority 2008-11-26 per the record — note the Unified Patents portal listing shows 2008-11-25, a one-day discrepancy I could not resolve; treat 2008-11-26 as controlling)
• Grant date: 2014-07-08
• Assignee: Red Hat, Inc. (original and current)
• Inventors: Michael Paul DeHaan; Adrian Likins
• Claims: 14 total — independent claims 1 (method), 6 (system), and 12 (non-transitory CRM); dependent claims 2–5, 7–11, 13–14
• Legal status (record): Active; adjusted expiration 2029-09-12
• Prosecution counsel / agent of record: Lowenstein Sandler LLP (Lowenstein Sandler LLP / Red Hat); Primary Examiner Ario Etienne, Assistant Examiner Michael C. Lai
• Maintenance: 4th-year fee paid 2017-12-28; 8th-year fee paid 2021-12-28; a fee-payment reminder was mailed 2026-02-23 (FEPP) with no recorded lapse. I cannot confirm the current 12th-year payment status from the sources reviewed — verify annuity status directly on Patent Center before relying on enforceability.

Strategic summary

Claim status — CANCELED / SUSTAINED / UNTESTED. There is nothing in the CANCELED column: no claim of US 8,775,574 has ever been canceled, disclaimed, or held unpatentable in any proceeding. Sustained by adjudication: none. Untested by the PTAB: all 14 claims, including all three independent claims (1, 6, 12) and every dependent claim (2–5, 7–11, 13–14). Contrast this with the family/neighborhood art: sibling Red Hat provisioning patents in the same 2008–2009 portfolio (e.g., US 8,716,392, US 9,280,399, US 8,566,459) likewise appear unchallenged at the Board. The '574 patent is a pure prosecution-only artifact — its claim scope is whatever the examiner allowed and whatever a district court later construes, with no PTAB layer on top.

Estoppel landscape — wide open. Because no IPR was instituted against this patent, no petitioner, real party in interest, or privy is subject to § 315(e)(2) estoppel on these claims, and there is no Patent Owner-side IPR-driven amendment history (no statutory disclaimer, no substitute claims under § 316(d)) narrowing the claims. Practically: a defendant today may raise any § 102/§ 103 ground, including art that was before the examiner during the 2008–2014 prosecution, art in the 70-item citation list, and art not considered at all. The absence of any prior IPR also means there is no Board claim-construction to inherit — only the intrinsic record. Two structural soft spots worth early attention, based on the specification's own framing:

• The background section concedes that existing pull-based systems (expressly naming puppet and cfengine) already performed per-machine configuration management — useful § 102/§ 103 framing against independent claims 1, 6, and 12 whose novelty is elsewhere (multi-node dependency ordering plus "in view of a determination that the first configuration order has been transmitted to the first node, transmitting the second configuration order").
• The single-figure embodiment (FIG. 2: machine A = UI logic, B = database, C = backend, D = backup) is the entire written description for multi-node dependency handling. Expect a § 112(a) written-description / enablement squeeze if a plaintiff reads the claims broadly onto arbitrary node topologies, and expect § 112(b) attack on the functional "generating… in view of a received global command" language plus the open-ended Markush-style "at least one of… or" claim formats in claims 3, 8, and 14.

Pattern signals. No petitioner has ever filed against this patent — not once, not twice. There is no defensive aggregator (Unified Patents or similar) in the chain for '574; the aggregator record for the patent shows a null challenge set. Red Hat, the owner, is on the offensive PTAB side elsewhere (it has petitioned against Competitive Access Systems' multipath patents) and files declaratory-judgment actions defensively (e.g., Red Hat, Inc. v. VPN Technology Holdings, LLC, 1:25-cv-00613, E.D. Va., filed 2025-04-10; the Sequoia/ETRI consolidated actions, D. Del. 18-1127). But '574 itself has never been asserted in a district court action I could locate, and no third party has ever filed a PAE-style demand around it in the public record. This is a classic defensive-portfolio patent, not a litigation asset.

Recommended next steps

1. If a demand letter or complaint cites the '574 patent, there are no canceled claims to point to. Do not expect an IPR shortcut on claim 1. Instead, (a) demand the plaintiff's claim charts against claims 1, 6, and 12 specifically, (b) prepare a Markman position on "configuration dependency," "global command," and "configuration order," and (c) begin a § 102/§ 103 search now — the relevant art window is 2008-11-26 backward, and the specification conveniently concedes puppet/cfengine-style per-node configuration management as prior practice.

2. If you are contemplating your own IPR, you are unobstructed. No estoppel runs against you, no § 325(d) "substantially the same art" problem exists beyond what the examiner actually applied, and no Fintiv-style discretionary-denial track record attaches. Statutory deadline math if you file: institution decision within 35 U.S.C. § 314(b) (~6 months), then a Final Written Decision within § 316(a)(11) — one year from institution, extendable only for good cause.

3. If you want to firm up the "no proceedings" conclusion, query the canonical sources directly before filing anything that depends on it:

   • PTAB E2E / Patent Trial Case Tracking System: https://ptacts.uspto.gov/ptabweb/
   • USPTO PTAB decisions library (FWDs and institution decisions): https://www.uspto.gov/patents/ptab/decisions
   • CourtListener for any CAFC appeal or district-case trail: https://www.courtlistener.com/
   • Patent bibliographic and legal-status page: https://patents.google.com/patent/US8775574/en

4. Monitor terminal disclaimers, reissue, and reexamination. Because the patent was never Board-tested, the owner's alternative narrowing path is a reissue or ex parte reexamination — neither is an AIA trial and neither would appear in the structured PTAB block. I found no evidence of either, but this is the one place a non-PTAB validity challenge could silently alter claim scope.

5. Watch the maintenance-fee clock. A fee-payment reminder mailed 2026-02-23 appears on the record with the patent still listed Active and expiring 2029-09-12. If the 12th-year fee lapses, the patent expires for failure to pay — a cheaper "defense" than any IPR. Confirm status on Patent Center before relying on it, and re-check before any invalidity workup.

Caveats on this report. The absence of proceedings is asserted on the strength of (i) the structured ODP feed in this prompt and (ii) my web searches, which for a 2008-filing patent with only two forward citations is a low-signal regime. I could not complete a final corroborating pull of the aggregator's PTAB-challenge record for US-8775574-B2 (search-step limit reached), though an earlier pass returned "No data." If a recently filed, not-yet-indexed petition exists, it would be less than ~18 months old and would not yet have produced an institution decision. Treat the "zero proceedings" finding as strong but re-verify at PTAB E2E before relying on it in a filing.

I'll cross-reference the authoritative patent text against live sources before writing up the record.

Let me verify there's no litigation or NPE assertion history before finalizing.

US 8,775,574 B2 — Ownership & Assignment Reconstruction

Patent: Remote network management having multi-node awareness
Appl. No.: 12/324,781 · Filed: 2008-11-26 · Granted: 2014-07-08 · Pub.: US 2010/0131625 A1 (2010-05-27)
Current assignee of record: Red Hat, Inc. (Google Patents legal events; Unified Patents portal also lists Red Hat Inc as assignee)

Inventors

Employer inference is well-grounded here, not merely a guess: both named inventors executed assignments to Red Hat, Inc., and the "Adrian Karstan Likins / Raleigh, NC" address recurs on Red Hat's sibling patent US 9,313,105 ("Network management using secure mesh command and control framework"), same inventive team.

Unusual patterns: None of the classic fire-sale tell (all inventors bailing out within 12 months of filing). I found no verified data on either inventor's departure date, so I will not speculate. Note, however, an administrative anomaly: DeHaan's assignment was executed and recorded on the filing date (2008-11-26), while Likins' first assignment was executed 2008-11-08 but not recorded until 2012-05-23 — more than three and a half years late — followed by a second, confirmatory Likins→Red Hat assignment on 2012-08-29. This is a paperwork-cure pattern, not a transfer pattern (both instruments run to the original assignee).

Original assignee

Red Hat, Inc. (Raleigh, NC; incorporated in Delaware, listed in the 2008 assignment record as a Virginia/North Carolina entity).

• Line of business: Enterprise open-source software — Red Hat Enterprise Linux, Red Hat Network (RHN), and the systems-management platform that became Red Hat Satellite. This patent is squarely in that product line.
• Did they ship a product embodying the claims? Yes, to a high degree of confidence. The claims (dependency-ordered, centrally orchestrated configuration orders pushed to multiple nodes) map directly onto Red Hat Network Satellite / Red Hat Satellite, which Red Hat marketed as centrally managing "provisioning, configuring, and updating systems" across "thousands of systems," including configuration drift remediation and remote execution across groups of systems. Red Hat's own Satellite 5-era datasheet describes centralized multi-organization satellite management, configuration channels, and scheduled actions across a network — the commercial embodiment of the "management server ... sequence ... first node ... second node" claim structure.
• Current status: Operating, as a wholly-owned subsidiary of IBM. IBM announced the $34B acquisition on 2018-10-28 and closed it on 2019-07-09; Red Hat continues to operate as a distinct unit within IBM's Cloud and Cognitive Software segment (redhat.com/investors; IBM press release 2019-07-09). No change-of-name or merger assignment was recorded against this patent, which is consistent with Red Hat, Inc. surviving as a subsidiary rather than being merged away.

Assignment timeline

Three assignment records are indexed. All three run to the original assignee, Red Hat, Inc. There is no recorded transfer out of Red Hat, no security interest, no license, and no release.

• 2008-11-26 (executed) / recorded 2008-11-26 — Reel 021898/0024

  • Conveyance: Assignment
  • Assignor: Michael Paul DeHaan
  • Assignee: Red Hat, Inc.
  • Correspondent: Not disclosed in the indexed record. (The patent's prosecution attorney of record is Lowenstein Sandler LLP / Red Hat, Roseland, NJ — a different field from the assignment correspondent, so I do not attribute Lowenstein to this recording.)
  • Context: Original inventor-to-employer assignment, executed on the filing date.

• 2008-11-08 (executed) / recorded 2012-05-23 — Reel 028257/0353

  • Conveyance: Assignment
  • Assignor: Adrian Likins
  • Assignee: Red Hat, Inc.
  • Correspondent: Not disclosed in the indexed record.
  • Context: Late-recorded / nunc pro tunc inventor assignment to the same employer — a paperwork cure, not a third-party transfer.

• 2012-08-29 (executed) / recorded 2012-08-29 — Reel 028884/0545

  • Conveyance: Assignment
  • Assignor: Adrian K. Likins
  • Assignee: Red Hat, Inc.
  • Correspondent: Not disclosed in the indexed record.
  • Context: Confirmatory assignment from the same inventor under an expanded name form ("Adrian K. Likins" vs. "Adrian Likins"), likely correcting the earlier instrument.

On correspondents: the Assignment Center records for this patent do not surface a correspondent of record in the indexed data, and no attorney's name recurs across the three links. I therefore cannot run the repeat-correspondent analysis the way one can on an NPE chain — and this absence is itself mildly probative, since a classic troll chain shows a single filing attorney stamped on every sequential LLC transfer.

If a reader finds additional recorded assignments at the Assignment Center that are not mirrored in the Google Patents legal-events table, treat them as controlling — Google's legal-events feed is a convenience mirror and has been known to lag.

Timeline diagram

timeline
    title Ownership of US 8775574
    2008 : Filed 26 Nov by Red Hat
         : DeHaan assigns to Red Hat
    2010 : Application published
    2012 : Likins assignments recorded to Red Hat
    2014 : Patent issued to Red Hat
    2019 : Red Hat acquired by IBM

NPE / troll-pattern signals

Mechanical detail worth flagging for maintenance purposes: a maintenance-fee reminder was mailed 2026-02-23 (FEPP, large entity) against this patent. The grants ledger still shows it "Active, expires 2029-09-12," but a lapsed-fee event would render the remaining asset unenforceable. Anyone valuing the family should confirm the 12-year fee was actually paid.

Verdict

Insufficient data — and that is a favorable result, not an inconclusive one.

The chain consists of nothing but the original inventor→employer assignments (reels 021898/0024 of 2008-11-26, 028257/0353 recorded 2012-05-23, and 028884/0545 of 2012-08-29), all naming Red Hat, Inc., which remains the assignee of record and is today an operating IBM subsidiary that ships a commercial embodiment (Red Hat Satellite). None of the eight NPE signals is supported by a single reel/frame or dated event, so no NPE label is warranted. I decline "Operating-company assertion" too, precisely because the discipline of this exercise cuts both ways: there is no assertion — no suit naming this patent — so calling it an assertion posture would overstate the record.

Verify at: https://assignmentcenter.uspto.gov/ (search patent 8775574) and https://assignment.uspto.gov/patent/index.html

I'll ground this in the authoritative USPTO/Google Patents record for the '574 patent and verify the key cited references before mapping them to claims.

Let me verify a few more of the closest prior-art references before drafting.

Prior-Art Analysis — U.S. Patent No. 8,775,574 B2

Patent under analysis: US 8,775,574 B2, "Remote network management having multi-node awareness" — Appl. No. 12/324,781, filed 2008-11-26, granted 2014-07-08, Red Hat, Inc. (DeHaan & Likins).

Identifier discipline: Every number below is taken literally from the '574 record. I did not fold in look-alike numbers. Note in particular that several Juniper configuration-patch patents surfaced in search — US 7,483,965, US 7,558,835 — which are related to but distinct from the cited US 7,865,578; they are not on the '574 citation list and are not treated here. Likewise, US 8,073,557 (Roy-G-Biv) is unrelated.

1. How to read this report

(a) Governing law — pre-AIA. The '574 application was filed 2008-11-26, before the AIA first-inventor-to-file provisions took effect (2013-03-16). Pre-AIA 35 U.S.C. §102 therefore controls, including §102(a) (known/used/patented/published before invention), §102(b) (publication or patent more than one year before filing, i.e., before 2007-11-26), and §102(e) (US patent/published application by another, effective as of its filing date). A cited reference can only be §102(a)/(b)/(e) art if its qualifying date precedes the relevant date.

(b) "Cited on the face" ≠ "anticipates." The '574 patent lists 70 patent citations on its face. A citation list is a disclosure-duty/IDS artifact, not a finding of anticipation. Anticipation under §102 requires a single reference disclosing every element of a claim as arranged. Most of these 70 are, at most, §103 obviousness references — and several are not prior art at all (see §6).

(c) The three independent claims — the elements any anticipatory reference must hit. Independent claims 1 (method), 6 (system), 12 (non-transitory CRM) each require, in combination:

1. management server accesses per-node configuration data for a first node and a second node;
2. in view of a received global command, generates a set of configuration orders — a first order tailored to node 1's config data, a second order tailored to node 2's config data;
3. determines a transmission sequence in view of a configuration dependency between the two nodes;
4. transmits the first order in view of the sequence AND in view of a predetermined schedule or predetermined triggering event; and
5. in view of a determination that the first order has been transmitted, transmits the second order.

Element 3 + element 5 together are the heart of the invention (centralized, dependency-ordered, gated multi-node push). Very few cited references disclose either, and none I could verify discloses both in a single reference. Expect §103, not §102, as the operative attack.

(d) Source confidence. The citation list, dates, and titles below come from the authoritative '574 record supplied and were spot-verified against Google Patents, FreePatentsOnline, Justia, and Espacenet (URLs cited inline where checked). I could not pull a USPTO PatentCenter face-page for all 70 in this session; treat the tables as high-confidence but verify any single reference you intend to rely on in a filing. (Housekeeping flag: the system clock reads 2026-09-28 while the task header reads 2026-04-26; this does not affect the analysis, which is date-independent.)

2. TIER 1 — Most relevant prior art (goes to independent claims 1 / 6 / 12)

These are the references that actually touch the centralized/multi-node/order-sensitive configuration concept. Ranked by closeness to the claim combination.

3. TIER 2 — Relevant to specific limitations / dependent claims

4. TIER 3 — Cited but background/remote (brief)

These appear on the face of '574 but bear only tangentially on the claims. I list them for completeness; none is a realistic standalone §102 reference and each is, at best, cumulative §103 art in the monitoring/alerts/inventory space.

Monitoring / alerting / event handling: US 6,157,128 (Wookey et al., 2000-11-28); US 6,327,677 (Garg et al./Proactive Networks, 2001-12-04); US 6,263,455 (Bannister/AT&T, 2001-07-17); US 6,915,457 (Miller/Nortel, 2005-07-05); US 7,373,553 (Tripp et al./HP, 2008-05-13); US 2003/0177412 A1 (Todd/IBM, 2003-09-18); US 2005/0066218 A1 (Stachura et al., 2005-03-24); US 6,611,869 (Eschelbeck et al., 2003-08-26); US 6,529,784 (Cantos et al./Caldera, 2003-03-04).

Config/state management & inventory (generic): US 6,721,880 (Pike/Lucent, 2004-04-13); US 6,636,521 (Giulianelli/Lucent, 2003-10-21); US 2003/0120754 A1 (Muto et al., 2003-06-26); US 2004/0006546 A1 (Wedlake et al., 2004-01-08); US 2004/0032625 A1 (Yamano, 2004-02-19); US 2004/0034577 A1 (Van Hoose et al., 2004-02-19); US 2004/0198319 A1 (Whelan et al., 2004-10-07); US 2006/0161444 A1 (Microsoft, 2006-07-20); US 2007/0005661 A1 (Yang, 2007-01-04); US 2007/0027936 A1 (Stakutis et al., 2007-02-01); US 2007/0288530 A1 (Xeround, 2007-12-13); US 2008/0091466 A1 (Hospira, 2008-04-17); US 2008/0219563 A1 (Moroney et al., 2008-09-11); US 2008/0244047 A1 (Inventec, 2008-10-02); US 2009/0070442 A1 (Kace Networks, 2009-03-12); US 2009/0193413 A1 (Lee Moso, 2009-07-30); US 2009/0276772 A1 (Garrett et al., 2009-11-05); US 2009/0276620 A1 (Microsoft, 2009-11-05); US 2010/0077076 A1 (Canon, 2010-03-25); US 2010/0198964 A1 (Tanaka, 2010-08-05); US 2010/0257047? — no such entry; ignore. US 2006/0031188 A1 (Lara et al., 2006-02-09); US 2007/0074077 A1 (Markow, 2007-03-29); US 2007/0266124 A1 (UPS, 2007-11-15).

Post-'574-date items appearing in the same Google "Citations" table (NOT §102(a)/(b)/(e) art — see §5): US 2010/0185590 A1; US 2010/0218014 A1; US 2010/0275064 A1 (DeCusatis/IBM); US 2011/0047414 A1 (Kudo/Hitachi); and the Red Hat/DeHaan 2009–2011 siblings (US 2010/0223375; US 2010/0223274; US 2010/0306347; US 2010/0306334; US 2010/0306359; US 2011/0055361; US 2011/0055810; US 2011/0055669; US 2011/0055636; US 2011/0078301; US 2011/0107299).

5. Two same-inventor / same-assignee references — special handling

Flagging these explicitly because a careless search would mislabel them as straightforward prior art against '574. They are common-ownership, common-inventor documents.

6. What on this list is not prior art to '574

1. Everything with a qualifying date after 2008-11-26 cannot be §102(a)/(b)/(e) art against '574. That eliminates the DeHaan 2009–2011 siblings, US 2010/0185590, US 2010/0218014, US 2010/0275064, US 2011/0047414, and similar late entries. They belong to the forward-citation / same-family noise of the Google table, not to the backward prior-art set.
2. EP2108656A1 — "Antigenic protein fragments of streptococcus pneumoniae" — Beninati, Concetta. This appears under the record's "Family Cites Families" field. It is a vaccine/immunology document with zero technical relation to network configuration management. It is a data artifact in the citation mapping and must not be treated as prior art. Calling it out so it cannot be mistaken for a substantive reference.

7. Bottom line — best candidates by claim

Most important caution: the closest-looking references (Halpern-US 7,660,824, Perry-US 7,441,021, Gerraty-US 7,865,578) are centralized configuration distribution references. None of them, as far as I could verify their disclosures, (i) derives a transmission sequence from an inter-node configuration dependency, or (ii) conditions the second transmission on determination that the first was transmitted. Those two limitations are the '574 patent's point of novelty over the pull-based, per-machine systems (puppet/cfengine) the specification itself disparages. Any §102 argument must produce a single reference that teaches both; any §103 argument must supply a rationale to combine two or more of Tiers 1–2 to reach them.

8. Caveats on completeness

• I verified the existence, dates, and subject matter of the Tier-1/Tier-2 references through Google Patents, Espacenet, FreePatentsOnline, and Justia (links above). I did not obtain the full specification of all 70 references, so my "what each reference discloses" descriptions are drawn from abstracts/summaries and the '574 record; verify claim-by-claim disclosures against full texts (and their file histories) before any §102/§103 position is filed.
• My §102 "anticipation" calls are preliminary and negative-biased: anticipation is a demanding standard, and I have deliberately not asserted anticipation where I could not confirm all elements in one reference.
• Pre-AIA §102(e) date analysis for pre-grant publications depends on the reference's earliest effective US filing date and "by another" status; I flagged the same-inventor cases (§5) but did not reconstruct §102(e) priority chains for every publication.
• No §102(b) on-sale/public-use art (a 2007-11-26 cutoff) is captured by the citation list at all — that is a separate search space (e.g., RHN/Satellite product documentation, puppet/cfengine public use) and arguably the most promising §102 avenue given the spec's own admissions.

Primary sources:

• '574 record & citation list: https://patents.google.com/patent/US8775574/en · https://www.freepatentsonline.com/8775574.html · https://patents.justia.com/patent/8775574
• US 7,660,824: https://patents.google.com/patent/US7660824B2/en
• US 7,441,021: https://patents.google.com/patent/US7441021 · Espacenet US7441021 B1
• US 7,865,578: https://www.freepatentsonline.com/[7865578](/patent/7865578).html
• US 2008/0016186: https://patents.google.com/patent/US20080016186A1/en

If you want, I can next build: (a) a full element-by-element claim chart for claims 1/6/12 against the Halpern + Perry combination, or (b) a pre-2007-11-26 §102(b) public-use search plan targeting Red Hat Network Satellite and the puppet/cfengine admissions in the '574 background.

I'll ground this analysis in the cited-art record before constructing the § 103 combinations. Let me pull details on the key backward-citation references.

Good grounding on the core references. Let me check the dependency-ordering art and the admitted background art (puppet/cfengine).

Obviousness Analysis — U.S. Patent No. 8,775,574 B2 under 35 U.S.C. § 103

Patent: US 8,775,574 B2 — "Remote network management having multi-node awareness"
App. No.: 12/324,781 · Filed/Priority: 2008-11-26 · Granted: 2014-07-08 · Assignee: Red Hat, Inc.
Independent claims analyzed: 1 (method), 6 (system), 12 (non-transitory CRM) — all three recite substantively identical steps
Prior art basis: the 70-item "Patent Citations" / reference list appearing in the Prior Art section of this patent page

⚠️ Two cross-reference flags before I begin.

1. Date inconsistency. The system context for this session states today is 2026-09-28; the task header says April 26, 2026. I treat the later date as controlling for status recency. Neither date affects the § 103 analysis, which is driven by the 2008-11-26 critical date.
2. Do not use the "Cited By" entries as prior art. The two forward citations on this page — US 10,033,835 B2 (Alibaba, priority 2015-06-09) and US 10,771,332 B2 (Microsoft, priority 2014-06-06) — both post-date the '574 filing by 6–7 years. They are § 102(a)(1)/§ 103 art-against-them, not art-against-'574. Any obviousness theory built on them is legally void. The "Family Cites Families (34)" table is likewise a forward-citation list; only the one entry with a pre-2008 priority (US 7,370,092 B2, Computer Sciences Corp., 2002-09-12, "System and method for enhanced software updating and revision") is even arguable, and its family placement is anomalous (a 2002 document cannot cite a 2008 family), so I treat it as citation-table noise rather than a usable reference. This is consistent with the previously generated PTAB section's warning not to mistake citation tables for proceedings — the same discipline applies to citation tables as art.

1. Governing legal framework

Because the application was filed 2008-11-26, pre-AIA § 103 governs. Prior-art status is measured under pre-AIA §§ 102(a)/(b)/(e)/(g). No inter partes review was ever filed, so there is no § 315(e)(2) estoppel, no Board claim construction, and no § 325(d) "same art" risk — every ground below remains squarely available (consistent with the earlier PTAB section).

The controlling obviousness standard is KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007): a claim is obvious if the differences between the claim and the prior art are such that the subject matter as a whole would have been obvious to a PHOSITA, considering (i) the scope and content of the art, (ii) the differences, (iii) the level of ordinary skill, and (iv) secondary considerations. Under KSR, a combination can be obvious where the improvement is a predictable use of prior-art elements according to known methods yielding no more than expected results, where a design incentive or market pressure points to the solution, or where the solution was "obvious to try" from a finite number of identified, predictable options.

Level of ordinary skill (PHOSITA): a person with a bachelor's degree in computer science, computer engineering, or electrical engineering and 2–4 years of experience in network/systems-management software (provisioning, configuration management, or remote administration), or an equivalent combination of education and experience. This is the level the specification itself presumes (FIG. 3 describes a conventional server with a Linux/Unix OS, database, and browser-based console).

flowchart LR
    A["Claim 1 element A<br/>Central server accesses per-node config data"] --> B["Element B<br/>Global command → node-specific orders"]
    B --> C["Element C<br/>Dependency → transmit sequence"]
    C --> D["Element D<br/>Transmit 1st order (schedule/trigger)"]
    D --> E["Element E<br/>Determination 1st sent → transmit 2nd"]

2. Claim 1 (and 6, 12) — element-by-element prior-art mapping

Note on element E. The claim's trigger is worded around transmission ("a determination that the first configuration order has been transmitted"), whereas the '574 specification frames the true problem as directing one machine to act "after another machine successfully completes action Y." BEA '824's conditional activation sits between those two readings: it is a determination that the first order was transmitted-and-accepted before the next command issues. If the district court construes "transmitted" narrowly (mere dispatch), BEA '824's distribution step alone still satisfies element E, because BEA distributes the change to involved managed servers and only then transmits the separate activation signal. Either construction is met. This is the single most important mapping in the analysis — it is the limitation most likely to be argued as the point of novelty.

3. Combination #1 — the primary § 103 ground

Primary references:

• US 7,661,024 B2 — Paclat, Halpern & Spotswood (BEA Systems), "System and method for performing batch configuration changes," filed 2005-05-17, granted 2010-02-09 (pub. US 2005/0262101 A1). Pre-AIA § 102(a)/(b)/(e) art.
• US 7,441,021 B1 — Perry (Sun Microsystems), "Methods and apparatus for producing a configuration for components of a network," filed 2003-10-06, granted 2008-10-21. § 102(a)/(b) art (granted before the '574 filing).
• US 2006/0004806 A1 — Kraft, "Updating data in a multi-system network that utilizes asynchronous message transfer," filed 2004-06-01, published 2006-01-05 (granted as US 7,392,265 B2). § 102(b) art.

Why every limitation reads on the combination.

Element A — BEA '824 discloses precisely the claimed architecture: an administration server (the claimed "management server") that generates "a system configuration change" and distributes it to "one or more managed servers" (the claimed remote "set of nodes"). The administration server "deems [which managed servers] will be affected," i.e., it holds/accesses configuration data keyed to each managed server. Sun '021 independently discloses a computerized device that "retrieves the hardware configuration information from the network components" and "obtains corresponding hardware configuration information associated with the network components," plus "software configuration information" for the application — exactly the "set of configuration data … first configuration data for a first node … second configuration data for a second node."

Element B — BEA '824: the administrator authors one configuration change through "an interface that may be made simple, transparent, and robust," and the system expands it into a per-server distribution, each managed server "compar[ing] the received configuration information to a configuration located on the managed server." That is a single global command differentiated into node-specific orders. Sun '021 adds that the deployment instructions are generated per component: the device "automatically … outputs the correlation result to support automatic configuration of the network components and the software," creating "one or more configuration orders [reflecting] the configuration template(s)." The two references together cover both prongs of element B (global-command origination from BEA; per-node order generation from Sun).

Element C — Sun '021 expressly teaches that installation must occur in a defined order and that the automatic deployment instructions minimize "user error during the installation procedure (e.g., performing the steps of the installation in an order different than the order listed in the markup language document)." A PHOSITA reading Sun '021 in 2008 would immediately recognize that "an order different than the order listed" is precisely the dependency order between components of a multi-node application. Kraft '806 supplies the multi-node coordination layer: it discloses three networked systems (a "first system 20 … second system 30 … third system 40") that each maintain data and exchange messages to keep the system-of-systems consistent — establishing, as of 2004, that a central element of multi-node management was coordinating actions across distinct machines.

Element D — BEA '824 discloses scheduled batch distribution ("the changes are activated… the administration server sending an activation signal to each of the involved managed servers") and the deferral of some changes "unless the server is restarted," i.e., a predetermined schedule or event/timing condition. Symantec '9990 (below) adds the trigger variant.

Element E — as detailed in §2 above, BEA '824 conditions the activation transmission on each managed server's returned "validation ok" signal. The second order is therefore transmitted "in view of a determination that the first configuration order has been transmitted." The claim does not require the determination to be of completion — only of transmission — so BEA '824's stronger gating step reads on the claim a fortiori.

Motivation to combine (KSR).

1. Same field, same problem, same artisan. All three references are network/systems-management art addressing remote configuration of multiple machines from a central point — the field the '574 specification itself names.
2. The patent's own admitted problem supplies the motivation. The '574 Background states the goal in terms: existing pull-based systems (puppet, cfengine) are "only capable of operating on a specific machine," "do not contain the ability to resolve dependencies, and direct one machine to do action X after another machine successfully completes action Y." An express statement of the problem in the specification is itself evidence that a PHOSITA would look to the cited multi-node art for the solution (KSR; In re Kahn).
3. Predictable combination of known elements with expected results. Combining BEA '824's central batch-distribution mechanism with Sun '021's per-component, order-aware deployment-instruction generator yields nothing more than the expected sum of the two: centralized distribution of correctly ordered, per-node instructions. No new structural or functional principle is required, and the references are analogous art (all H04L 41/08, configuration management of networks).
4. Design incentive / market pressure. BEA '824 and Sun '021 both expressly motivate automation to "minimize the administrator's time" and "minimize user error." The '574 specification touts the identical benefit ("comparatively compact command structures," no host-by-host updates) — confirming the pre-existing demand.

4. Combination #2 — secondary ground adding the scheduling/trigger reference

Add: US 7,769,990 B1 (Symantec Corp.; "Using a monitoring process to update system configuration settings during restore operations," filed 2007-03-23, granted 2010-08-03 — § 102(e) art as of its 2007-03-23 filing).

'574 claim 1 requires transmission "in view of at least one of a predetermined schedule or a predetermined triggering event." BEA '824 alone supplies the schedule prong (batched activation, reboot-pending deferral). If a court reads "triggering event" narrowly (i.e., not a mere admin toggle), Symantec '9990 closes the gap expressly: a monitoring process detects a condition and drives a configuration-setting update — precisely the claim's "predetermined triggering event," and the same mechanism the '574 specification describes at FIG. 4 ("receipt of notification of a hardware change," "an application fault or detection of a virus").

Motivation: Symantec '9990 and BEA '824 are both configuration-management-of-networked-machines art; a PHOSITA seeking to automate updates without an operator typing commands (the stated goal of both) would predictably substitute a monitored condition for a manual command as the initiator. KSR ("A person of ordinary skill is also a person of ordinary creativity").

5. Combination #3 — the "different orders / node template" ground (dependent claims)

Add:

• US 2002/0184349 A1 — Manukyan, "Method and system for automatically configuring a client-server network," published 2002-12-05 (§ 102(b)) — central automatic configuration of a client-server network, with configuration driven from a central point to differentiated clients.
• US 7,865,578 B1 — Shafer (Juniper Networks), "Generation of a configuration patch for network devices," filed 2006-11-20 (CIP of an application filed 2002-08-19) — a management module generates a configuration patch representing "differences between the working copy and the initial data source" and applies it; the patch "may be communicated to other network devices" (§ 102(e)/§ 102(b)).
• US 6,721,880 B1 — Lucent, "Method and apparatus for maintaining configuration information in a computing environment" (granted 2004-04-13) — maintaining per-machine configuration information.

These are chiefly relevant to claims 2/7/13 ("node template specifying … hardware resources, software resources, or network settings") — Sun '021's "hardware configuration information" + "software configuration information" retrieved per network component is a direct anticipation-grade teaching of a node template — and to claims 5/11 ("first and the second configuration orders are different"), which BEA '824 supplies by distributing different changes to different "involved managed servers" depending on each server's compared running state, and Manukyan supplies by configuring heterogeneous clients differently.

Claims 3/8/14 ("software installation order, software update order, software inventory order, hardware inventory order, security order, or node restore order") — BEA '824 (update/activation), Sun '021 (installation + software identification/inventory), and Symantec '9990 (restore) collectively disclose each listed order type. Note for later: the Markush-style "at least one of … or" format in claims 3/8/14 invites a § 112(b) indefiniteness attack independent of § 103.

Claims 4/10 ("set of hosts and a set of targets associated with the set of hosts") — Sun '021's network components plus Manukyan's client-server clients read on this; the host/target split is a conventional network-management architecture.

6. Where the cited art is genuinely weak — and how a challenger must fill the gap

I will not overstate the record. Element C ("determining … in view of a configuration dependency between the first node and the second node, a sequence") is the load-bearing limitation, and the cited-art list is thinnest precisely there. The cited references show:

• ordering of installation steps within a deployment (Sun '021 — same-machine step order), and
• order-invariant consistency of multi-system data (Kraft '806 — asynchronous reconciliation, not sequenced commands), and
• point-in-time config patching on a device (Juniper '578).

None of the 70 cited references, standing alone, discloses computing an inter-node dependency graph and using it to sequence transmission between two distinct machines. That is the '574 patent's actual point of novelty, and it maps onto the specification's single worked example (FIG. 2: machine A = UI logic, B = database, C = backend, D = backup server).

A challenger must therefore supplement the cited-art list with art teaching dependency-ordered multi-node execution. The most probative supplemental categories are:

• Build/dependency-resolution tooling (e.g., make, ant, RPM/yum dependency graphs) — dependency-DAG-ordered actions, long pre-2008.
• Workflow/job-scheduling orchestration (Tivoli, HP OpenView, BMC) — cross-machine task sequencing.
• Cross-server provisioning art — e.g., the later Oracle/Oracle-family line (US 10,291,467 / US 10,897,394, "Deploying a server stack having a cross-server dependency," which expressly recites "requisite servers" and "dependent servers" and "a particular sequence for re-provisioning") — but caution: these have 2016 priority and are not prior art to '574; they are cited here only to show that cross-server dependency sequencing remained a recognized, solvable problem, and to guide a search for the pre-2008 equivalent. Do not plead them as § 103 art.
• The applicant's own co-pending applications, which are § 102(e) art against '574 if the inventive entity differs:
  • US 2009/0300180 A1 (DeHaan, "Systems and methods for remote management of networked systems using secure modular platform," filed 2008-05-30) — incorporated by reference into '574 itself; § 102(e) art as of 2008-05-30.
  • US 2010/0088197 A1 (DeHaan, "Systems and methods for generating remote system inventory capable of differential update reports," filed 2008-10-02) — § 102(e) art as of 2008-10-02.
    Because both bear 2008 filing dates before the '574 filing date and name a different inventive entity (DeHaan alone vs. DeHaan + Likins), they are candidate § 102(e) references — a point worth early diligence, given how tightly the '574 claims track the Red Hat provisioning portfolio.

Bottom line on the gap: element C is where a defendant should expect a Markman fight and where the plaintiff's infringement case is strongest. The cited-art combinations above render elements A, B, D, and E clearly obvious and element C arguably obvious in view of Sun '021's explicit order-of-installation teaching plus the ordinary knowledge of a PHOSITA who deploys multi-tier applications (database → application → presentation). A § 112(a) written-description squeeze also lurks here: the entire written description for "configuration dependency" is the single FIG. 2 example, so if a plaintiff reads the claims broadly onto arbitrary topologies, enablement/description becomes a live counterattack (a point flagged in the earlier PTAB section and reinforced here).

7. Secondary considerations (Graham factor 4) — preliminary read

No evidence of secondary considerations is in the record for this patent, and the earlier sections establish the relevant posture:

• No nexus evidence of unexpected results; the claimed benefit (central, order-aware, multi-node push) is exactly the expected result of combining BEA '824 + Sun '021.
• No commercial-success evidence tied to the claims as opposed to Red Hat Satellite generally; and any Satellite success owes to features far beyond claims 1/6/12 (Red Hat Satellite practices the prior-art field broadly).
• No licensing program, no assertion history (per the prior Litigation and Assignment sections), so no "industry acquiescence" or "copying" evidence exists.

On the current record, secondary considerations do not rebut the obviousness showing.

8. Conclusion

Most likely-to-succeed single ground: US 7,661,024 B2 + US 7,441,021 B1 (+ US 7,769,990 B1 for the trigger prong). This pairing was before the examiner (both appear in the '574 reference list), which cuts two ways — it supports the § 103 motivation (KSR: the artisan had the references), but it also means a reexamination/IPR petitioner must show the combination was not previously considered, and a § 325(d) argument is not available since no IPR was ever filed.

Recommended posture (consistent with the earlier sections' "defensive-portfolio, untested-claims" finding): because every one of the 14 claims is PTAB-untested with no estoppel lockout, a challenger may run any § 102/§ 103 ground. Prioritize (a) a Markman position on "configuration dependency," "global command," and "configuration order"; (b) the element-E "transmitted" vs. "successfully completed" distinction (a potential non-infringement escape hatch that is not an invalidity point); and (c) supplementation of the cited-art list on element C with pre-2008 dependency-orchestration art.

Confidence, caveats, and limits of this analysis

1. I analyzed only the references actually listed on this page. The "Prior Art" section of the patent page supplies 70 cited references; the strongest combination (BEA '824 + Sun '021) is grounded in verbatim excerpts I retrieved for both, and in Symantec '9990, Kraft '806, Juniper '578, and Manukyan '0184349 by title/abstract. I did not obtain the full text of UPS US 2007/0266124 A1, McData US 2007/0038679 A1, or Yamamoto US 2003/0208589 A1 (my search step limit was reached), so I cite them only by title as candidate element-C art and do not assert what they disclose.
2. Element C is the analytical weak point, and I have said so plainly rather than papering over it. Do not represent to a court that the cited art, standing alone, renders the dependency-sequencing limitation obvious without a supplemental reference or an expert declaration on the knowledge of a PHOSITA.
3. This is a validity opinion on the intrinsic and cited-art record only. It is not a freedom-to-operate or infringement analysis, and it does not account for prosecution-history estoppel, later-acquired art, or a court's eventual claim constructions.
4. Status caveat carried forward: a maintenance-fee reminder dated 2026-02-23 is on the record with the patent still listed Active (expiration 2029-09-12), and the 12th-year fee status was not confirmed. If the fee lapsed, the obviousness question becomes moot as a practical matter — verify on Patent Center before commissioning an invalidity workup.