US 6058445

I'll verify this against live sources before summarizing.

Let me check for litigation/appeal activity and verify assignee details.

Let me pull the claim set to identify the independent claims precisely.

Verification summary

Sources checked: Google Patents full text for US6058445A (https://patents.google.com/patent/[US6058445](/patent/US6058445)/en), FreePatentsOnline record (https://www.freepatentsonline.com/[6058445](/patent/6058445).html — claim text), EveryPatent claim listing (http://www.everypatent.com/comp/pat6058445.html), plus targeted searches for litigation/appeal activity.

CAFC 2026 docket check — negative result. My searches returned no Federal Circuit docket entries, opinions, or 2026 appeal activity tied to patent 6,058,445. I also found no USPTO PTAB proceeding naming it (the USPTO petition documents surfaced by search involve unrelated patents, e.g., the '844 patent and the Adaptix '445 patent). I cannot confirm any appeal or IPR involving this patent; treat that as "no evidence found," not as proof of none.

⚠️ Conflation warning (honored literally): search hits reference a "'445 Patent" in the Adaptix v. ALU/AT&T/Verizon/Sprint complaint. That is U.S. 8,934,445 (Li et al., multi-carrier OFDMA) — a completely different patent. Do not merge it with 6,058,445. Likewise, the IPR/EIS documents discussing a '844 patent and US 6,105,089 are separate instruments.

---

US 6,058,445 — Bibliographic data

Assignee caution: Google Patents lists two "current assignees," and its own notice warns the list "may be inaccurate." I have not independently verified present-day ownership; the reassignment chain above is what the record shows.

---

Abstract (as published)

"A data management method supports hot plug operations on a computer by defining, organizing, and maintaining hot plug variables which identify components of a computer that may be involved in hot plug operations, and which also identify capabilities and operational states of those components as well as control their operation and interface to the computer. The hot plug variables identify a component as well as represent states and capabilities of a component, and thus the hot plug variables advantageously operate as commands to predetermined components. The method generally selects a plurality of variables to support adding a component to or exchanging components of a computer while the computer runs, and collects in a computer readable medium, hot plug variable data representing capabilities, characteristics or states of components of the computer… The method supports generating, with management software running on a client computer, requests such as a suspend device driver request, a power off request, a power on request, and a resume device driver request, and sending the requests over a network to agent software running on a server computer…"

---

Independent claims in plain language

The specification's "Summary of the Invention" enumerates six distinct inventive embodiments, each corresponding to an independent claim. Four are confirmed by claim text; the other numbered independents are inferred (flagged).

Claim 1 — Managing a computer's configuration (confirmed, matches Summary ¶1).
Extend a MIB module with variables chosen to support hot-adding, hot-removing, and hot-swapping computer components while the computer runs; store the MIB on a computer-readable medium; compile the MIB module to produce a binary MIB; and generate a "hot plug MIB table" holding variable data corresponding to those MIB variables, where the data represents capabilities, characteristics, or states of the computer's components.

Claim ~11/12 — Managing hot plug data to hot add or hot swap (inferred; matches Summary ¶2).
Simply: select a set of variables supporting add/remove/exchange on a running computer, store them on a medium, and collect hot plug variable data into a computer-readable medium, the data describing component capabilities/characteristics/states and being related to those variables. (Exact claim number not confirmed.)

Claim ~20 — Refreshing hot plug variables (inferred number; matches Summary ¶3). Confirmed only that claim 20 exists as a parent (claim 21 depends from it) and that a dependent claim recites "a retrieve data routine running on said client computer."
Hot plug variables (including existing component data identifying a server component) reside in a client computer's storage; poll the server's component(s) at a predetermined interval for new component variable data; and refresh the client's variables by storing the new data to supersede the old. (Inferred mapping to ¶3 of the Summary.)

Claim 23 — Making hot plug variables available to a software module (confirmed, verbatim).
Store a binary hot plug MIB on the computer, generated by compiling (with a MIB compiler) a hot plug MIB module whose variables support hot add/remove/exchange on a running computer and which specifically include (a) a power state variable for regulating a component's power and (b) a component state variable for suspending or resuming a component's operation; then access data in that binary hot plug MIB with software running on the computer.

Claim 24 — Network variant of claim 23 (confirmed text; independence uncertain).
Same storing/accessing framework as claim 23, plus: store the binary hot plug MIB on a second computer linked by a network, and access its data with software on the second computer that controls hot plug operations on the first computer. (The retrieved excerpt begins mid-claim, so I flag its exact preamble/independent status as not fully verified.)

Claim 25 — Controlling a server's hot plug operations from a client (confirmed, verbatim). A 13-step method:

1. Prepare a hot plug MIB module defining hot plug MIB variables;
2. compile it to a binary MIB module;
3. distribute that binary to storage on both client and server;
4. poll server components to produce server-side hot plug MIB variable data;
5. refresh client-side hot plug MIB data by sending the server-side data to the client;
6. generate (with client-side management software) a suspend device driver request tied to a component state variable;
7. send it to server-side agent software, which recognizes it and suspends the driver;
8. generate a power off request tied to a power state variable;
9. send it; the agent recognizes it and stops power to a component;
10. generate a power on request tied to a power state variable;
11. send it; the agent recognizes it and starts power;
12. generate a resume device driver request tied to a component state variable; and
13. send it; the agent recognizes it and resumes the driver.

Claim 26 — Updating hot plug data for a newly connected component (confirmed, verbatim).
Prepare a MIB module defining hot plug variables for a class of components that can connect to a computer; compile it into a binary hot plug MIB; connect a component of that class to the computer; prepare hot plug MIB variables on the computer corresponding to that class; poll the component to obtain its hot plug MIB variable data; and update the MIB variables with the obtained data.

(Dependent claims 2–~19, 21–22, and any dependent claims under 24–26 are not reproduced here; I did not retrieve their full text, so I make no representation about them.)

---

Practical/technical context disclosed

The patent's worked examples target SNMP-based management over Windows NT: a client-side manager called Maestro and a server-side SNMP agent plus SNMP extension agent, talking to device drivers configuration manager (adapters/drivers) and Intrapulse manager (slots, canisters, power supplies, system boards), with a binary MIB.INI file. The extended subMIB sits under the enterprise node netframe and defines group nodes (trapGroup, adapterGroup, driverGroup, slotGroup, canisterGroup, systemGroup, coolingGroup, powerGroup, cpuGroup, slotFanGroup), with concrete object identifiers such as 1.3.6.1.4.1.837.2.4.1.1.6.1.3 (slot power state) and 1.3.6.1.4.1.837.2.2.1.1.5.n (adapterCommand). Figures 6–10 describe hot-add and hot-swap flows for both non-canister (8 PCI slots, individually power-switched) and canister-based (4 canisters × 4 slots) servers, using suspend → power-off → physical swap → power-on → resume → verify sequences.

Uncertainty flags (explicit)

• Claim numbering for the "refresh" and "manage hot plug data" independents is inferred, not confirmed; total claim count (26) rests on claim 26 being the terminal claim in the retrieved text.
• Claim 24's independent status is unverified (partial text).
• No CAFC 2026 docket or PTAB activity for 6,058,445 was found; absence of evidence here is not a negative finding.
• Current ownership is reported inconsistently by the aggregator (Round Rock Research LLC and Mei California Inc both listed); I did not verify the live assignment record beyond the recorded chain of reassignments.

I'll research litigation involving US Patent 6058445.

Those results concern a different patent (the '844 patent). Let me search more specifically for this patent and its owner.

Let me check the specialized patent litigation databases directly.

Findings: Litigation Involving U.S. Patent No. 6,058,445

Short answer: I could not identify any court case that specifically names U.S. Patent No. 6,058,445 ("Data management method for adding or exchanging components on a running computer") as an asserted patent. I want to be explicit about that rather than present inference as fact.

What the searches did establish

1. Ownership / provenance of the '445 patent (relevant because ownership drives litigation risk):

• The patent issued 2000-05-02 to Micron Electronics, Inc., on an application (US 08/942,124) filed 1997-10-01, claiming priority to provisional 60/046,310 dated 1997-05-13.
• Per the Google Patents record, the chain of title runs: Micron Electronics → MEI California, Inc. (2001) → Micron Technology, Inc. (2001) → Round Rock Research, LLC (2010-01-04). The current listed assignees are Round Rock Research LLC / Mei California Inc.
• Status: Expired – Lifetime (anticipated expiration 2017-10-01).

Source: Google Patents US6058445A — https://patents.google.com/patent/US6058445A

2. Round Rock Research LLC is a litigious NPE, which is why its portfolio is the natural place to look:

• Round Rock acquired roughly 3,000–4,500 Micron patents in Dec. 2009/Mar. 2010 and, founded by John Desmarais, filed a large 2010–2015 campaign against HTC, Dell, Acer, Asus, SanDisk, Amazon, Canon, JVC Kenwood, Oracle, Macy's, PepsiCo, and others.
• Sources: Stanford NPE Litigation Database (Round Rock Research LLC party page, https://npe.law.stanford.edu/party/round-rock-research-llc); Justia dockets; Unified Patents / PTAB petitions.

3. But the Round Rock dockets that surfaced asserted other patents, not the '445 patent. Examples I found:

• Round Rock Research LLC v. SanDisk Corp., No. 3:11-cv-05243-RS (N.D. Cal.) — asserted U.S. Pat. Nos. 6,570,791; 6,845,053; 5,682,345; 6,383,839.
• Round Rock Research LLC v. Canon Inc. et al., No. 1:14-cv-01457 (D. Del., filed 2014-12-03) — asserted 5,986,347; 6,147,405; 6,358,801; 6,455,935; 6,459,617; 6,828,683.
• Round Rock Research, LLC v. Oracle Corp. et al., No. 4:11-cv-00332 (E.D. Tex.) — asserted a different set of patents.
• Stanford NPE database entries for Round Rock (1:11-cv-01279 Amazon; 1:11-cv-01238 American Apparel; 1:11-cv-01237 Macy's; 1:11-cv-01244 PepsiCo; 1:14-cv-01458 JVC Kenwood).

None of these lists the '445 patent.

Important caveats on my search

• My tool queries returned no result that ties the number "6,058,445" (or "6058445") to any civil action, case number, or docket entry. Because you instructed me to interpret identifiers literally and not to substitute "similar numbers," I have not treated the many '844/'445-adjacent results (e.g., the Ingevity '844 patent, Docker/American/Southwest IPRs on a different '844 patent) as being this patent. Those are different patents entirely.
• The absence of a hit in the sources I reached is not proof that no suit exists — it means the number did not surface in the sources I could access before hitting my search limit. Litigation databases index asserted patents at the complaint level, and a patent can be named only as one of dozens of asserted patents or appear only in a "Report on the Filing or Determination of an Action Regarding a Patent" form, which can be missed by keyword searches.

Recommended verification (to confirm definitively)

To close this out with confidence, check these directly, searching the exact string 6,058,445:

1. Unified Patents litigation portal — https://portal.unifiedpatents.com/litigation/caselist (search the patent number).
2. Stanford NPE Litigation Database — https://npe.law.stanford.edu/patent/6058445 (the per-patent page format; e.g., https://npe.law.stanford.edu/patent/[6459726](/patent/6459726) shows the structure).
3. RPX Insight — https://insight.rpxcorp.com/patent/US6058445A (it has a "litigation" tab tied to this exact patent page).
4. PACER / CourtListener RECAP — full-text search for the patent number in complaints.
5. PTAB / USPTO PatentCenter — search for IPR/PGR/CBM or reexamination proceedings involving the patent (none appeared in my results, but confirm).

Bottom line

• Plaintiff/defendant, jurisdiction, case number, filing date, outcome: I have no verified litigation for U.S. 6,058,445 to report.
• Current status: The patent is expired (term ended 2017-10-01), which substantially reduces the likelihood of active assertion, though expired patents can still appear in already-filed cases (and Round Rock's campaign ran mostly 2010–2015).
• The patent sits in the Round Rock Research LLC portfolio (ex-Micron), an entity with substantial litigation history, but I found no case specifically asserting this patent number.

I'd rather flag this as an open item for direct database confirmation than assert a case that I cannot source. If you can share a candidate case name or docket, I can try to verify it against the patent number specifically.

I'll start by checking whether any AIA trial proceedings exist for this patent, since the structured ODP block reports none.

The initial results are noise (they concern a different "844" patent owned by Intellectual Ventures). Let me run more targeted searches.

No proceedings found yet. Let me probe specific databases and related litigation.

PTAB Proceedings Report — US 6,058,445

"Data management method for adding or exchanging components on a running computer"
Patent owner of record: Round Rock Research, LLC (originally Micron Electronics, Inc.)
Priority date 1997-05-13 · Filed 1997-10-01 · Granted 2000-05-02 · Expired 2017-10-01

---

Proceedings overview

Zero AIA trial proceedings are on file against US 6,058,445 — the USPTO ODP structured data reports no IPR, PGR, or CBM, and independent web searching surfaced no petition, institution decision, Final Written Decision, or Federal Circuit appeal naming this patent; the tally is therefore 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denials. The bottom-line defensive posture is not "the patent survived IPRs and is hardened," but something more favorable still: there is no PTAB record at all, and the patent expired on 2017-10-01, so the usual estoppel-hardening narrative is irrelevant — a defendant's real leverage is expiration and the § 286 damages bar, not an IPR record.

No proceedings to report

I cannot populate per-proceeding sections (### IPR{xxxx}-{xxxxx} — Petitioner v. Patent Owner) because no proceeding number exists to cite, and the instructions forbid inventing one. What I checked and found:

Caution on "’445" shorthand. Several unrelated patents are commonly cited as "the '445 patent" and will pollute any manual docket search — e.g., Adaptix's US 8,934,445, Kidde's US 7,525,445, and various pharma patents (US 7,525,445-style shorthand appears in ANDA suits). None of those involve US 6,058,445. A defendant's counsel searching PTAB by "445" may get false positives; search on the full number 6,058,445 or application 08/942,124.

Caveat on the "absence" inference. An empty PTAB docket is often read as "not worth challenging." Here that reading is partly wrong. Round Rock Research was a highly active acquirer/assertor (roughly 20+ infringement suits against Acer, Amazon, Dell, HTC, Lenovo, Oracle, SanDisk, Nintendo, and others, mostly in D. Del.). Its 2014 enforcement wave used the memory/semiconductor patents (US 6,828,683; 6,358,801; 6,147,405; 6,455,935; 5,986,347; 6,459,617; 6,424,594; 6,469,336) — a different slice of the portfolio. I found no campaign that turned this hot-plug/MIB patent into a litigation target, which is the most likely reason no IPR was ever filed. I could not confirm this from a primary source, so treat it as a reasoned inference, not a documented fact.

---

Strategic summary

Canceled vs. sustained vs. untested claims. There is no claim-level PTAB record, so every claim of US 6,058,445 remains exactly as issued — no claim has been canceled, disclaimed by amendment, or narrowed by an adverse Final Written Decision. Note that the full claim set was not reproduced in the text provided to me (the excerpt ends in the Detailed Description), so I cannot quote or enumerate the claims; I simply have no basis to say any of them was addressed at the Board. If you need the claim numbers, pull the printed patent (front page and columns following the specification) or the USPTO PatentCenter "Claims" tab — do not rely on this report for claim text.

Estoppel landscape. Because no IPR was ever instituted, 35 U.S.C. § 315(e)(2) estoppel never attached to anyone. There is no petitioner, no real party in interest, and no privy barred from raising prior-art grounds. A defendant today can raise any § 102/§ 103 ground, in district court or before the Board, subject only to ordinary rules (e.g., § 315(b) time bar running from service of a complaint; § 325(d) discretion if the art was already before the examiner; the ITC/PTAB overlap rules). In other words, the usual "IPR petitioner forfeited grounds A–D" analysis simply doesn't apply — there is no forfeiture to inherit or to fear.

Pattern signals. No serial petitioner (a petitioner cannot be serial if there is no first petition). No evidence of a defensive aggregator such as Unified Patents in the chain for this patent. No appellate history: because there is no FWD and no appealable Board decision, there is no Federal Circuit docket and nothing on CourtListener for this patent. The one dominant governing fact is expiration: the patent lapsed 2017-10-01 (20 years from the 1997-10-01 non-provisional filing) and its status is "Expired – Lifetime."

The expiry point is the whole ballgame. Infringement liability for a patent ends at expiration, and § 286 limits recovery to damage accruing within six years before the complaint is filed. Since the last possible accrual date here is 2017-10-01, any past-damages window closed by roughly 2023-10-01. As of today (2026-09-28), a demand letter or suit asserting this patent is, on its face, time-barred for damages — a far stronger defense than any IPR outcome. That, not PTAB activity, is what a defendant should lead with.

---

Recommended next steps

1. Lead with expiration and § 286, not the IPR docket. Confirm the term from the front page (filing 1997-10-01, no term extension noted) and the Google Patents legal-status field ("Expired – Lifetime," anticipated expiration 2017-10-01): US6058445A on Google Patents. Then confirm no continuation/reissue keeps live claims on the same subject matter — a reissue or continuation in the same family would change the calculus.
2. Verify there is truly no co-pending proceeding under a different identifier. I searched by patent number only. Run the patent (not "445") through PTAB E2E and PEDS to confirm zero trials and to check for any ex parte reexamination or reissue, which would not appear as an AIA trial but could still bear on validity.
3. If a demand letter cites this patent, do not bother budgeting an IPR. An IPR on an expired patent is legally permissible but economically pointless: no available estoppel benefit, no live injunction exposure, and claim construction under Phillips rather than the BRI. The only realistic Board-side use would be a narrow coordination with a stay motion, and even that is weak against an expired patent.
4. Keep district-court invalidity, especially § 101, alive. A 1997-software MIB/hot-plug method patent is squarely in the Alice crosshairs; that ground was never tested, in court or at the Board, so it remains fully available to a defendant.
5. Milestones: none. There are no pending trials, no institution deadlines, no oral-hearing dates, and no FWD due dates to track, because there is no instituted proceeding.

Bottom line for a defendant: there is no PTAB story here — and that is the point. The patent has never been tested at the Board, has no cancellation to lean on, and has been expired since 2017-10-01. Treat any present assertion as a § 286 timeliness problem first and an invalidity problem second.

Limitation: I was unable to reach any primary PTAB record because none appears to exist, and my web access hit its step limit before I could exhaustively sweep every secondary aggregator. Treat the "zero proceedings" conclusion as consistent with the canonical ODP block and the searches actually run, and re-verify against PTAB E2E before relying on it in a filing.

I'll research the assignment record for US 6,058,445, focusing on reel/frame numbers and correspondents of record.

I found reel/frame leads from a sibling patent. Let me verify specifically for the '445 patent and the Round Rock transfer.

I'll search for the reference citations on US 6,058,445's face. Let me run several targeted queries.

Let me get the complete reference list and filing dates.

Prior-Art / § 102 Analysis — U.S. Patent No. 6,058,445

Patent: US 6,058,445 A — "Data management method for adding or exchanging components on a running computer"
App. No. 08/942,124 · filed 1997-10-01 · priority to provisional 60/046,310 (1997-05-13) · granted 2000-05-02 · Expired – Lifetime (2017-10-01)

Date flag (not corrected): this task states "Current Date: April 26, 2026," while the system context says 2026-09-29. Immaterial to a § 102 analysis of a 1997-priority patent; noted for the record only.

Builds on prior sections. Per instruction I do not repeat the earlier Patent summary, Obviousness, Litigation, PTAB, or Assignment sections. Where those flagged uncertainty (the "refresh" and "manage hot plug data" independents are inferred numbers; claim 24's independence unverified), I key this analysis to claim subject matter and say so.

---

0. Sourcing and a candid limitation — read this first

What I actually retrieved. I was able to pull the patent's front-page "References Cited → U.S. Patent Documents" block from two independent mirrors of the USPTO front-page data:

• FreePatentsOnline — https://www.freepatentsonline.com/6058445.html (reverse-chronological, upper part of the list, ~issue dates 1999-08 back to 1998-06)
• EveryPatent — http://www.everypatent.com/comp/pat6058445.html (chronological, lower part of the list, issue dates 1991-03 to 1997-08)

The two snippets do not perfectly overlap, so there is a coverage gap in the middle of the list (roughly references issuing between Aug 1997 and Jun 1998). I also could not retrieve the Foreign Patent Documents and "Other References" (NPL) blocks. Issued U.S. references I can positively identify are listed in § 1; I make no representation about references in the gap or about foreign/NPL art.

Hard stop reached. My search tool returned "maximum number of steps" on my last three queries, so I could not verify filing dates for most references (critical under § 102(e), see § 2) and could not confirm the complete list. Treat everything below as provisional pending a PatentCenter "References Cited" pull.

No auto-correction. All numbers are read literally as written in the sources. Where a source's digits look like a typo (e.g., Austruy class "631/58"), I reproduce it as-is and flag it rather than "fixing" it.

---

1. References cited on the face of US 6,058,445 (as retrieved)

1a. From FreePatentsOnline (issued 1998-06 → 1999-08)

1b. From EveryPatent (issued 1991-03 → 1997-08) — titles not shown by source

(Table split for width; the middle rows of group 1b — issue dates ~1995-08 to 1996-07 — were partly cut off in the retrieved snippet and are marked "[gap]"/omitted. I do not fabricate the missing entries.)

Observation that matters for the whole analysis: the overwhelming majority of cited references issued in 1996–1999. For a patent whose invention date is ~1997-05-13, an issued U.S. patent is prior art under § 102(a) only if it issued before the invention date, and under § 102(b) only if it issued before 1996-10-01. References issuing in 1998–1999 are therefore not § 102(a)/(b) art. They can be prior art only under § 102(e), via their U.S. filing dates — which I largely could not verify (§ 2).

---

2. The § 102 timing trap (why "cited" ≠ "anticipating")

For a pre-AIA application filed 1997-10-01 with a ~1997-05-13 invention date:

Verified § 102(e) dates (from prior work sessions, carried forward):

Bottom line: only Guthrie, Beatty, and Lichtman are confirmed § 102(e) art today. Every other 1998–1999 reference in § 1 is, on the record I hold, not yet established as prior art at all — its § 102(e) filing date must be pulled. Several 1996–1997 references (e.g., 5,604,873 Feb-1997; 5,621,892 Apr-1997; 5,632,021 May-1997) are not § 102(b) art (issued after 1996-10-01) and are § 102(a)/(e) art only if their filing dates (or the invention date) so permit.

---

3. Per-reference analysis — the most probative cited references

For each I give full citation, dates, brief description, and the claim(s) it could potentially anticipate under § 102. Anticipation requires a single reference disclosing every element of a claim, arranged as in the claim (Net MoneyIN v. VeriSign; MPEP § 2131). Where a reference discloses only part of a claim, I say so and note it is § 103 material, not § 102 — cross-referencing the earlier Obviousness section rather than re-deriving combinations here.

R1 — US 5,784,576 (Guthrie et al.) — the strongest § 102 candidate

• Citation: U.S. Pat. No. 5,784,576, "Method and apparatus for adding and removing components of a data processing system without powering down," issued 1998-07-21; filed 1996-10-31. Assignee IBM. Class 395/283. Google Patents US5784576A
• Description: PCI hot-plugging via in-line switch modules and a "Control & Power Logic" block controlling (i) access to each secondary PCI bus, (ii) power to each slot, and (iii) switch gating, across HPREQ lines and slot registers (PRSNT1/2, door-switch, clock, reset, power). Expressly frames the operation as "hot-plugging a device."
• Potentially anticipates: the method claims reciting per-slot power control on a running computer — i.e., the power-state-variable element of claim 23 and the power-off/power-on steps of claim 25 — if the claim is read to the hardware/control level. Caution: Guthrie is a hardware/bus-power reference; it does not disclose a MIB, a binary MIB, or MIB variables, so it cannot anticipate any independent claim that requires a MIB. It is a § 102 target only for a claim hypothetically directed to slot-power switching alone, and none of the ’445 independents is that narrow.

R2 — US 5,781,798 (Beatty et al.) — driver suspend/resume antecedent

• Citation: U.S. Pat. No. 5,781,798, "Method and apparatus for providing hot swapping capability in a computer system with static peripheral driver software," issued 1998-07-14; filed 1996-11-18 (continuation of 1993-12-30). Assignee IBM. Class 395/830. FPO 5781798
• Description: Hot-swap with a "static" driver; detects insertion/removal; builds an inter-device communications (IDC) packet containing a command word (install/de-install) plus slot ID, IRQ, port, bus address; the static driver allocates/releases resources after initialization. Background expressly states the goal of inserting/removing devices "while the associated computer continues to operate."
• Potentially anticipates: the driver-suspend / driver-resume subject matter of claim 23's "component state variable" and the suspend/resume steps of claim 25 — again only at the driver-control level. Beatty has no MIB, no client/server mgmt-agent architecture, and no power-variable-per-se; it therefore cannot anticipate the independents textually.

R3 — US 5,787,246 (Lichtman et al.) — configure-on-connect antecedent

• Citation: U.S. Pat. No. 5,787,246, "System for configuring devices for a computer system," issued 1998-07-28; filed 1994-05-27. Assignee Microsoft. Class 395/200.5. EveryPatent 5787246
• Description: Detecting devices on a system bus, assigning a unique device identification code, appending a bus code, obtaining logical configuration data, and identifying/loading a device driver "without user intervention."
• Potentially anticipates: the "class of components → connect → poll the component → update" flow of claim 26. Lichtman is the closest cited reference to claim 26's steps (1)-(5); however, claim 26 also requires "compiling the MIB module to generate a binary hot plug MIB" and "updating the hot plug MIB variables," which Lichtman does not disclose. On the record I hold, Lichtman is therefore § 103 art against claim 26, not clean § 102 anticipation — unless the MIB limitation is met by a separate reference (see Obviousness § 3, Combination 6).

R4 — US 5,913,037 (Spofford et al.) — the MIB reference, but a § 102(e) timing risk

• Citation: U.S. Pat. No. 5,913,037, "Dynamic management information base manager," issued 1999-06-15; filing date UNVERIFIED. Class 709/226. Unified Patents US-5913037-A
• Description: Runtime management/extension of a MIB.
• Potentially anticipates: the "extending a management information base module" and "generating a … MIB table" elements of claim 1, and the binary-MIB-with-software-access framework of claim 23. Critical caveat: because it issued in 1999, Spofford is prior art only under § 102(e), and its filing date is not verified. If its filing date is after 1997-05-13, it is not prior art at all and R4 drops out entirely. This is the single most important verification item (carried forward from the Obviousness section).

R5 — US 5,812,750 (Dev et al.) — polling/refresh antecedent

• Citation: U.S. Pat. No. 5,812,750, "Method and apparatus for monitoring the status of non-pollable devices in a computer network," issued 1998-09-22. Class 395/182.02. (Related to cited US 5,261,044, Dev et al., issued 1993-11.)
• Description: Polling/status monitoring of network devices.
• Potentially anticipates: the "polling, at a predetermined time interval …" and "refreshing the hot plug variables …" steps of the refresh independent (Summary ¶3; number inferred). Alone it does not disclose hot-plug variables; it is closer to § 103 art. Note its 1993 sibling 5,261,044 is clean § 102(a)/(b) art (issued Nov 1993), which strengthens the Dev family's prior-art status even though 5,812,750 itself depends on § 102(e).

R6 — US 5,768,541 (Pan-Ratzlaff) — hot-plug on a running PC

• Citation: U.S. Pat. No. 5,768,541, "System for hot-plugging peripheral device to computer bus and disconnecting peripheral device upon detecting a predetermined sequence of keystrokes inputted by user through keyboard," issued 1998-06-16. Class 395/283.
• Description: Hot-plugging a peripheral to a computer bus, with disconnection gated on a keystroke sequence.
• Potentially anticipates: the "hot add" (running-system component addition) concept underlying several claims. It lacks MIB/variable and remote-management elements, so it too is § 103 material, not standalone anticipation.

R7 — US 5,577,946 (Bender et al.) and R8 — US 5,621,892 (Cook) — context only

• US 5,577,946, Bender et al., 1996-11-19 issue (EveryPatent lists "Nov., 1996"; the FPO-adjacent Google record shows 1996-11-19), class 364/146, "Icon based process design and control system." Note: this patent separately appears in Google Patents as citing US 6,058,445 (a forward citation, not relevant to the ’445 patent's own prior art). Its relevance on the ’445 face is as monitoring/control-UI background.
• US 5,621,892, Cook, issued 1997-04-22 (source showed Apr-1997; exact day not captured), class 395/200 — network/environment monitoring background.
• Both are background/§ 103 art; neither discloses MIB-based hot-plug management and neither anticipates any independent claim.

R9 — The 1997-05 cluster: US 5,632,021 (Jennings), US 5,638,289 (Yamada), US 5,651,006 (Fujino), US 5,652,892 (Ugajin), US 5,655,081 (Bonnell)

All issued 1997-05-20 → 1997-08-26. Because they issued after the 1996-10-01 § 102(b) cutoff and around/after the ~1997-05-13 invention date, they are prior art only under § 102(e) (or not at all), depending on filing dates I could not verify. Their subject matter (bus mastering 5,632,021; CAD 5,638,289; ATM 5,651,006; power management 5,652,892; network/system monitoring 5,655,081) is background. Bonnell (5,655,081, "…") and Ugajin (5,652,892, power management) are the most conceptually adjacent (monitoring; power state) but still do not anticipate — no MIB-based hot-plug variable management.

R10 — Everything else in § 1 (telephony, DRAM emulation, switches, connector hardware, etc.)

References such as 5,907,610 (telephony central offices), 5,901,304 (DRAM emulation), 5,910,954 (network switch), 5,340,340 (Hastings, connector 439/64), and 5,272,584 (Austruy; class shown as "631/58" — reproduced literally, likely a source typo) are technologically remote. They were cited for general context and do not anticipate any claim.

---

4. Bottom line — which claims, if any, are potentially anticipated

Conclusion: On the references retrieved on the face of US 6,058,445, no single reference anticipates any independent claim under § 102. Every independent claim contains at least one element — typically the MIB authoring/compilation step or the hot-plug variable table — that no cited reference discloses. The cited references are therefore § 103 (obviousness) material, which the earlier Obviousness section has already worked through; I do not re-derive those combinations here.

The three references that are confirmed prior art today (Guthrie, Beatty, Lichtman) are not the MIB reference, and the one MIB reference (Spofford) is the one whose prior-art status is unverified. That asymmetry is the crux of any validity challenge.

---

5. Verification items (explicit)

1. Confirm the complete "References Cited" list — including the coverage gap (~Aug 1997–Jun 1998) and, importantly, the Foreign Patent Documents and "Other References" (NPL) blocks, which I could not retrieve and which often carry better art (e.g., the PCI Hot-Plug Specification Rev. 0.9, Mar. 5, 1997, and the IBM TDB 92A+62947 card-hot-plug disclosure referenced from sibling Micron patents). Pull the USPTO PatentCenter "References Cited" PDF.
2. Verify the § 102(e) filing dates for every 1997–1999 reference in § 1, Spofford first. Until then, only Guthrie/Beatty/Lichtman are established prior art.
3. Confirm claim text/numbering from the printed patent before citing claim numbers — per prior sections, the "refresh" and "manage hot plug data" independents are inferred and claim 24's independent status is unverified.
4. No auto-correction applied — e.g., Austruy US 5,272,584's class "631/58" is reproduced as retrieved.

Sources this session: FPO US6058445 · EveryPatent US6058445 · Google Patents US6058445A · Google Patents US5784576A · FPO US5781798 · EveryPatent US5787246 · Unified Patents US-5913037-A. (Filing dates for all other references remain unverified — search limit reached.)

I'll verify the key references' disclosure dates and content before building the §103 combination analysis, since the enablement of each combination turns on whether each reference actually qualifies as prior art and what it teaches.

Let me nail down the remaining reference dates and the two most probative references' disclosures, since anticipation/obviousness timing is dispositive for a 1997-priority patent.

Obviousness Analysis — U.S. Patent No. 6,058,445

Under 35 U.S.C. § 103 (pre‑AIA)

Patent: US 6,058,445 A — "Data management method for adding or exchanging components on a running computer"
App. No. 08/942,124 · filed 1997‑10‑01 · priority to provisional 60/046,310 (1997‑05‑13) · granted 2000‑05‑02
Status: Expired – Lifetime (2017‑10‑01)

Date note (flagged, not corrected): this task states "Current Date: April 26, 2026," while the system context says 2026‑09‑28. I treat the difference as immaterial to the §103 analysis, but the §285/§286 timeliness discussion in the earlier PTAB Proceedings section is keyed to the later date.

Cross‑reference discipline: this section builds on, and does not repeat, the prior Patent summary, Prior art, PTAB Proceedings, Assignment, Litigation, and Agreement sections. Where those sections flagged uncertainty (inferred claim numbers for the "manage hot plug data" and "refresh" independents; unverified independent status of claim 24), I key the analysis to claim subject matter and say so.

---

0. The legal frame that actually governs

Because the application was filed 1997‑10‑01, pre‑AIA § 103(a) applies. Obviousness is judged under Graham v. John Deere Co., 383 U.S. 1 (1966) (scope/content of prior art; differences; PHOSITA level; secondary considerations) as refined by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007). No rigid TSM test is required; what is required is an articulated reason why a PHOSITA would have combined the references with a reasonable expectation of success. KSR, 550 U.S. at 418; MPEP §§ 2141–2144. Issued claims carry a § 282 presumption of validity; invalidity must be proven by clear and convincing evidence.

PHOSITA definition (1997): a bachelor's degree in CS/EE (or equivalent) plus ~2–3 years' experience in server firmware/device‑driver development, or a master's plus ~1 year, with working familiarity with PCI enumeration, BIOS runtime services, SNMP/MIB management, and OS/2 or Windows NT driver models.

---

1. Threshold issue: which references even qualify as prior art?

This is the single biggest analytical trap in the record, and it is where the previously generated Prior art table (organized by issue date) can mislead. Under pre‑AIA law:

• § 102(a) — a reference patent is "patented" as of its grant date; it is prior art under § 102(a) only if that grant predates the applicant's invention date (~1997‑05‑13).
• § 102(b) — printed publication/patent more than one year before 1997‑10‑01, i.e. before 1996‑10‑01.
• § 102(e) — a U.S. patent is prior art as of its earliest effective U.S. filing date, provided that date precedes the invention date.

Consequence: nearly every reference in the Prior art table issued in 1998–1999 — after the '445 priority date. They therefore cannot be § 102(a)/(b) art. They qualify, if at all, only under § 102(e), via their filing dates. I verified the filing dates for the four most important references:

Practical effect: Guthrie, Beatty, and Lichtman are solid § 102(e) art (all filed before 1997‑05‑13). Spofford is the linchpin MIB reference and its § 102(e) date is unconfirmed — if it was filed after 1997‑05‑13, every combination below that leans on it for the "extend/compile/access a MIB" limitation must be re‑plumbed with substitute MIB art. I flag this as the first thing to verify (see § 9). The same § 102(e) verification is needed for Dev (US 5,812,750), Tezuka (US 5,764,911), Garvey (US 5,774,667), Graf (US 5,862,333), Guzak (US 5,838,319), Nguyen (US 5,826,046), and Ote (US 5,815,652).

No § 103(c) problem: Guthrie/Beatty are IBM, Lichtman is Microsoft, Spofford is (apparently) HP — none commonly owned with Micron at the time of invention, so none is disqualified from the § 103 analysis by common ownership.

---

2. What each reference actually contributes (content verified this session)

• Guthrie US 5,784,576 — PCI hot‑plugging implemented with in‑line switch modules, and critically a "Control & Power Logic" block that controls (1) access to each secondary PCI bus, (2) power to each slot, and (3) gating of the switch modules, operating across HPREQ lines and slot registers (PRSNT1/2, door‑switch, clock, reset, power). This is a direct hardware/control antecedent for the '445's slotPowerState, per‑slot power switch 700, and Intrapulse‑register writes. It expressly frames the operation as "Hot‑plugging a device."
• Beatty US 5,781,798 — hot swap with a "static" driver; detects insertion/removal, builds an inter‑device communications (IDC) data packet containing a command word (install / de‑install) plus slot ID, IRQ, port, bus address; the static driver then allocates/releases system resources after initialization. Its background expressly states the motivation: "the already significant utility of peripheral devices would be even greater if one were able to insert or remove them from the expansion slots while the associated computer continues to operate." This is the antecedent for the component‑state variable (suspend/resume driver) element of claim 23 and the suspend/resume requests of claim 25.
• Lichtman US 5,787,246 — detecting devices on a system bus, assigning a unique device identification code, appending a bus code, obtaining logical configuration data ("configuration requirements"), and identifying/loading a device driver — "without user intervention." This is a near‑literal antecedent for claim 26's "class of components," "connecting a component," and "polling the component."
• Spofford US 5,913,037 — dynamic MIB manager: runtime management/extension of a MIB. This is the antecedent for "extending a MIB module" and "generating a … MIB table."
• Dev US 5,812,750 / Thompson US 5,761,429 / Nguyen US 5,826,046 — polling and status monitoring of network devices (antecedent for the refresh/poll claim).
• Tezuka US 5,764,911 — synchronizing managed objects with physical state on a change notification (antecedent for trap‑driven refresh).
• Graf US 5,862,333 — central console controlling processes on a group of computers based on alerts (antecedent for the client‑side manager + trapGroup).
• Guzak US 5,838,319 — hierarchical/tree GUI control (antecedent for browsing MIB nodes).

Family‑adjacent NPL I surfaced (from sibling Micron patents, e.g. US 6,219,734 — Justia), to be treated as context, not confirmed on the '445 face: PCI Hot‑Plug Specification, Preliminary Rev. 0.9, Mar. 5, 1997; IBM Technical Disclosure Bulletin 92A+62947, "Method for Card Hot Plug Detection and Control," Oct. 1992; Compaq, "Where Do I Plug the Cable? Solving the Logical‑Physical Slot Numbering Problem," Dec. 1996; Herr et al., "Hot Swapping the PCI Bus," Linear Technology Magazine, Jun. 1997; Microsoft, "Supporting Removable Devices Under Windows and Windows NT," Aug. 13, 1997. Timing matters: only items published before ~1997‑05‑13 are clean § 102(a) art; the Jun./Aug. 1997 items would have to be sworn behind under 37 C.F.R. § 1.131 if the invention predates them.

---

3. Claim‑family element mapping and proposed combinations

The '445 claim set (per the prior Patent summary) comprises six inventive families. Below, each is keyed to subject matter because exact numbering for two independents remains inferred.

Combination 1 — Claim 1 (extend MIB → compile → hot plug MIB table)

Primary: Spofford 5,913,037 (extending/managing a MIB at runtime). Secondary: Guthrie 5,784,576 (add/remove component while the computer runs — power/switching/control logic). Tertiary: Lichtman 5,787,246 (collecting component characteristics/capabilities).

• Element gaps and their sources: MIB extension → Spofford. "Variables selected to support adding/removing/exchanging components while the computer runs" → Guthrie. "Binary MIB" from compiling → admitted prior art in the '445 specification itself, which concedes "MIB compilers are known in the art. Products such as IBM's NetView/6000™ or Hewlett‑Packard's Openview™ … provide MIB compilers." "Hot plug MIB table … representing capabilities, characteristics or states of components" → Spofford's MIB tables populated with Lichtman's device information.
• Motivation: See § 4.

Combination 2 — the "manage hot plug data to hot add/hot swap" independent (Summary ¶2)

Guthrie + Lichtman + Spofford. No compilation step, so this claim is weaker than claim 1; it requires only (a) selecting variables supporting running‑system add/remove/exchange and (b) collecting hot‑plug variable data describing component capabilities/states.

Combination 3 — Claim 23 (binary hot plug MIB with power‑state variable AND component‑state variable; software accesses it)

Primary: Spofford (binary MIB, software access). For the power‑state variable: Guthrie (Control & Power Logic + per‑slot power) and/or Pan‑Ratzlaff US 5,768,541 and the PCI Hot‑Plug Rev. 0.9 (Mar. 5, 1997) NPL. For the component‑state variable (suspend/resume): Beatty 5,781,798 (install/de‑install command packet controlling driver resources post‑initialization).

• This is the cleanest two‑reference‑plus‑MIB combination in the set, because claim 23's only "special" elements — a power state variable and a component state variable — are individually disclosed by Guthrie and Beatty respectively, and the claimed advance reduces to expressing those two known control parameters as MIB variables. That is a textbook KSR "known technique applied to a known device ready for improvement."

Combination 4 — the "refresh hot plug variables" independent (Summary ¶3)

Primary: Dev 5,812,750 (polling/status monitoring of network devices) or Nguyen 5,826,046 (polling/selection). Secondary: Garvey 5,774,667 (managing parameter settings across multiple network devices). Tertiary: Tezuka 5,764,911 (updating managed objects in conformity with a change notification — supports the trap‑triggered variant).

• The claim's "predetermined time interval" polling is the paradigm SNMP GET/GETNEXT polling loop; the '445 specification itself describes the "retrieve‑data routine" as a software‑timer‑driven loop, i.e. an implementation detail, not an inventive contribution.

Combination 5 — Claim 25 (the 13‑step client/server hot‑plug method) — the marquee claim

Core combination: Spofford (MIB module/compile) + Guthrie (power off/on) + Beatty (suspend/resume driver) + Dev/Garvey (poll & refresh) + Graf (central console controlling a group of computers) + Guzak (hierarchical browse/select display).

Assessment: every one of claim 25's 13 steps maps to a known element. Nothing in claim 25 recites a structural or algorithmic novelty beyond (i) expressing known hot‑plug controls as MIB variables and (ii) sequencing known hot‑plug steps into the conventional suspend → power‑off → replace → power‑on → resume flow that Guthrie and Beatty already describe at the hardware/driver level.

Combination 6 — Claim 26 (class of components; connect; prepare MIB variables; poll component; update)

Primary: Lichtman 5,787,246 (detect device → assign ID code → retrieve configuration data → identify/load driver, "without user intervention"). Secondary: Beatty 5,781,798 (insertion detection + IDC packet). Tertiary: Spofford (updating the MIB variables with the obtained data).

• Claim 26 is essentially Lichtman's configure‑on‑connect flow plus the step of updating a MIB variable table — the smallest delta of any independent claim.

---

4. Why a PHOSITA would have combined these references (the KSR/MPEP § 2143 rationales)

1. Combining prior‑art elements according to known methods, yielding predictable results. MIB‑based management (Spofford) and hot‑plug control (Guthrie, Beatty) were each known; joining them yields the expected result — remote, software‑controlled hot‑plug — with no change in the operation of either. MPEP § 2143(A).
2. Express motivation in the references themselves. Beatty's own background states the goal of adding/removing devices "while the associated computer continues to operate" and identifies the driver‑polling impediment; Guthrie frames the operation as "Hot‑plugging." A PHOSITA reading either would look to complementary driver‑ and power‑control mechanisms.
3. The patent's own Background supplies the reason to combine. The '445 specification admits that SNMP/MIB tools already existed for routine computer management, and that the field had "little if any focus on the area of adding or removing components to a running, operating computer." That admission is a powerful obviousness signal: the problem (apply established remote‑management tooling to the known hot‑plug domain) was known, and the solution was the predictable application of a known technique to a known device ready for improvement (KSR rationales (C)/(D); MPEP § 2143(C)).
4. Market/design pressure. The Background recites the business driver (downtime cost, I/O‑subsystem transient faults). Commercial and market pressures are recognized KSR motivations.
5. "Obvious to try" — finite, predictable solutions. Once one decides to manage hot‑plug remotely, the choice to reuse SNMP MIBs, to hold the table in RAM, to poll at a software‑timer interval, to group variables by component, or to trigger a refresh on a TRAP, are among a small, predictable set of options with anticipated results. KSR, 550 U.S. at 421. This point is decisive for the dependent claims (the "retrieve data routine running on said client computer," the trapGroup/threshold variables, the table‑in‑RAM limitations) — none of them recites an unpredictable technical effect.
6. Same field of endeavor / analogous use. All six references address configuration or management of computer hardware/servers; the differences among them (PCI slot control, PCMCIA driver hand‑off, bus enumeration, network MIBs) do not create a teaching away.
7. Predictability of the art. PCI hot‑plug was codified by March 1997 (PCI Hot‑Plug Spec Rev. 0.9) and card hot‑plug detection had appeared in the IBM Technical Disclosure Bulletin in Oct. 1992 — so the expectation of success in combining software‑based power/driver control with a management database was high.

---

5. Summary of proposed § 103 rejections, ranked by strength

Anticipation (§ 102) remains unavailable. As the prior Prior art section concluded, no single reference contains (i) MIB authoring/compilation, (ii) hot‑plug variable generation for running‑system add/remove/exchange, and (iii) client/server distribution and refresh with agent‑recognized suspend/power‑off/power‑on/resume requests. The § 103 routes above supply the missing pieces in combinations.

---

6. Graham factor 4 — secondary considerations (and the patentee's best rebuttals)

I found no evidence in the record of unexpected results, long‑felt but unmet need, industry praise, competitor copying, commercial success, or licensing attributable to this patent; I also did not specifically search for such evidence, so treat this as an open item rather than a negative finding.

The patentee's strongest non‑obviousness arguments would be:

1. "Different fields / no reason to look to PCMCIA or local OS/2 art." Beatty (static drivers, PCMCIA, OS/2) and Lichtman (bus enumeration) are local, non‑networked; Spofford (network MIBs) is remote. Rebuttal: KSR rejects a rigid field‑of‑endeavor test; the "field of endeavor" is computer configuration/hot‑plug management, and the problem addressed (avoiding downtime during component change) is common to all three.
2. "The references are hardware/driver‑level; the claims are management‑data‑level." Rebuttal: this is precisely a level‑of‑abstraction argument; representing a known power state and a known driver suspend/resume state as named MIB variables is a design choice, not an inventive step (KSR; MPEP § 2144.04).
3. Swearing behind. For the family‑adjacent NPL dated Mar.–Aug. 1997 (PCI Hot‑Plug Rev. 0.9; Herr; Goodrum; Microsoft "Supporting Removable Devices"), the patentee could attempt a § 1.131 affidavit if it can document an earlier conception/reduction to practice. But Guthrie (filed 1996‑10‑31), Beatty (filed 1996‑11‑18/1993), and Lichtman (filed 1994‑05‑27) are unaffected by any such affidavit.
4. § 101 overlay. Independently of § 103, a 1997 software/MIB method patent faces Alice exposure — noted in the prior PTAB Proceedings section and preserved here, but that is a § 101 ground, not § 103.

---

7. Strategic caveat: these references were of record

The references driving every combination above appear on the face of the patent (the References Cited block) — i.e., they were before the examiner, who nonetheless allowed the claims. Any renewed § 103 challenge therefore has an uphill burden: it must explain why the examiner's allowance was wrong, typically by (a) supplying a motivation‑to‑combine the examiner did not articulate, (b) assembling a combination the examiner did not consider, or (c) adding art not of record. Procedurally, if a challenge were filed as an IPR, § 325(d) would let the Board discretionarily deny on the ground that the same or substantially the same art was previously presented. There is, however, no § 315(e) estoppel to inherit, because — per the prior PTAB Proceedings section — no AIA trial was ever instituted against this patent.

The dominant practical fact remains expiration. As developed in the prior PTAB Proceedings and Litigation sections, the patent expired 2017‑10‑01 and any damages window closed by roughly 2023‑10‑01 under § 286. The obviousness analysis above is therefore most useful (i) defensively, in any already‑filed or time‑barred dispute, (ii) in evaluating a reissue/continuation that would attempt to keep the subject matter alive, or (iii) as a validity screen for the family's other members (e.g., US 6,105,089).

---

8. Bottom line

• § 102: no single one of the cited references anticipates any independent claim of US 6,058,445.
• § 103: the claims are substantially exposed. The strongest, most economical rejections are Lichtman + Spofford against the class‑update claim, Guthrie + Lichtman + Spofford against the hot‑plug‑data claim, and Spofford + Guthrie + Beatty against the binary‑MIB/power‑state/component‑state claim. The 13‑step client/server claim (claim 25) is covered only by a six‑reference combination, making motivation to combine — not element coverage — the contested issue there.
• The motivation story is unusually strong because the patent's own specification concedes both the existence of SNMP/MIB management tooling and the prior absence of hot‑plug focus, and because Beatty's background expressly articulates the goal of changing devices while the computer runs.

---

9. Limitations and required verification (explicit)

1. Spofford US 5,913,037's effective U.S. filing date is unverified. I hit my research‑step ceiling before confirming it. If it postdates 1997‑05‑13, it is not § 102(e) art and Combinations 1, 2, 3, 5, and 6 lose their MIB component; substitute MIB art would be required. Verify first.
2. Filing dates for Dev (5,812,750), Tezuka (5,764,911), Garvey (5,774,667), Graf (5,862,333), Guzak (5,838,319), Nguyen (5,826,046), and Ote (5,815,652) are unverified. All issue dates in 1998–1999 are after the priority date, so each depends on § 102(e) timing.
3. The complete citation list for the '445 face is not in hand. The prior Prior art section captured U.S. references only down to ~5,761,085; the Foreign Patent Documents and Other References (NPL) blocks were not captured. Better art may exist — e.g., the PCI Hot‑Plug Specification Rev. 0.9 (Mar. 5, 1997), PCI Bus Hot Plug Specification (Goodrum, Jun. 15, 1997), and Microsoft, "Supporting Removable Devices Under Windows and Windows NT" (Aug. 13, 1997) that surface in sibling Micron patents. Pull the USPTO PatentCenter "References Cited" PDF.
4. Claim numbering is partly inferred. Per the prior Patent summary, the "manage hot plug data" and "refresh" independents are inferred, and claim 24's independent status is unverified. This analysis is keyed to claim subject matter; substitute the true numbers from the printed patent before using it in a filing.
5. Witness/perfection gaps. A final § 103 position would need pin cites (column/line) into each reference for each claim element; I have described the disclosures at the abstract/claim level, not with column‑and‑line citations.
6. No secondary‑considerations search was run (see § 6).

Sources relied on this session: Google Patents US6058445A · Google Patents US5784576A · uspto.report 5784576 · Google Patents US5781798A · FPO 5781798 · uspto.report 5781798 · EveryPatent 5787246 (US 5,787,246) · Unified Patents US‑5913037‑A · Justia US 6,219,734 (sibling NPL listings) · FPO 6058445 (per prior section).