US 8909772

I'll verify against live sources before summarizing.

Let me check for any litigation or post-grant proceedings involving this specific patent.

Summary of U.S. Patent No. 8909772

Important search caveat: The tools available to me are general web search engines, not a direct, authenticated query of the USPTO PatentCenter/PTAB docket system or the CAFC 2026 argument/decision docket. I ran targeted searches for "8909772" in combination with litigation, IPR/PTAB, and CAFC terms. No litigation, IPR/PGR, or CAFC proceeding involving U.S. 8909772 was found. The only search hits for "8909772" were the patent's own Google Patents page and identification of the number as part of a different patent's proceedings (U.S. 7,535,890, an unrelated Uniloc patent asserted against Facebook/WhatsApp). Treat the absence of litigation as "not found in my searches," not as affirmative proof of a clean litigation history.

Bibliographic data (from the authoritative full text)

Source: https://patents.google.com/patent/US8909772/en

Abstract (as issued)

A system for monitoring a number of HDDs arranged in a number of servers of a data center, comprising a number of BMCs configured to obtain a state of each HDD in a server and output corresponding status information, a control module, and a display module. The control module includes an address storage unit storing IP addresses corresponding to the BMCs, a request unit configured to receive a request for obtaining the status information of each HDD coupled to each BMC, and an analyzing unit configured to obtain the status information outputted by the BMC and analyze it to obtain the state of each HDD. The display module displays the state of each HDD.

Independent claim (claim 1) in plain language

There is only one independent claim in this patent. Claim 1 is a system claim requiring four cooperating elements:

1. A plurality of BMCs (baseboard management controllers), each connected to corresponding HDDs, that (a) obtain the statuses of their HDDs and (b) output status information reflecting those statuses.
2. A control module containing three specific sub-units:
   • an address storage unit that stores multiple IP addresses, each mapped to a BMC;
   • a request unit that receives a request to obtain the status information of each HDD coupled to each BMC; and
   • an analyzing unit that obtains the status information output by the BMC and analyzes it to derive the status of each HDD.
3. A display module connected to the control module that displays the status of each HDD.
4. The overall framing: the HDDs are arranged in a plurality of servers within a data center.

Conceptually, claim 1 is a centralized, network-based monitoring architecture — BMCs harvest drive status locally, a client-side control module addresses those BMCs by stored IP address, polls/requests and parses their reports, and a display presents drive health to the operator. Notably, claim 1 itself does not recite the SGPIO transport, the three-bit message packet, the LED, or the site-mapping/location feature — those are all in dependent claims.

Dependent claims (for completeness)

• Claim 2 — adds a site-mapping unit storing each server's location in the data center. When the analyzing unit detects an abnormal HDD, it looks up the BMC's IP address from the address storage unit and resolves the corresponding physical location from the site-mapping unit, and the display shows that location.
• Claim 3 — defines the status information as three-bit SGPIO message packets: bit 1 = HDD operating status, bit 2 = connection status, bit 3 = HDD status; the analyzing unit reads bit 3 to decide whether the HDD is working normally and, if not, resolves the location via the BMC's IP address.
• Claim 4 — adds a per-HDD LED that is off when the HDD is abnormal (i.e., the monitored condition mirrors the physical LED state).
• Claim 5 — recites that the control module communicates with the BMCs through an SGPIO bus.

Analytical notes / points of uncertainty

• Apparent internal inconsistency in claim 5. The specification describes the BMCs obtaining HDD status over an SGPIO bus 300, and the control module communicating with the BMCs through the network 302 (e.g., "a control module 10 connected to the BMCs through a network 302"; the request unit "sends the request... to the BMC according to the IP address"). Claim 5 instead states the control module communicates with the BMCs "through a serial general purpose input output (SGPIO) bus." Read literally, claim 5 appears to conflict with the described embodiment, since IP-address-based requests over a network and an SGPIO bus are different transports. This is an observation about the claim language as issued, not a legal conclusion about validity or claim construction.
• Numbering typo in the specification. The description says "the second BMC 30 and two other HDDs 50 coupled to the second BMC 20" (referring to BMC 20 in the context of BMC 30) and elsewhere the request unit is called "request unit 106" instead of 100. These appear to be clerical errors in the printed patent.
• Note on the "8909772" identifier. Per the strict rule, I have not auto-corrected any number. Searches for "8909772" that returned U.S. 7,535,890 material are for an unrelated patent; those results do not relate to US 8,909,772 and should not be attributed to it.
• Date basis. Your instruction states the current date is April 26, 2026; my retrieval of the patent text is timestamped 2026‑09‑30. The bibliographic data above reflects the retrieved record. I cannot independently verify current USPTO fee/status entries beyond what the retrieved record shows, and the Google Patents legal-status field is expressly flagged there as an assumption rather than a legal conclusion.

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

Let me try additional targeted searches.

Let me try more specific searches targeting litigation databases.

Litigation Search Results for U.S. Patent No. 8,909,772

No litigation is known involving U.S. Patent No. 8,909,772.

Based on my searches of publicly available patent litigation resources, I found no record of any lawsuit — district court, ITC, CAFC, or PTAB proceeding — involving this specific patent. I want to be explicit about the confidence level here, as required.

What I searched

• General litigation queries for "8909772" and "8,909,772"
• Unified Patents litigation/PTAB portal references
• Docket Alarm / PACER-adjacent references
• Case-law and complaint-text searches pairing the patent number with infringement terminology

All results returned either the patent's own Google Patents page (US8909772B2, "System for monitoring hard disk drive") or unrelated documents where a coincidentally similar number appeared (e.g., an unrelated 1989 Bush-era document listing "8909772" as a correspondence code, WO1989009772A1 — a completely different chemical patent, and unrelated docket exhibits listing other patent numbers). None referenced the asserted U.S. Patent No. 8,909,772 in a litigation context.

Caution — I cannot rule it out categorically

Public patent-litigation databases (Unified Patents Portal, Lex Machina, Docket Navigator, RPX Insight, PACER) are not perfectly indexed by lay searches, and small cases, IPR petitions that were never instituted, or suits filed under a different name could exist without surfacing. My searches did not conclusively query every one of those databases directly, so treat this as "no litigation found" rather than a positive certification that none ever occurred.

Contextual facts from the patent record that support the "no litigation" finding

These come directly from the authoritative Google Patents record for US8909772B2:

• Assignee: Originally Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd. and Hon Hai Precision Industry Co., Ltd.; reassigned in 2018 to Hongfujin Precision Electronics (Tianjin) Co., Ltd.
• Legal status: Expired – Fee Related. Per the Legal Events record, the patent lapsed for failure to pay maintenance fees:
  • 2018-07-23 — Maintenance fee reminder mailed
  • 2019-01-14 — Lapse for failure to pay maintenance fees
  • Adjusted expiration date: 2033-06-13 (nominal term, but effectively ended 2018-12-09 per the fee-lapse entry)
• Family: CN103514078A, JP2014010840A, TW201401044A — i.e., a defensive corporate filing by a large hardware manufacturer, not a portfolio that appears to have been asserted.

A patent that expired in 2018–2019 for non-payment of maintenance fees, held by a manufacturing affiliate, with no litigation citations or docket references, is consistent with never having been asserted in litigation.

Summary table

Bottom line: I could not identify any litigation involving U.S. Patent No. 8,909,772. If you need a higher-assurance clearance, I'd recommend a direct, paid query of Docket Navigator, Lex Machina, or the Unified Patents portal, which I was unable to fully access through open web search here.

Note: I was unable to directly load the Unified Patents caselist page you referenced (https://portal.unifiedpatents.com/litigation/caselist) within this session, so that specific source could not be confirmed firsthand.

Proceedings overview

Total AIA trial proceedings on file: 0. The USPTO Open Data Portal returns no IPR, PGR, or CBM proceedings for US 8,909,772 (no active proceedings, no claims invalidated, no claims sustained, no settlements, no institution denials). My independent web searches — for the patent number, the '772 short form, the assignees (Hong Fu Jin Precision Industry (Shenzhen), Hon Hai Precision Industry, Hongfujin Precision Electronics (Tianjin)), and the patent title "System for monitoring hard disk drive" — surfaced no PTAB petition, Final Written Decision, or related Federal Circuit appeal. The only IPR hits with a "890"-style patent number were unrelated patents (U.S. 7,535,890 to Uniloc; U.S. 6,586,890 to Philips), which I am deliberately not conflating with this patent.

Defensive posture: There is no PTAB record at all — neither sword nor shield. A defendant gets no § 315(e)(2) estoppel benefit from anyone, but also cannot point to any adjudicated invalidity. Critically, though, the practical value of this patent is already near zero for a different reason: the patent lapsed for failure to pay maintenance fees, with the lapse effective 2018-12-09 (USPTO legal events: fee-payment reminder 2018-07-23; "Lapse for failure to pay maintenance fees" 2019-01-14; "PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES" 2019-01-14; "Lapsed due to failure to pay maintenance fee — effective date: 20181209"). A defendant's first response to any assertion should therefore be a standing/enforceability point, not an IPR.

Proceedings overview — detail

No proceedings to itemize. For completeness, the record I was able to verify:

Strategic summary

Claim status: no claims of US 8,909,772 have ever been adjudicated by the PTAB. Claims 1–5 (the entire claim set — claims 1 and 5 independent, claims 2–4 dependent) are therefore untested in AIA proceedings. There are no canceled claims to point to and no sustained claims that have been "hardened." What is true is that the patent is expired for fee-lapse purposes effective 2018-12-09, so the enforceable term has effectively run its course. Claim 1 recites a plurality of BMCs obtaining HDD statuses and outputting status information, a control module with an address storage unit storing BMC IP addresses, a request unit, and an analyzing unit, plus a display module. Claims 2–4 add the site-mapping unit and the three-bit SGPIO message-packet analysis that maps an abnormal HDD to a server location in the data center; claim 5 recites that the control module communicates with the BMCs over an SGPIO bus.

Estoppel landscape: § 315(e)(2) estoppel is irrelevant here — no petitioner has ever appeared, so no party (or privy) is estopped. If you are a defendant facing an assertion today, every prior-art ground remains available to you in district court and, technically, in a fresh IPR petition (subject to the patent's expired status and the Board's discretion to institute on an expired patent). The art cited on the face of the patent — US 2003/0072033 (Kanda), US 2004/0068670 and US 7,739,416 (Hitachi disk-array), US 2009/0290249 and US 8,015,434 (Fujitsu management apparatus), US 7,835,305 (Ricoh remote management), and US 2003/0072033 — is all untested before the Board and unburdened by any estoppel.

Pattern signals: No petitioner has ever filed against this patent, let alone serially. No defensive aggregator (Unified Patents, RPX, etc.) appears anywhere in the chain. The patent owner has never pursued a PTAB appeal, because it has never been in a PTAB proceeding. The assignment history shows the patent simply migrated within the Hon Hai/Foxconn corporate family — filed 2012-10-30 by Hong Fu Jin Precision Industry (Shenzhen) and Hon Hai Precision Industry; reassigned 2018-03-05 (effective 2018-01-12) to Hongfujin Precision Electronics (Tianjin) Co., Ltd. — and then went abandoned for fees in December 2018, a few weeks before the end of that calendar-year maintenance window. The absence of any IPR is consistent with a patent that was never commercially asserted; well-asserted patents in the data-center/HDD-monitoring space (see the "Families Citing this family" list at patents.google.com/patent/US8909772/en) did attract post-grant challenges, but this one did not.

Recommended next steps

1. Lead with the fee-lapse, not with an IPR. The maintenance-fee lapse effective 2018-12-09 is the single most useful fact in this file. If you receive a demand letter citing US 8,909,772, confirm the current USPTO Patent Center status and, if the lapse is unreversed (there is no reinstatement petition on the record I reviewed), respond that the patent is expired and unenforceable for the post-lapse period. Document the legal events: https://patents.google.com/patent/US8909772/en.
2. Do not fabricate a PTAB record. There is no FWD to link to and no proceeding number to cite. Any brief asserting "claims 1–5 were canceled in IPR" would be wrong; the claims were never challenged.
3. If an assertion is live and you must build a validity record, the cleanest route is a district-court § 102/§ 103 attack on claim 1 using the untested art of record (Kanda '033; Hitachi '670 / '416; Fujitsu '249 / '434; Ricoh '305) plus the SGPIO protocol specification and contemporary BMC/HDD-backplane documentation — the specification's own admission that reading SGPIO message-packet bits and mapping BMC IP addresses to server locations was conventional is a strong § 103 hook for claims 2–4.
4. If you nonetheless file an IPR (e.g., for a stay or to lock in a validity finding), expect the Board to weigh the patent's expired status and the length of time the claims were in force; the Director's discretionary-denial framework and Fintiv/General Plastic considerations may cut against institution where parallel litigation exists. Statutory deadlines still apply (institution decision within 6 months of the preliminary-response deadline; FWD within 1 year of institution, 35 U.S.C. § 316(a)(11)) — but note that for an expired patent, the Board's practice has generally favored resolving validity anyway.
5. Verify my negative finding. I searched the patent number, short form, title, and assignee names and found nothing, but PTAB E2E (https://ptacts.uspto.gov/ptacts/) and CourtListener (https://www.courtlistener.com/) should be checked directly against the patent number and its family (CN 103514078A; JP 2014010840A; TW 201401044A) before you rely on the absence of proceedings as a litigation position. Absence of PTAB activity is itself a signal here: this patent was never worth challenging.

I'll research the assignment record for US 8,909,772, starting with targeted searches on the reel/frame numbers from the legal events and the assignment databases.

Let me dig into the specific assignment records and the prosecution correspondent of record.

Assignment & Ownership Analysis — U.S. Patent No. 8,909,772

Data note / confidence statement up front. The USPTO Assignment Center (https://assignmentcenter.uspto.gov/) and the legacy Assignment Search (https://assignment.uspto.gov/patent/index.html) could not be loaded directly in this session — my searches surfaced the underlying records only as reported in the Google Patents "Legal Events" table for US8909772B2, which reproduces the USPTO reel/frame data. I therefore have reel/frame numbers and execution/recording dates but NOT the correspondent of record for either assignment. I will not invent correspondent names. Anything marked unclear below is a genuine gap, not a hedge.

Inventors

Notes on unusual patterns:

• Single-inventor patent. That is common for Foxconn's incremental server/storage filings and is not, by itself, a signal.
• Yang is a prolific Foxconn inventor — a third-party compilation (Patent Leaderboard) credits him with ~36 issued U.S. patents, the large majority associated with Foxconn, with later clusters attributed to Tencent, Scienbizip Consulting (Shenzhen), Hongfujin Precision Electronics (Tianjin), and Miics & Partners (Shenzhen). A Foxconn→Tencent shift would indicate inventor mobility, but I could not determine the timing of that transition, so I cannot say whether he left Foxconn within 12 months of this 2012 filing. Mark: unclear — not a finding.
• The inventor did not leave before filing. He assigned to his employer on 2012-10-15, and the application was filed 2012-10-30. There is no "inventor departed → fire-sale" pattern here.

Original assignee

Entities named on the issued patent (per the assignment recorded at reel 029209/0978):

• Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd. — China
• Hon Hai Precision Industry Co., Ltd. — Taiwan (Taipei Hsien, TW; the ultimate Foxconn parent, TWSE: 2317)

Shipped a product embodying the claims? — Likely yes, but I could not verify a specific commercial product. The patent's own specification describes the invention as a monitoring/management feature for servers and HDD backplanes (BMC → SGPIO bus → HDD LED state), i.e., firmware/board-level functionality in Hon Hai's own server and storage hardware. Hon Hai is the world's largest electronics manufacturing services (EMS) provider and a major server/storage ODM. So the practical reading is that this is a captive manufacturing-portfolio patent, not a standalone licensing asset.

Primary line of business: EMS / contract design and manufacturing (Foxconn). Hon Hai's own filings list numerous "Hongfujin"-named entities (Wuhan, Yantai, etc.) as subsidiaries/affiliates — corroborating that the "Hong Fu Jin / Hongfujin" name family is the Foxconn group's mainland-China manufacturing arm (source: an Hon Hai related-party disclosure retrieved via stockanalysis.com, TPE:2317 filings).

Current status: Operating / going concern. Neither original assignee is dissolved or in bankruptcy — relevant because it rules out the bankruptcy fire-sale signal (§6 below).

Assignment timeline

Two recorded assignments exist. Both are transcribed from the Google Patents Legal Events table.

• 2012-10-15 (executed) / recorded 2012-10-30 — Reel 029209/0978

  • Conveyance: Assignment (ASSIGNMENT OF ASSIGNORS INTEREST; ASSIGNOR: YANG, MENG-LIANG)
  • Assignor: YANG, MENG-LIANG
  • Assignee: (1) HONG FU JIN PRECISION INDUSTRY (SHENZHEN) CO., LTD.; (2) HON HAI PRECISION INDUSTRY CO., LTD. (Taiwan)
  • Correspondent: Not obtainable in this session. The Assignment Center page was not directly loadable; the Google Patents legal-events table does not surface the correspondent. Verify directly at https://assignmentcenter.uspto.gov/ by reel 029209 frame 0978.
  • Context: Inventor-to-employer assignment — standard "assignment of rights" executed 15 days before the 2012-10-30 U.S. filing date. Note the U.S. filing claims priority to CN 201210217632.4 (2012-06-28); this record is the pre-filing title capture, not a post-issuance transfer.

• 2018-01-12 (executed) / recorded 2018-03-05 — Reel 045501/0324

  • Conveyance: Assignment (ASSIGNMENT OF ASSIGNORS INTEREST; ASSIGNORS: HONG FU JIN PRECISION INDUSTRY (SHENZHEN) CO., LTD.; HON HAI PRECISION INDUSTRY CO., LTD.)
  • Assignors: Hong Fu Jin Precision Industry (Shenzhen) Co., Ltd. and Hon Hai Precision Industry Co., Ltd.
  • Assignee: Hongfujin Precision Electronics (Tianjin) Co., Ltd. (No. 80 HaiYun Street, Tianjin Economic & Technological Development Area, Tianjin, CN)
  • Correspondent: Not obtainable in this session. Same limitation as above. Verify by reel 045501 frame 0324.
  • Context: Internal corporate reorganization / intra-group IP consolidation. Both assignors and the assignee are Foxconn-group entities; the assignee is a mainland-China manufacturing affiliate of the same parent. This is consistent with Foxconn re-papering its China-origin patent titles into a single Tianjin holding/manufacturing entity — not a transfer to a third party or to an asserter.

Post-Assignment Event (for completeness — not an assignment):

• 2018-07-23 — maintenance-fee reminder mailed.
• 2019-01-14 — lapse for failure to pay maintenance fees; 2019-02-05 "FP – Lapsed," effective 2018-12-09.
• Nominal/adjusted expiration listed as 2033-06-13; the patent is marked Expired – Fee Related. Effectively, the new owner (Tianjin entity) let the patent die roughly 11 months after taking title.

Timeline diagram

timeline
    title Ownership of US 8909772
    2012 : Inventor assigns rights to Hon Hai and Shenzhen unit
         : US application filed 30 Oct
    2014 : Patent issued as US 8909772
    2018 : Title moved to Foxconn Tianjin affiliate
    2019 : Patent lapses for unpaid maintenance fee

NPE / troll-pattern signals

Verdict

Defensive / non-asserting — with an explicit caveat about the label's definition.

Justification: The ownership chain is a two-step, all-in-family record. Step 1 is the inventor's routine pre-filing assignment to his employers (reel 029209/0978, executed 2012-10-15). Step 2 is an intra-group consolidation of both Foxconn co-owners' interests into Hongfujin Precision Electronics (Tianjin) Co., Ltd. (reel 045501/0324, executed 2018-01-12, recorded 2018-03-05). There are no shell-entity transfers, no NPE assignees, no cascading LLC hops, and no litigation. The patent was then simply allowed to lapse for unpaid maintenance fees (2019-01-14, effective 2018-12-09), which is the opposite of an assertion posture.

Caveat on the verdict label: the task defines "Defensive / non-asserting" as a chain that terminates at a defensive aggregator. That specific fact is not true here — the chain terminates inside the Foxconn corporate family and dies by fee lapse. None of the other labels fit either (not NPE; there is no "operating-company assertion" because no suit was ever filed by an operating assignee). I am therefore using Defensive / non-asserting in its substantive sense — non-asserted, dormant, and ultimately abandoned — and flagging that the formal definition is not satisfied.

Two residual uncertainties, stated plainly:

1. Correspondent of record for both reels is unknown to me. If you need signal #3 resolved, that is a two-minute lookup at https://assignmentcenter.uspto.gov/ searching patent 8,909,772 (records 029209/0978 and 045501/0324).
2. Whether a specific Foxconn product embodied the claims is inferred from the patent's subject matter and Hon Hai's business, not verified against a product teardown.

Verification link: https://assignmentcenter.uspto.gov/ (search "8909772") — or the mirrored legacy UI at https://assignment.uspto.gov/patent/index.html.

I'll verify each cited reference against live sources before analyzing. Let me run targeted searches.

Prior-Art Analysis — U.S. Patent No. 8,909,772 B2 ("System for monitoring hard disk drive")

A. Scope, method, and a required caveat

Target confirmed as exactly US 8,909,772 B2 (App. 13/663,581; "System for monitoring hard disk drive"; priority 2012‑06‑28 via CN 201210217632.4; US filed 2012‑10‑30; granted 2014‑12‑09). Per the strict rule, I did not fold in look‑alike numbers. Searches for the bare string "8909772" also return unrelated matter — e.g., U.S. 7,535,890 (an unrelated Uniloc patent) and WO 1989/009772 A1 (an unrelated chemistry filing). Those are excluded; they are not citations to this patent and must not be attributed to it.

Two limitations on this analysis you should know before relying on it:

1. Tooling. My available tool is general web search of the open record (primarily the Google Patents page for US8909772B2, which reproduces the front-page citation lists, plus scanned front pages on patentimages). I did not run an authenticated USPTO PatentCenter / USPTO Full‑Text (PatFT) or Examiner's "PTOL‑892" query. The citation set below is taken from the authoritative Google Patents record supplied in the full text of the patent.
2. Full‑text depth. I was able to verify bibliographic data and subject matter for most references (Kanda/Ricoh, the Hitachi disk‑array power family, Hitachi US 7,739,416, Ricoh US 7,835,305). I hit a session step limit before pulling the complete specifications of the two Fujitsu references (US 2009/0290249 A1 / US 8,015,434 B2). For those I rely on title/assignee/date plus the patent's own citation context, and I flag the gap rather than assert element‑level mapping I could not verify.

Governing law / timing note. The application's effective filing (2012‑10‑30) and priority (2012‑06‑28) both pre‑date the AIA first‑inventor‑to‑file change (2013‑03‑16). This is therefore a pre‑AIA §102 case. Every cited reference published or issued more than one year before the 2012‑10‑30 US filing date, so each is squarely available as pre‑AIA §102(b) art (and, being "by another," also §102(e) art as of its own earlier effective filing date). No reference relies on the narrower §102(a)/(g) windows.

B. The citation set — an important structural point

The patent record contains two citation lists, and they are easy to confuse:

• "Citations (5)" — the five references actually cited by the Examiner (marked *):
  1. US 2003/0072033 A1
  2. US 2004/0068670 A1
  3. US 2009/0290249 A1
  4. US 7,739,416 B2
  5. US 7,835,305 B2
• "Patent Citations (12)" — the same five, expanded to include family members (grants and continuations/divisionals) that Google Patents auto‑associates. The seven extra entries are all grants/continuations of the five above; they are not seven additional independent third‑party references.

So the substantive prior‑art universe is five references (in seven/nine family publications). My table below lists all twelve entries but groups them by family.

C. Master table of cited references

D. Reference‑by‑reference §102 analysis

Recall the only independent claim is claim 1, requiring: (a) plurality of BMCs each connected to HDDs and outputting status information; (b) a control module with an address storage unit storing IP addresses mapped to the BMCs, a request unit receiving a request for the status information, and an analyzing unit that parses the outputted status information; (c) a display module showing each HDD's status; in the context of HDDs in servers of a data center. Claims 2–5 depend from 1.

1 / 1a. Kanda — US 2003/0072033 A1 (pub. 2003‑04‑17) and US 7,212,307 B2 (2007‑05‑01)

Verified description. The Kanda disclosure (a Ricoh digital‑copier image‑storage system using multiple HDDs) determines whether image data's intended use is short‑term (electronic sorting) or long‑term preservation, and selects a storage mode accordingly — splitting data across several HDDs or mirroring it. Relevant to our patent, Kanda expressly includes, as stated objectives: "to identify or pinpoint a HDD that has an abnormality" and "to provide a clear‑cut notice to its user," and it avoids using a failed HDD's data when reading. Source: https://patents.google.com/patent/US20030072033 and the US 7,212,307 front page (https://patentimages.storage.googleapis.com/07/28/f6/2da2af0110cb9e/US7212307.pdf).

§102 potential.

• Claim 1 — no anticipation. Kanda has multiple HDDs and a notion of detecting/reporting an abnormal HDD, but there is no baseboard management controller, no IP‑address‑to‑controller storage, and no request unit polling controllers. It engages only the "status of HDDs / display of abnormality" concept.
• Claim 4 — closest, but not anticipatory. Claim 4 requires, in a system already having claims 1–3's structure, that "each HDD comprises a light‑emitting diode (LED), the LED of the abnormal HDD is off." Kanda's "clear‑cut notice to its user" of an abnormal HDD is conceptually adjacent, but a claim‑4 anticipation theory fails because (i) claim 4 depends from claim 3's three‑bit SGPIO packet, absent from Kanda, and (ii) I found no per‑HDD LED‑off‑on‑fault disclosure in Kanda.
• Realistic role: §102/§103 background art on "identifying an abnormal HDD among many and notifying the user." It is not a full‑element disclosure of any claim.

2 / 2a–2c. Hitachi disk‑array power family — US 2004/0068670 A1 (2004‑04‑08), US 2007/0016811 A1, US 7,284,140 B2, US 2007/0255968 A1

Verified description. This family (priority 2002‑10‑03, Hitachi/Ltd., Suzuki et al.) concerns power distribution inside a rack‑mount disk array: dual AC inputs, AC/DC supply groups, summing group outputs to loads, battery/UPS destaging, inrush current on HDD hot‑plug, and optionally switching power per HDD. It is a power‑supply reliability disclosure, not a status‑monitoring one. Source: https://www.patents-review.com/a/20070255968-disk-array-device-method-supplying-power-disk-array-device.html and EP 1 411 523 A2.

§102 potential.

• No claim anticipated. The reference discloses neither BMCs, nor status packets, nor IP‑address storage, nor a display of individual HDD status. It mentions "operation states of the installed HDDs" only incidentally, in the context of AC‑load balancing.
• Realistic role: generic environmental/analogous‑art background (HDD arrays, HDD hot‑plug detection). It cannot supply any missing claim element; at most it is §102(b) context, not an anticipation reference.

3 / 3a. Hitachi — US 7,739,416 B2 (2010‑06‑15) and US 2013/0179595 A1

Verified description. A disk array apparatus focused on the SAS (Serial Attached SCSI) interface: controller / SAS expander / storage devices connected by physical links, rate matching, and efficient data transfer when links run at different rates (e.g., 1.5 vs 3.0 Gbps). Inventors: Honma, Chikusa, Yamaura, Tachibana, Maki. Sources: https://patents.google.com/patent/US7739416 and https://patents.google.com/patent/US20130179595.

§102 potential.

• No claim anticipated. This is a data‑transfer/efficiency reference. It has no BMC, no status‑packet analysis, no IP‑address‑to‑controller map, no display. (Note the separate Hitachi patent US 7,461,203 B2, "Disk array apparatus and method for controlling the same", is a different family — do not conflate; the cited US 7,739,416 is the SAS‑rate‑matching case.)
• Realistic role: background on the storage‑array hardware context (SAS/expanders). Not an anticipation reference for any claim.

4 / 4a. Ricoh — US 7,835,305 B2 (2010‑11‑16) and US 2011/0026080 A1

Verified description. A remote management system for networked electronic devices (office equipment/copiers). A communication adaptor specifies a network segment, searches that segment for devices, obtains remote‑management information, verifies whether the information is in a predetermined format, reports devices with invalid information, and sends change requests. Continuation US 2011/0026080 A1 (imaged to Kazuki Onishi) is in the same family (see also US 8,799,420 B2 from App. 12/905,510). Sources: https://patents.google.com/patent/US7835305 and https://patents.google.com/patent/US20110026080.

§102 potential.

• No claim anticipated, but this is the most structurally relevant "network‑centric" reference. It discloses, in general terms, the remote‑request → device‑interrogation → parse‑returned‑information architecture that echoes claim 1's request unit and analyzing unit, and it is IP‑network based.
• Nevertheless, anticipation of claim 1 fails: the managed devices are office machines, not HDD‑coupled BMCs; there is no address storage unit mapping IP addresses to BMCs; and there is no display module of per‑HDD status. It also does not teach the data‑center/server framing.
• Realistic role: the strongest reference for an obviousness combination directed at claim 1's request‑and‑analyze‑over‑a‑network feature, and possibly at the "obtain information / verify format / report device" concept. Standalone §102 anticipation: no.

5 / 5a. Fujitsu — US 2009/0290249 A1 (2009‑11‑26) and US 8,015,434 B2 (2011‑09‑06)

Description (title/assignee/date verified; full text not retrieved). A "Management apparatus, storage system, and storage apparatus management method" by Fujitsu Limited, priority 2008‑05‑23. By title and field this is the cited reference most topically aimed at centralized management/monitoring of storage apparatuses, i.e., the general area of claim 1's "control module that obtains status of storage devices."

§102 potential — stated with appropriate caution.

• On the record I can verify, I cannot assert that this reference discloses (i) baseboard management controllers, (ii) an address storage unit of IP addresses mapped to BMCs, or (iii) the three‑bit SGPIO message‑packet structure of claim 3, or (iv) the site‑mapping/location feature of claim 2. Anticipation requires all elements in a single reference, arranged as in the claim.
• Therefore no claim of US 8,909,772 is clearly anticipated by this reference on the verified record. Its realistic role is §102(b)/§102(e) background and §103 art on "management apparatus that gathers and reports storage‑apparatus status."
• Flagged gap: if you need an element‑by‑element chart against claims 1–3, the full specification of US 8,015,434 / US 2009/0290249 must be pulled and read; my searches did not reach that text within the session limits.

E. Synthesis — which cited reference is "most relevant," and why none anticipates

Ranked by relevance to the claims of US 8,909,772:

1. Fujitsu US 2009/0290249 A1 / US 8,015,434 B2 — most topically on‑point (centralized storage‑management/status). Closest to claim 1's "control module analyzing storage status." Verify full text before making any §102/§103 assertion.
2. Ricoh US 7,835,305 B2 / US 2011/0026080 A1 — closest on the network request/obtain/analyze mechanics of claim 1.
3. Kanda US 2003/0072033 A1 / US 7,212,307 B2 — closest on identifying and notifying the user of an abnormal HDD among many (touches the claim‑4 concept).
4. Hitachi US 7,739,416 B2 — background only (SAS disk‑array hardware).
5. Hitachi US 2004/0068670 A1 family — background only (disk‑array power reliability).

The pivotal conclusion: No cited reference anticipates any claim of US 8,909,772 under §102. The single independent claim (claim 1) is distinguished by the combination of a plurality of baseboard management controllers that locally harvest HDD status and output status information, plus a control module whose address storage unit maps IP addresses to those BMCs with a request unit and analyzing unit, plus a display module — all in a data‑center/server setting. None of the five cited references (in their family publications) discloses a BMC, and none discloses the IP‑address‑to‑BMC mapping with a request/analyze control module. Each reference engages at most a single strand of the claim (storage management; remote network retrieval; abnormal‑HDD notification). Accordingly:

• As §102 art, the examiner's citations function as background, not anticipation — consistent with a granted claim set that survived them.
• Their realistic value, if this patent were litigated, would be as §103 obviousness references, most plausibly in combinations (e.g., Fujitsu or Ricoh for the network‑based status retrieval/analysis, plus a BMC‑bearing server‑management teaching), and only against claim 1 — not as clean single‑reference anticipations.

F. Points of uncertainty and items to close out

1. Citation vs. family count. The "12" figure is 5 Examiner‑cited references expanded with family members, not 12 independent references. Treat the family groupings in Section C as controlling.
2. Full‑text verification outstanding. Fujitsu US 2009/0290249 A1 / US 8,015,434 B2 full text was not retrieved; my §102 statement for reference 5 is deliberately limited and flagged. The same is true, to a lesser degree, for the exact figure/specimen‑level disclosures of the Hitachi and Ricoh references (front‑page‑level subject matter was verified).
3. No intrinsic corroboration of anticipation. Because the patent issued over this exact citation set, the presumption is that the Examiner did not view any of them as anticipating; my element‑level review is consistent with that.
4. Date basis. Per your instruction the current date is April 26, 2026; my live retrieval of the patent record is timestamped 2026‑09‑30 and reflects the record as retrieved. The Google Patents legal‑status field is expressly an assumption, not a legal conclusion, and I could not independently confirm current USPTO fee/status entries.
5. Identifier integrity. Per the strict rule, no patent numbers or technical identifiers have been "corrected." Where an identifier in the patent's own text looked like a typographical slip (e.g., claim 5's "SGPIO bus" versus the specification's network‑302 communication; the "second BMC 20" and "request unit 106" typos noted in the earlier summary), I have preserved the literal text and flagged the discrepancy rather than silently fixing it. That claim‑5/SGPIO discrepancy is worth noting in any §112 or claim‑construction assessment, but it does not change the §102 conclusion above.

I'll research the prior-art references cited on the patent's page before building the § 103 analysis.

Let me pull details on the closely-related monitoring references listed in the "Similar Documents" and "Families Citing" sections of the page.

Obviousness Analysis — U.S. Patent No. 8,909,772 B2

"System for monitoring hard disk drive" (Meng-Liang Yang; priority 2012‑06‑28; issued 2014‑12‑09)

This analysis builds on the previously generated summary and litigation sections. It does not repeat the claim text or bibliographic data; it assumes the reader has the claim‑1 element breakdown and dependent‑claim summaries from those sections.

1. Legal framework and date scoping (stated up front because it changes which "prior art" on the page counts)

Governing statute. The application was filed 2012‑10‑30, with earliest priority 2012‑06‑28 — both before the AIA first‑inventor‑to‑file provisions took effect (applications filed on/after 2013‑03‑16). The claims are therefore governed by pre‑AIA 35 U.S.C. § 103(a) and pre‑AIA § 102. The KSR "expansive and flexible" obviousness standard (KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007)) applies regardless.

Which items on the page are actually prior art. This is important, because most of the items in the "Families Citing this family" and "Similar Documents" sections post‑date the 2012‑06‑28 priority date and cannot be § 103 prior art, notwithstanding their appearance on the patent's own page:

Consequence: any honest § 103 case against the '772 claims must be built on the five examiner‑cited families (all pre‑2003–2010) and, for the location element, possibly US 2012/0005344 A1. The on‑point‑looking 2013+ monitoring patents on the page cannot be used.

2. The reference set and what each actually discloses

I retrieved substance for the five examiner citations. What follows is limited to content I could verify in the retrieved records; where I am inferring an element mapping rather than reading it directly, I say so.

• A. US 2009/0290249 A1 — Fujitsu, "Management apparatus, storage system, and storage apparatus management method."
  A management apparatus (CM) monitors storage apparatuses (magnetic disk drives / DEs—Drive Enclosures). It determines whether the AL_PA (an address/identification) assigned to a Drive Enclosure can be acquired, and includes an acquisition determination section and a failure determination section that distinguish a drive failure from a power failure. It maintains a "configuration table … a list for storing information concerning the modules constituting the storage system … a correspondence between the name of a module and status of the module." → Teaches an automatic controller that (i) addresses/identifies discrete storage modules, (ii) obtains and stores per‑module status in a table, and (iii) analyzes status to detect a failed unit.

• B. US 7,835,305 B2 — Ricoh, "Remote management system."
  A communication adaptor / center system includes a "network segment specification unit for specifying a network segment to be managed," a "device search unit … to search the specified network segment to find the electronic device," a "remote management information obtaining unit … to obtain the remote management information from the found electronic device," a format verification unit, and an "invalid device information sending/reporting unit" that reports electronic‑device information of a device whose information is invalid, plus a change‑request unit. → Teaches a centralized, network‑addressed client control module that discovers managed devices by network segment/IP, polls them for status/maintenance information, validates it, and reports/identifies the device to a center. This is the closest mapping to claim 1's address storage unit + request unit + display/reporting.

• C. US 7,739,416 B2 — Hitachi, "Disk array apparatus."
  A controller and storage devices (HDDs) connected through a SAS/SATA serial bus via an expander, with the controller exchanging device information over serial physical links. → Teaches a controller harvesting HDD information over a point‑to‑point serial management transport, the functional analogue of the asserted SGPIO bus.

• D. US 2004/0068670 A1 — Hitachi, "Disk array device and method of supplying power to disk array device."
  A disk array with multiple HDDs, a controller, and power supplies; the controller detects power/HDD failures and the drives can signal the controller — e.g., "the other normal HDD 210 that has not failed informs the disk control section 700 that it is operating normally." → Teaches per‑HDD status signaling to a controller among a population of HDDs, including normal/abnormal discrimination and selective handling of a failed drive.

• E. US 2003/0072033 A1 / US 7,212,307 B2 — Kanda (Ricoh), "Image data storage system."
  A system with a plurality of HDDs and a CPU that detects a data abnormality in a HDD; a stated object is to "identify or pinpoint a HDD that has an abnormality in an image data storage system utilizing a plurality of HDDs, thereby providing a clear‑cut notice to its user," and to avoid using data from, and to enable replacement of, a malfunctioning HDD. → The best mapping for the "detect the HDD being abnormal … and notify the user" aspects of claims 2 and 4.

3. The person of ordinary skill and the motivation framework

POSITA (my construction): a computer/systems engineer with ~2–4 years' experience in server/storage hardware and out‑of‑band management, familiar with (i) server management controllers (BMCs/IMPI‑class devices) and (ii) HDD enclosure management buses (SAS/SGPIO‑style sideband signaling used for drive activity/fault/LED control).

Common motivation threads running through all five references — this is the heart of the § 103 case:

1. Same field of endeavor. Every reference is in storage‑system or managed‑device status monitoring.
2. Same problem. Large populations of HDDs must be monitored without manual inspection; failures must be detected automatically and localized to the specific unit.
3. Same design tendency. Each reference independently teaches automatic, networked or bus‑mediated collection of per‑device status and reporting/pinpointing of the bad device — exactly the asserted advance (automating what the '772 Background admits was a manual visual LED check).
4. KSR rationales available: (a) combination of known elements with predictable results; (b) simple substitution of a known networked‑management front end (Ricoh) for a manual inspection; (c) "known technique" / "obvious to try" for the data‑center‑location lookup (claim 2); (d) design incentive / market demand — hundreds‑to‑thousands‑of‑drive data centers, as the '772 Background itself concedes.

4. Claim 1 — combinations that render it obvious

4.1 Primary combination: Fujitsu '249 + Ricoh '305 (+ Hitachi '416)

Motivation. Fujitsu '249 supplies the analytical core — a management apparatus that harvests per‑storage‑module status into a table and decides whether a module is failed or merely unpowered. Ricoh '305 supplies the network front end — discovery of managed devices by network segment, retrieval and validation of their status information, and reporting of the specific invalid device to a central point. Both address the identical problem of supervising many storage devices without manual checking, and combining a status‑table analyzer (Fujitsu) with a network‑address‑based polling/reporting layer (Ricoh) to yield a central console that displays each drive's status is the predictable, mechanical union of two known elements with the expected benefit of eliminating manual inspection. Hitachi '416 is added only to supply the serial‑bus controller‑to‑HDD status link (relevant mainly to claim 5).

4.2 Alternative combination emphasizing abnormality detection: Kanda '307 + Ricoh '305 + Hitachi '416

Kanda '307 explicitly detects an abnormal HDD among a plurality of HDDs and pinpoints/notifies the user of the specific abnormal drive; Ricoh '305 supplies the network‑based control module that gathers and reports device status; Hitachi '416 supplies the serial controller‑to‑HDD management link. A POSITA seeking to scale Kanda's local copier‑HDD monitoring to a networked data center would look to Ricoh's remote‑management architecture (same Ricoh assignee; overlapping field), producing claim 1 with the predictable benefit of centralized, remote HDD‑health display.

4.3 Where claim 1 is weakest against these references (candid assessment)

• "BMC" is not disclosed by any of the five references. Fujitsu '249 and Hitachi '416 use storage controllers/management blades; Ricoh '305 uses a "communication adaptor" and "center system." None uses a baseboard management controller in a server. BMCs were unquestionably well known in server platforms by 2012 (IPMI), and the references disclose the functional equivalent (a management controller that reads HDD sideband status and reports over a network), so a POSITA‑based argument that "BMC = the known server management controller" is available under KSR's "known technique" prong — but that limitation is the soft spot, and a challenger would be well advised to add an explicit server‑BMC/IPMI reference.
• "IP address storage unit" is only indirectly met (Ricoh's segment specification/discovery; Fujitsu's AL_PA addressing). A challenger should be prepared to argue equivalently or pair with a network‑management reference.

5. Dependent claims

Claim 2 — site‑mapping unit; resolve server location from the BMC's IP and display it

• Core (detect abnormal HDD → report the specific device) is met by Kanda '307 (pinpoint and give "clear‑cut notice" of the abnormal HDD) in combination with Ricoh '305 (reporting electronic‑device information of the invalid device) and Fujitsu '249 (failure determination from the status table).
• The "location of each server in the data center" mapped to IP is the one element not clearly present in the five examiner citations. For this, the strongest candidate on the page is US 2012/0005344 A1, "Data Center Inventory Management Using Smart Racks" (pub. 2012‑01‑05), which by its title is directed to inventory/location of data‑center equipment — but I did not retrieve its substance and cannot represent its specific teachings. A challenger would need to confirm it (or an equivalent DCIM/asset‑management reference) teaches mapping a device/address to a physical rack/server location.
• Motivation: once the system detects that a drive failed (Fujitsu '249 / Kanda '307) and identifies which device over the network (Ricoh '305), attaching the known physical location of that managed device is a predictable expedient that merely automates the manual "find the server with the dark LED" step the '772 Background identifies. This is a textbook "known technique applied to a known process" / "obvious to try" limitation.

Claim 3 — status information = three‑bit SGPIO message packets (bit1 operating, bit2 connection, bit3 HDD status); analyze bit3

• Analysis‑of‑a‑status‑field: Fujitsu '249's configuration table (module name ↔ status) and its acquisition/failure determination logic teach reading a stored per‑module status field and deciding normal vs. abnormal, which maps onto "read bit 3 to determine whether the HDD is working normally."
• The three‑bit packet structure itself: the '772 specification calls this "the SGPIO protocol" and describes the bit meanings as an existing protocol convention ("Each message packet of the SGPIO protocol includes three bits"), rather than as the inventor's contribution. If the three‑bit format is the industry‑standard SGPIO/SFF‑8485 sideband format (as the specification's own language implies), then claim 3 recites the known protocol format plus the routine step of reading the status bit — obvious under the "known technique" prong. Caveat: I could not verify the SFF‑8485 specification's exact packet content from the material available; the claim's characterization ("three bits," with those specific meanings) is idiosyncratic, so this position should be confirmed against the actual SGPIO standard before being relied upon.
• Motivation: an artisan implementing HDD sideband monitoring on an SGPIO‑equipped backplane necessarily uses SGPIO's defined bit field; no inventive faculty is required to read the status bit and act on it (Hitachi '416 / '670 show controllers routinely consuming per‑drive serial status).

Claim 4 — per‑HDD LED, off when the HDD is abnormal

• Kanda '307 expressly addresses detecting a HDD abnormality and giving the user notice (and replacing the malfunctioning drive); Hitachi '670 shows drives signaling normal/abnormal operation to the controller. The '772 specification itself concedes the conventional HDD LED that emits light when normal and is dark when abnormal. Rendering the monitored abnormality as the same (known) LED state is a predictable, conventional design choice and, at most, a mere automation/visualization of an admitted prior‑art indicator.
• Strongest reference: Kanda '307 (abnormality detection + notification) in view of the admitted conventional per‑drive LED.

Claim 5 — control module communicates with the BMCs "through a serial general purpose input output (SGPIO) bus"

• Internal‑consistency flag (carried forward from the summary section): this claim as issued conflicts with the specification, which states the BMCs read HDD status over SGPIO bus 300 while the control module reaches the BMCs through network 302 by IP address. Read literally (control module ↔ BMC over SGPIO), the claim is hard to square with the described embodiment; read instead as "the status‑gathering layer communicates with the drives over SGPIO," it maps cleanly onto the references.
• If read as BMC‑to‑HDD over SGPIO: Hitachi '416 (controller↔HDD over a serial bus: SAS/SATA) teaches the underlying serial management transport, and substituting the equally‑known SGPIO sideband bus for SAS is a simple substitution of one known serial HDD‑management bus for another, with predictable results. This is a strong § 103 position.
• If read literally as control‑module‑to‑BMC over SGPIO: no reference supports that (unusual) architecture, and the § 103 case is correspondingly weak as to that literal reading — but such a reading arguably renders the claim inconsistent with its own specification, which a challenger would raise.

6. Summary: element → reference matrix

7. Confidence, gaps, and what a challenger still needs

High confidence (grounded in retrieved text): Fujitsu '249 teaches a management apparatus that stores per‑module status in a configuration table and analyzes it to determine a failure/abnormality; Ricoh '305 teaches network‑segment‑based discovery, polling, validation, and reporting of an identified device; Kanda '307/'033 teaches detecting an abnormal HDD among many and pinpointing/notifying the user; Hitachi '416 shows a controller↔HDD serial management bus; Hitachi '670 shows per‑drive normal/abnormal signaling to a controller. These support the core § 103 combinations for claims 1–4 (with claim 5's caveat).

Lower confidence / open gaps:

1. "BMC" per se is not disclosed by any examiner‑cited reference. Either an equivalent‑means argument or an added server‑BMC/IPMI reference is needed.
2. Claim 2's data‑center location mapping is not clearly met by the five citations; the candidate on the page (US 2012/0005344 A1) is unverified.
3. Claim 3's exact three‑bit SGPIO packet structure should be checked against the actual SGPIO/SFF‑8485 standard; I could not verify the standard's content.
4. Claim 5 is internally inconsistent with the specification; its § 103 posture depends on which reading controls.
5. None of the "Families Citing"/"Similar Documents" post‑2012 items (US 2013/0159561 A1; US 9,713,215 B2; CN 104166613 A; TWI576694B; etc.) may be used as § 103 art against the 2012‑06‑28 priority date; US 2013/0159561 A1 could only qualify as pre‑AIA § 102(e) art if its filing predates the invention date, which I could not confirm.

Bottom line. On the reference set actually printed on this patent's page, claim 1 (and claims 2–4) would have been obvious under pre‑AIA § 103(a) to a POSITA by combining Fujitsu '249 + Ricoh '305 (with Hitachi '416 for the serial link and Kanda '307 for abnormality pinpointing), because each element is disclosed or its functional equivalent is disclosed, all references share the same field and problem, and the combination yields the predictable benefit of replacing manual LED inspection with automated, network‑based status display — the very advantage the '772 Background concedes. The principal vulnerabilities are the un‑cited "BMC" hardware limitation and claim 2's physical‑location mapping, which require either an equivalent‑means rationale or one additional reference.