US 5926833

I'll search for any litigation or docket activity involving this specific patent, then provide the summary.

Let me check for any litigation or docket records specifically naming this patent.

US Patent 5,926,833 — Analyst Summary

Searches performed: Google Patents full text (authoritative copy supplied), plus targeted web searches for USPTO records, PTAB/CAFC dockets, and third-party citation databases. No litigation, PTAB proceeding, or CAFC appeal naming this patent was found in the open sources searched (see "Docket check" below).

---

1. Bibliographic data

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

---

2. Abstract (as issued)

"A method and system are provided which allow heterogeneous computing systems to have direct access to the same data storage areas on a shared data storage subsystem such that the method and system are transparent to the heterogeneous computing systems. The method and system achieve the foregoing via the following steps. A data storage subsystem controller queries all computing systems having direct access to the same data storage areas of a shared data storage subsystem as to the operating systems utilized by such computing systems. In response to answers received in response to the queries, the data storage subsystem controller creates and stores meta-data which associates each computing system having direct access with whatever operating system is running on each computing system having direct access. In response to a request from a computing system having direct access for access to a data storage area within the shared data storage subsystem, the data storage subsystem controller retrieves the stored meta-data associated with the computing system which is requesting access to a data storage area within the shared data storage subsystem. The data storage subsystem controller utilizes the retrieved meta-data to correctly interpret and respond to the request for access to a data storage area in a manner consonant with the operating system of the computing system which is requesting access to a data storage area within said shared data storage subsystem."

---

3. Plain-language overview of the independent claims

Claim 1 — Method (the core claim).
A storage-subsystem controller does four things:

1. Queries every host that has direct access to the shared storage areas and asks what operating system each one runs.
2. Creates and stores meta-data (on the storage subsystem itself) mapping each host to its OS.
3. When a host requests access to a storage area, retrieves that host's meta-data. Claim 1 specifically narrows this step to: identify which host is requesting, determine the linear block addresses (LBAs) where that host's meta-data lives, and then read the meta-data from those determined LBAs.
4. Uses the retrieved meta-data to interpret and answer the request in the OS-appropriate manner, so heterogeneous hosts transparently reach the same physical data areas.

Claim 6 — Apparatus. The same four-stage functionality expressed as means-plus-function elements, including the identify → determine-LBA → retrieve sub-elements.

Claim 11 — Program product. Same functionality as instruction means, plus signal bearing means (carrier medium).

Claim 18 — Method, narrowed to the offsetting mechanism. Query → create/store meta-data → retrieve → utilize, where "utilize" expressly includes: (a) letting the controller correctly interpret the OS-specific request, (b) offsetting the requested LBA based on the amount and location of stored meta-data consumed, and (c) accessing the offset LBA as the requesting system directed.

Claim 19 — Apparatus, mirroring claim 18's offsetting limitation in means-plus-function form.

Claim 20 — Program product, mirroring claim 18's offsetting limitation as instruction means plus signal bearing means.

Key dependent-claim concepts (claims 2–5, 7–10, 12–17): querying occurs at initial program load; one meta-data set per distinct OS stored at initial contiguous LBAs; a mapping table of host → meta-data region; and recordable vs. transmission media for the program product.

---

4. Technical substance / the stated problem

The specification frames the field as three "cases of sharing":

• Case 1 — physical co-location only (separate subsystems in one cabinet); the state of the art.
• Case 2 — universal sharing of all data (called "practically unachievable").
• Case 3 — the target: one application (e.g., a database such as ORACLE) running on multiple heterogeneous systems directly reading/writing the same physical locations (same LBA = same data across systems).

The asserted cause of the problem: each OS's logical/physical volume manager partitions the disk its own way, so the controller receives requests for the "same" LBA in different "languages." The invention solves this by teaching the storage subsystem who its attached hosts are, storing that as meta-data in the lowest LBAs, and translating/offsetting each host's logical LBA into the true physical LBA. Two allocation variants are described:

• Approach ONE — each host sees a disk of a different effective size (offset = the other hosts' meta-data consumption).
• Approach TWO — the subsystem aligns all hosts to a common data-area size/address by padding with a "Storage Subsystem Owned Meta-Data Size," so every host sees the same geometry.

Figures: FIG. 1–2 = conventional IBM RISC System/6000 workstation hardware; FIG. 3 = the high-level flowchart (steps 200–218); FIG. 4 = a controller (100) with three heterogeneous hosts (AIX 102, Vendor-2 UNIX 104, Vendor-3 UNIX 106) and four disks (112); FIG. 5A/5B = meta-data placement and the transparency/offsetting scheme.

---

5. Prior art cited and downstream citation footprint

Prior art cited by the examiner (14–15 references) referenced in the record includes: US 4,630,196 (AT&T, store-and-forward multiprocessing); US 4,835,685 (Computer X, virtual single machine); US 5,214,768 and US 5,412,791 (E-Systems, mass data storage library); US 5,239,643 (IBM, reducing disk I/O in clustered multiprocessors); the IBM family US 5,363,497 / 5,369,767 / 5,369,749 / 5,388,215 (uncoupling a CPU from its OS, cross-OS memory allocation, direct inter-processor transfer); US 5,345,586 (IBM, distributed heterogeneous data manipulation); US 5,463,754 (IBM, shared DASD for fixed-block devices); US 5,471,609 (IBM, identifying a system holding a Reserve); US 5,625,841 (IBM); and US 5,758,125 (Newframe Corporation, "Method of sharing data in a heterogeneous computer system").

Downstream significance: The patent is cited in the international search report for WO 2001/042985 A3, "Sharing data between operating systems" (Storage Technology Corp.; inventor Kurt G. Schumacher; US priority 09/455,842, filed 1999-12-07) — there US 5,926,833 A is listed as an "X" (particularly relevant) document against claims 1–21. This is a third-party examiner's relevance finding about a later application; it is not a validity ruling on 5,926,833 itself. Source: https://patentimages.storage.googleapis.com/66/b0/b6/cb5cc5497bd150/WO2001042985A3.pdf

The patent is also cited by a substantial body of later work (IBM direct-I/O / LBA-translation families, Nextio/Emulex shared-I/O families, Hitachi storage systems, Microsoft schema-mapping patents, etc.), consistent with it being an early reference in the shared-storage/heterogeneous-access area.

---

6. Docket check (USPTO / PTAB / CAFC)

• No CAFC appeal, PTAB proceeding (IPR/PGR/CBM), or district-court complaint naming US 5,926,833 was surfaced by my searches. The patent expired (fee-related) with an anticipated expiration of 2017-03-24, so active assertion is unlikely.
• Searches for "5926833" also returned false positives that I am explicitly not treating as patent records: a Lithuanian company-registration notice number ("Pranešimo Nr. 5926833") and unrelated Realtime Data / Cardsoft / Verifone litigation materials that matched on other keywords.
• A USPTO Certificate of Correction for "PATENT NO.: 5,926,833 … July 20, 1999 … Inventor(s): Rasoulian et al." appears in the patent's scanned records (the substantive text of the correction was truncated in the copy retrieved). I could confirm the certificate exists but not the specific columns/lines corrected.

---

7. Explicit uncertainty and data-quality notes

1. Litigation search is not exhaustive. I did not query PACER, Docket Navigator, or the USPTO Patent Center/Assignment databases directly; my results come from general web search of indexed materials. Treat "no docket found" as "none surfaced," not as proof of no proceedings.
2. Inventor-name variant in a third-party record. The WIPO international search report OCR renders the inventor as "RASOULTAN BEHROUZ ET AL." Per your instruction, I am not auto-correcting that string — but note that the patent's own front page (and the Certificate of Correction) read "Rasoulian." These are almost certainly the same person, with the ISR spelling being an OCR/transcription artifact.
3. Internal document inconsistencies in the as-published text (likely OCR/printing artifacts, flagged rather than silently fixed): the FIG. 1–2 narrative refers to "the logic flow chart of FIG. 5" when the flowchart is FIG. 3; step labels appear as "Method stop 202"; and the OCR includes garbled tokens ("da storage subsystem," "used Zare distinct"). I have not verified these against the printed original.
4. Claim count. The patent carries 20 claims. The StorageTek ISR lists relevance to "claims 1–21," which does not match the 20-claim total and appears to be an error in that document.
5. "Approach ONE/TWO" and the numeric LBA examples (e.g., IBM AIX request for LBA 22 → LBA 28; Vendor X request for LBA 22 → LBA 26) are illustrative embodiments from the specification and are not claim limitations; the claims recite "offsetting … as appropriate," not specific values.

Primary source of record: https://patents.google.com/patent/US5926833/en (full text, claims, and citation data).

I'll research this systematically. Let me search multiple litigation sources for US patent 5926833.

Let me search specialized patent litigation sources directly.

Let me query litigation databases directly with more targeted searches.

Litigation Search Report: U.S. Patent No. 5,926,833

Patent Identified (for confirmation of scope)

Before reporting on litigation, I confirm the patent matched literally to the number you provided:

Sources: Google Patents US5926833A

---

Litigation Findings

I found no litigation involving U.S. Patent No. 5,926,833 — no district court infringement action, no PTAB proceeding (IPR/PGR/CBM), no ITC investigation, and no CAFC appeal in which this patent was the patent-in-suit.

I was unable to populate the requested case table (plaintiff, defendant, jurisdiction, case number, filing date, status) because no cases were located. I am stating this as an absence of discovered litigation rather than positively certifying the absence of any litigation anywhere.

What the searches did surface — and why these are NOT litigation

The only third-party references to the '833 patent that appeared were prior-art citations, which are frequently mistaken for litigation and should not be reported as such:

1. Cited as prior art in WO 2001/042985 A3 — "Sharing Data Between Operating Systems," Storage Technology Corporation (PCT/US2000/033039, priority 1999-12-07). The '833 patent is listed in the search report under category "X" as relevant to claims 1–21 of that application. This is a patentability citation in a published PCT application, not a lawsuit or PTAB proceeding.
   Source: WO2001042985A3 PDF

2. Forward citations (Cited By) — the '833 patent is cited by numerous later patents (e.g., US 6,073,209 to Ark Research Corp.; US 6,658,417 to IBM; various Nextio/Emulex/Mellanox shared-I/O patents). These are bibliographic citations by patent examiners/ applicants, not evidence of enforcement, suits, or IPR petitions.
   Source: Google Patents "Cited By" listing for US5926833A

3. Backward citations (Citations) — the '833 patent itself cites 14–15 earlier references (e.g., US 5,463,754 "Shared direct access storage device for fixed block architecture devices"; US 5,758,125 to Newframe Corporation; US 5,345,586). These are references considered during prosecution of the '833 patent, not litigation.
   Source: Google Patents "Citations" listing for US5926833A

Negative / false-positive control: A result referencing "U.S. Patent No. 8,663,683" appeared in a New Jersey ANDA/Hatch-Waxman answer (topiramate extended-release, Zydus/Cadila). That is a different patent number (8,663,683) and is unrelated to US 5,926,833. It has not been counted.

---

Methodology, Sources, and Limitations

Sources queried (via targeted web searches): Google Patents (full text and citation/legal-status records), Unified Patents litigation portal (portal.unifiedpatents.com), RPX Insight litigation documents, CourtListener RECAP dockets, and PTAB/PTACTS petition and filing repositories, plus general CAFC opinion searches.

Search terms used: the patent numbers "5926833" and "5,926,833"; inventor names "Rasoulian" and "Recio"; title keywords ("heterogeneous computing systems," "shared data storage subsystem"); and combinations with "litigation," "infringement," "lawsuit," and "complaint."

Limitations — please weigh these:

• I was stopped before completing the full planned search sequence, so this is not an exhaustive, database-by-database confirmation. My conclusion is based on the results actually returned.
• I could not run direct, confirmed queries against PACER (paywalled) or directly against the Unified Patents case list URL you cited; the searches returned general litigation material rather than a specific '833 hit.
• The patent's anticipated expiration on 2017-03-24 and its Expired – Fee Related status further reduce (but do not eliminate) the likelihood of recent enforcement activity.

---

Conclusion

No litigation is known involving U.S. Patent No. 5,926,833. The record I was able to assemble — Google Patents legal-status and citation records, plus litigation-oriented web sources — shows the '833 patent used only as a prior-art reference and as a citation in later patents, with no identified infringement suits, PTAB trials, ITC actions, or CAFC appeals.

Recommended next steps to confirm definitively (before treating this as final):

1. Run a docket-level search in Lex Machina, Docket Navigator, or RPX Insight filtered on patent number 5,926,833.
2. Check PACER for the patent number across all district courts.
3. Query the PTAB end-to-end system and the CAFC docket for the patent number.

If you'd like, I can draft the precise search strings for each of those paid databases so your paralegal or IP docketing team can complete the verification.

This is a factual search summary, not legal advice, and no attorney-client relationship is formed. Litigation coverage databases are not exhaustive; the absence of a record does not conclusively establish that no litigation exists.

I'll verify the structured block's "no proceedings" result with targeted web searches before reporting.

No hits yet. Let me run a few more targeted checks, including the PTAB E2E-style search and CAFC angle.

Two more checks — CourtListener/docket and any litigation that would have driven an IPR.

PTAB / AIA Trial Proceedings — US Patent 5,926,833

Verification performed (2026-09-30): structured USPTO ODP block (canonical) plus four targeted web searches — by patent number alone, by patent number + "IPR/PTAB", by inventor names + PTAB, and by "inter partes review … cancelled claims." No AIA trial number, petition, institution decision, Final Written Decision, or Director Review decision naming US 5,926,833 surfaced in any query.

---

Proceedings overview

Total AIA trial proceedings on US 5,926,833: zero. The USPTO Open Data Portal returns no IPR, PGR, or CBM proceedings against this patent, and my web searches surfaced none the ODP may not have indexed — so the breakdown is 0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denials, and the defensive posture is not "the patent is hardened by surviving IPRs." The correct reading of the silence is the opposite: this patent was never subjected to PTAB attack at all, and the reason is that the record shows it lapsed for non-payment of maintenance fees (Google Patents legal events: "PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362" and "FP — Lapsed due to failure to pay maintenance fee; Effective date: 2003-07-20", https://patents.google.com/patent/[US5926833A](/patent/US5926833A)/en). An unassertable, lapsed patent generates no petitions, and AIA trials did not even exist until 2012-09-16 — nine years after the recorded lapse.

Flagged contradiction with the previously generated summary. Section 1 of the earlier summary lists this patent as "Expired – Fee Related; anticipated expiration 2017-03-24 (20 years from filing)." The Google Patents legal-events record I retrieved shows a lapse event with an effective date of 2003-07-20 (four years post-grant, i.e., the first maintenance-fee window). These two statements cannot both describe an enforceable term through 2017. The "2017-03-24 anticipated expiration" line is a computed 20-year term date, not an event of record; the 2003 lapse is an event of record. I could not resolve which controls from open sources and I am not asserting a legal conclusion — but the discrepancy matters materially to enforcement posture and should be resolved via USPTO Patent Center / the fee record before anyone relies on either date.

Per-proceeding detail

None exists. There are no proceeding numbers to report, and I will not generate placeholder numbers for AIA trials that were never filed. For completeness, the categories turn out as follows:

Why the negative result is credible here (not merely an absence of evidence):

1. Timing. IPR/CBM/PGR became available 2012-09-16 (AIA). The recorded maintenance-fee lapse is 2003-07-20. A patent already lapsed for fee non-payment has essentially no litigation or licensing exposure to motivate a petition.
2. Standing-by-type. This is a pre-AIA patent (priority 1997-03-24), so PGR is unavailable by statute — it applies only to patents subject to the first-inventor-to-file provisions. CBM was theoretically available only if the patent qualified as a "covered business method" patent and the petition was filed before the transitional program sunset on 2020-09-16; no such petition was filed. That leaves only IPR under 35 U.S.C. § 311 — and none was filed.
3. No litigation engine. Earlier in this analysis, no district-court complaint, PTAB proceeding, or CAFC appeal naming this patent was surfaced. No litigation means no defense-side budget for a petition.

---

Strategic summary

Claim status — UNTESTED, not narrowed. All 20 claims (independent claims 1, 6, 11, 18, 19, 20 and dependents 2–5, 7–10, 12–17) stand exactly as issued at the PTAB level. There is no IPR certificate cancelling anything, no FWD sustaining anything, and no Board claim construction on the record. Do not represent any claim as "cancelled" or as "upheld" — neither happened. The only post-issuance amendment of record is a Certificate of Correction (referenced in the earlier summary, substantive text not retrieved), which corrects typographical/clerical matter and is not a validity adjudication.

Estoppel landscape — a clean slate, with a caveat. Because no AIA trial was ever instituted, 35 U.S.C. § 315(e)(2) estoppel is a null set: no petitioner, real party in interest, or privy is barred from raising any § 102/§ 103 ground based on patents or printed publications. Every prior-art ground — including art already cited in the file and the art cited in the WO 2001/042985 A3 international search report — remains procedurally available to a defendant today, subject only to § 325(d) discretion (which itself is now exercised by the Director, not a panel; see the October 2025 institution memorandum discussed below). The practical caveat is that estoppel availability is academic: on the record before me the patent appears to have lapsed in 2003, and a defendant's first move is an unenforceability/expiration defense, not a § 102/§ 103 fight.

Pattern signals — none. No repeated-petitioner pattern (there is no petitioner). No patent-owner PTAB-appeal activity (there is no FWD to appeal, so no CAFC docket number exists). No defensive aggregator (e.g., Unified Patents) appears anywhere in the chain — and none would have had a reason to file against a lapsed patent. The patent's third-party significance is citation-side, not challenge-side: it is the "X" reference against WO 2001/042985 A3 and an early citation in the IBM direct-I/O, Nextio/Emulex shared-I/O, and Hitachi storage-system families. That is a prior-art footprint, not a target footprint.

Institutional context worth noting for any future filing (if the lapse is somehow reversed). PTAB practice has shifted sharply since this patent lapsed: under Director Squires's 2025-10-17 memorandum (Director Institution of AIA Trial Proceedings, https://www.uspto.gov/sites/default/files/documents/Director_Institution_of_AIA_Trial_Proceedings.pdf), the Director — not a three-APJ merits panel — now decides whether to institute IPR and PGR, and as of 2026 that authority is exercised personally by the Director, with discretionary-denial briefing available to the patent owner. The parallel October 2025 proposed rules would bar an IPR against a patent that had already survived a validity challenge in court or at the PTAB, and would require petitioners to stipulate not to pursue §§ 102/103 arguments elsewhere. For a hypothetical future petition against a 1999 patent with a 1997 priority date, "settled expectations" and patent-age discretionary factors would loom large. Sources: https://www.willkie.com/publications/2025/10/ptab-announces-new-institution-policy; https://www.uspto.gov/sites/default/files/documents/InterimProcesses-PTABWorkloadMgmt-20250326.pdf.

---

Recommended next steps

1. Lead with the terminal-status defense, not with PTAB. There are no AIA proceedings to cite because there are none. The dispositive point is the maintenance-fee lapse event of record. Pull the USPTO Patent Center maintenance-fee/status record and the fee-payment history for US 08/822,891 to confirm (a) whether the 4-year fee was in fact unpaid, (b) the exact lapse date, and (c) whether any petition to accept an unintentionally delayed payment was filed (I found none, but I did not query the fee record directly). If the patent is lapsed and unrevived, that is a complete answer to a demand letter and is cheaper to establish than any IPR — and 35 U.S.C. § 286's six-year damages lookback makes it decisive regardless of validity.
2. Resolve the date conflict before drafting anything that relies on it. The earlier summary's "anticipated expiration 2017-03-24" versus the recorded "Effective date: 20030720" lapse is an unresolved inconsistency in the source material. Confirm which governs and correct the record.
3. If, and only if, the patent is shown to be live: the full § 102/§ 103 prior-art space is procedurally open (no § 315(e) estoppel attaches to anyone), so a defendant could file an IPR, but must clear (i) the Director's discretionary-institution gate under the 2025 process, (ii) the Fintiv-style parallel-proceeding factors, and (iii) § 325(d) against the art already cited by the examiner — including the Newframe reference US 5,758,125, which was before the examiner and is closely on point. Statutory framework if a trial institutes: institution decision within 3 months of the patent owner's preliminary response, and FWD within one year of institution (35 U.S.C. § 316(a)(11)), subject to good-cause extension.
4. Statement of limitation, restated: this is a measured negative finding, not proof of a negative. I did not query PACER, Docket Navigator, PTAB E2E/PTACTS directly, or the CAFC docket by hand; my conclusion rests on the canonical ODP block plus indexed web search. If a specific demand letter or district-court case number exists, re-run the check against that case number and against PTAB E2E, because a just-filed or recently-terminated pre-institution proceeding could post-date the ODP ingest.

Assignment / Ownership Analysis — US Patent 5,926,833

Method note (read first). The authoritative text supplied in the user message plus the Google Patents legal-events record show exactly one recorded ownership transaction for this patent: the original assignment of assignors' interest from the two inventors to IBM, executed and recorded on the filing date. My live web searches (Google Patents legal events, FreePatentsOnline, Justia, general queries on the patent number, application number, and inventor names) surfaced no post-issuance assignment, security agreement, merger, change of name, or other recorded conveyance, and no NPE/asserter linkage. I was not able to open the USPTO Assignment Center record interactively, so I could not read the specific reel/frame or the correspondent of record for even the one recorded assignment; I have not invented them. Treat the reel/frame fields below as "not retrieved," not as "none exists."

---

Inventors

• Both inventors assigned their rights to IBM on the filing date (1997-03-24) — the standard IBM pre-filing invention-assignment practice. There is no evidence of either inventor departing IBM within 12 months of filing; the "inventor flight precedes a fire-sale" pattern is not present (and cannot be shown absent employment records, which I did not retrieve).
• Note on record quality: the WIPO international search report for a related later application OCR-renders the inventor as "RASOULTAN BEHROUZ ET AL." The patent front page and the Certificate of Correction read "Rasoulian." I am not auto-correcting the ISR string, but flag it as an OCR artifact, not a second inventor.
• Renato John Recio is a prolific IBM storage/networking inventor and recurs as a named inventor on IBM's later direct-I/O and LBA-translation family (e.g., the Boyd/Hufferd/Mena/Recio/Vega patents). That is a technical-continuity observation, not an ownership signal.

Caveat: employer attribution is inferred from the front-page assignee and the recorded assignment; I did not verify individual employment histories against external sources for this specific patent.

---

Original assignee

• Entity on the issued patent: International Business Machines Corporation, Armonk, New York (original assignee and, per the record, the only assignee ever recorded for this patent).
• Primary line of business: enterprise computing — hardware, software, and services. Patent sits in IBM's storage-subsystem / AIX (IBM's UNIX) portfolio. FIG. 1–2 teach the IBM RISC System/6000 platform, and the specification's worked example uses AIX, IBM's UNIX implementation.
• Did they ship a product embodying the claims? Unclear. The patent is a method/apparatus/program-product claim set directed at a data storage subsystem controller that stores per-OS meta-data in the lowest LBAs and offsets host LBAs. IBM was an active vendor of shared DASD/enterprise storage (e.g., the contemporaneous IBM shared-DASD-for-fixed-block art cited on the face of the patent, US 5,463,754). I found no product literature, press release, or specification tying these specific claims to a shipped IBM product, so I will not assert embodiment.
• Current status: IBM operating (no bankruptcy, dissolution, or acquisition). The patent itself is Expired – Fee Related, with an anticipated expiration of 2017-03-24 (20 years from the 1997 filing date). IBM let it lapse rather than pay maintenance fees — the ordinary outcome for a 1997 storage-method patent with no assertion history.

---

Assignment timeline

Only one recorded conveyance is evidenced in the sources I could reach. The Assignment Center record could not be read directly, so reel/frame and correspondent are not retrieved.

• 1997-03-24 (executed & recorded) — Reel not retrieved / Frame not retrieved
  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)
  • Assignor: RECIO, RENATO J.; RASOULIAN, BEHROUZ (the two inventors)
  • Assignee: INTERNATIONAL BUSINESS MACHINES CORPORATION
  • Correspondent: not retrieved from the sources reachable to me (I did not open the Assignment Center record directly, and Google Patents' legal-events feed does not expose the correspondent). I therefore make no repeat-correspondent finding.
  • Context: Ordinary pre-filing employment assignment — inventors conveying rights to their employer as a condition of filing. This is the only link in the chain.

No further recorded assignments, security agreements, mergers, name changes, releases, or corrections-of-ownership were surfaced for US 5,926,833. That absence is itself the key finding in this section: there is no evidence the patent ever left IBM. The only "correction" item associated with the patent is a USPTO Certificate of Correction (Rasoulian et al., issued patent dated 1999-07-20) noted in the patent's scanned records; the substantive text was truncated in my copy and I could not confirm whether it corrected ownership or merely typographical text — a certificate of correction is not a title transfer in any event. (This is consistent with the prior summary section.)

Sources: https://patents.google.com/patent/US5926833/en (Legal Events / Reassignments); https://www.freepatentsonline.com/5926833.html

---

Timeline diagram

timeline
    title Ownership of US 5926833
    1997 : Inventors assign rights to IBM
         : Application 08 822 891 filed
    1999 : Patent issued to IBM
    2017 : Expired fee related

(Only events substantiated by the record are shown. There are no post-issuance transfers to plot.)

---

NPE / troll-pattern signals

1. Shell-entity transfer — Not present. No operating-assignee → licensing-LLC transfer is evidenced. The chain never leaves IBM; no "IP / Holdings / Ventures" successor appears in the record.
2. Known asserter in the chain — Not present. Current and prior assignee is IBM only. No Acacia, Marathon, IV, Wi-LAN, Mosaid/Conversant, Round Rock, etc. appears. No Unified Patents or RPX high-frequency-plaintiff match was surfaced.
3. Repeat correspondent across the chain — Unclear / cannot assess. With only one recorded link and no correspondent retrieved, there is no basis to find (or rule out) a recurring recording attorney. Not inferable from the available data.
4. Cascading transfers — Not present. There is a single assignment; no chained LLC hops, let alone hops within 24 months.
5. Pre-litigation transfer — Not present. No litigation naming this patent was found (consistent with the prior summary's docket check), so there is no suit to measure a transfer against. Anticipated expiration 2017-03-24 and Expired – Fee Related status make assertion moot.
6. Bankruptcy fire-sale — Not present. IBM did not file for bankruptcy; the patent simply lapsed for fee non-payment.
7. Privateering — Not present. No evidence IBM transferred this patent to an NPE to assert against competitors. (IBM has run more sophisticated offensive-licensing programs generally, but nothing ties this specific patent to such a transfer.)
8. Defensive aggregator (anti-NPE) — Not present. The chain does not terminate at RPX, AST, LOT, Unified, or OIN. It terminates at the original operating company.

---

Verdict

Insufficient data — but with the specific meaning the rubric intends: the record shows only the original assignment and no post-issuance chain.

The sole recorded conveyance is the inventors → IBM assignment executed and recorded 1997-03-24 (reel/frame not retrieved; correspondent not retrieved), and the patent issued 1999-07-20 to IBM, remaining with IBM until it expired fee-related on 2017-03-24. There is no record of any transfer to a shell entity, known asserter, or defensive aggregator, and no litigation surfaced, so no NPE signal is supported. Every NPE indicator above is either not present or, for the correspondent-recurrence signal, not assessable from the records I could reach.

Verification links:

• USPTO Assignment Center (search "5926833" or application "08/822,891"): https://assignmentcenter.uspto.gov/
• Legacy assignment search: https://assignment.uspto.gov/patent/index.html
• Google Patents legal events: https://patents.google.com/patent/US5926833/en

Remaining gap I could not close: the reel/frame and correspondent of record for the single 1997 assignment, and confirmation of whether the Certificate of Correction touched any ownership text. If you want those fields filled, the assignment record must be opened directly at the Assignment Center (I could not do so interactively here) — I have deliberately left them blank rather than guess.

I'll research the prior-art citations for US 5,926,833. Let me search for the key references.

Let me gather details on the remaining cited references.

I hit the tool-call limit mid-research, so I'll report what was confirmed and be explicit about where I'm relying on the patent's own front-page citation data rather than a full-text read of each reference.

Prior-Art Analysis — US 5,926,833 ("Direct Data Access to a Shared Data Storage Subsystem by Heterogeneous Computing Systems")

0. Confirmation of the target patent (USPTO record)

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

Search-integrity note (per your strict rule): my search for "5926833" returned the correct record (Google Patents full text, plus the patentimages PDF of the AS-issued document). I did not return or rely on any look-alike numbers. One false positive that surfaced during the earlier litigation pass — US 8,663,683 — is a different patent and is excluded here. I could not open a Patent Center / PAIR-native citation list within the step budget; the citation set below is taken from the patent's own front page ("Patent Citations (15)") as reproduced in the authoritative full text, which is the prosecution record of record.

Critical date: Because the application was filed 1997-03-24, the § 102(b) one-year bar date is 1996-03-24. This is a pre-AIA (first-to-invent) case; the relevant subsections are § 102(a), § 102(b) and § 102(e).

Structural note on the claims: The core limitation is not merely "share a disk between hosts." Claim 1 affirmatively requires four things: (1) querying every host for which operating system it runs; (2) creating/storing meta-data that associates each host with its OS; (3) retrieving that meta-data, specifically by identifying the requesting host → determining the LBAs where that host's meta-data lives → reading it; and (4) using the meta-data to interpret/respond to the request "consonant with" the requesting host's OS. Claims 18/19/20 add the LBA-offsetting step. The strongest prior-art question is therefore whether any reference teaches the host-OS discovery + per-host meta-data mapping + OS-aware LBA translation combination.

---

1. Summary table — all 15 examiner-cited references

Bottom line: On the record available, none of the 15 cited references appears to disclose every element of any independent claim (1, 6, 11, 18, 19, 20) under § 102. The two closest are US 5,758,125 and US 5,463,754, both of which are better characterized as § 103 combination art than as anticipatory art. This is consistent with the patent having issued over these references at the examiner level.

---

2. Reference-by-reference detail

US 4,630,196 — Bednar et al. / AT&T Information Systems, Inc.

• Full citation: US 4,630,196, "Store and forward facility for use in multiprocessing environment," filed 1983-04-13, issued 1986-12-16, Appl. No. 484,474; inventors Joseph A. Bednar Jr., Richard L. Bennett, Charbak R. Dutt, Michael K. Stafford.
• Description: A message store-and-forward facility for a multiprocessing, multinode environment. "Transfer" and "delivery" processes create a message at an originating application process and route it to a delivery process at each destination node, which maintains a work item and notifies the destination application when an earliest-delivery time is reached. No shared disk, no block-address translation, no OS discovery.
• § 102 assessment: Anticipates no claim. It is multiprocessor messaging infrastructure; it does not query hosts for operating systems, does not store host↔OS meta-data, and does not translate LBAs. Cited for general multiprocessing background.

US 4,835,685 — Kun et al. / Computer X, Inc.

• Full citation: US 4,835,685, "Virtual single machine with message-like hardware interrupts and processor exceptions," filed 1985-05-06, issued 1989-05-30. (Same family as EP 0 201 065: Computer X, "Virtual single machine with logical ring…")
• Description: A distributed "virtual single machine" in which processes communicate only by messages and hardware devices appear as processes; "messages provide the mechanism by which hardware transparency is achieved." Interrupts/exceptions are handled as messages.
• § 102 assessment: Anticipates no claim. It supplies a concept of hardware transparency across heterogeneous nodes, but there is no shared-storage subsystem, no LBA offsetting, and no host-OS query/mapping. Background art only (potentially usable in a § 103 obviousness narrative about "transparency").

US 5,214,768 — E-Systems, Inc.

• Full citation: US 5,214,768, "Mass data storage library," filed 1989-11-01, issued 1993-05-25.
• Description: A mass (robotic/tertiary) storage library management system. (Full text not retrieved; description from title/citation table.)
• § 102 assessment: Anticipates no claim. No OS identification, no per-host meta-data, no logical→physical LBA translation for heterogeneous OSs.

US 5,239,643 — IBM

• Full citation: US 5,239,643, "Method for reducing disk I/O accesses in a multi-processor clustered type data processing system," filed 1987-11-30, issued 1993-08-24.
• Description: Reduces disk I/O in a clustered multiprocessor system (from title/citation table).
• § 102 assessment: Anticipates no claim. Cluster I/O optimization; no host-OS discovery or meta-data mapping.

US 5,325,517 — IBM

• Full citation: US 5,325,517, "Fault tolerant data processing system," filed 1989-05-17, issued 1994-06-28.
• § 102 assessment: Anticipates no claim. Fault tolerance; unrelated to the claimed OS-aware shared-storage translation.

US 5,345,586 — IBM

• Full citation: US 5,345,586, "Method and system for manipulation of distributed heterogeneous data in a data processing system," filed 1992-08-25, issued 1994-09-06.
• Description: Manipulation of distributed heterogeneous data (from the citation table; full text not retrieved).
• § 102 assessment: At most marginal. The word "heterogeneous" overlaps, but the claim requires the addressing/translation sub-steps (query OSs, store host↔OS meta-data at known LBAs, offset LBAs). Nothing in the title/record indicates those. Not anticipatory as recorded; could be § 103 background.

US 5,363,497 — IBM

• Full citation: US 5,363,497, "System for removing section of memory from first system and allocating to second system in a manner indiscernable to both operating systems," filed 1989-05-17, issued 1994-11-08.
• Description: Cross-OS resource re-allocation made invisible ("indiscernable") to both operating systems.
• § 102 assessment: Marginal on one element only — it bears on Claim 1's "such that said method is transparent to said heterogeneous computing systems" limitation (and the analogous transparency language in claims 6/11/18–20). It does not teach the querying, meta-data creation, or meta-data-LBA determination steps, so it cannot anticipate any independent claim standing alone.

US 5,369,767 — IBM

• Full citation: US 5,369,767, "Servicing interrupt requests in a data processing system without using the services of an operating system," filed 1989-05-17, issued 1994-11-29.
• § 102 assessment: Anticipates no claim. Interrupt handling that bypasses the OS; no storage-sharing translation.

US 5,369,749 — IBM

• Full citation: US 5,369,749, "Method and apparatus for the direct transfer of information between application programs running on distinct processors without utilizing the services of one or both operating systems," filed 1989-05-17, issued 1994-11-29.
• Description: Direct inter-processor application-to-application data transfer that removes the OS from the data path.
• § 102 assessment: Marginal. It supports the notion of "direct access" independent of the OS, relevant rhetorically to Claim 1's "direct access" limitation, but it involves no shared data-storage subsystem, no meta-data, and no host-OS identification/mapping. Not anticipatory.

US 5,388,215 — IBM

• Full citation: US 5,388,215, "Uncoupling a central processing unit from its associated hardware for interaction with data handling apparatus alien to the operating system controlling said unit and hardware," filed 1989-05-17, issued 1995-02-07.
• Description: A CPU is uncoupled from its hardware so it can interact with data-handling apparatus "alien" to the controlling OS.
• § 102 assessment: Marginal. Conceptually adjacent to a subsystem controller that must deal with a "foreign" OS's conventions, but it discloses no host-OS query, no per-host meta-data store, and no LBA offsetting. Not anticipatory.

US 5,412,791 — E-Systems, Inc.

• Full citation: US 5,412,791, "Mass data storage library," filed 1989-11-01, issued 1995-05-02. (Companion/continuation to US 5,214,768.)
• § 102 assessment: Anticipates no claim. Same reasoning as US 5,214,768.

US 5,463,754 — Beausoleil et al. / IBM (one of the two most relevant)

• Full citation: US 5,463,754, "Shared direct access storage device for fixed block architecture devices," filed 1992-10-30, Appl. No. 07/969,865, issued 1995-10-31; inventors Beausoleil, Hupcey, Berghorn, Schlosser. (§ 102(b).) (Related program-product patent: US 5,564,019.)
• Description (confirmed from the patent PDF): Provides two or more computer systems with regulated access to a shared FBA DASD. A shared FBA control unit couples the disk to the systems and maintains SDF lock files — one control file per shared file — containing map records with system identification, starting block/cylinder, extent, link flag (read/write/none), an up/down status flag, and a heartbeat count. New SETL/QSETL channel control words let a system request/lock a block range; the control unit reads the lock file to detect conflicting access, grants access, and records the requesting system's identity. Heartbeat updates let it detect a "down" system and break stale locks.
• § 102 assessment: Moderate, and the best "physical-sharing" teaching — but not a full anticipation.
  • Overlap: shared DASD accessed by multiple hosts through a controller; the controller stores access information in control files and identifies the requesting system; supports more than 16 systems; block-address ("fixed block") granularity.
  • Gaps vs. the claims: the disclosure is oriented to write-exclusion/locking ("does not require monitoring by trained operators," "more than 16 systems"), not to discovering each host's operating system and storing host↔OS meta-data that lets the controller interpret that host's specific request format. There is no teaching of querying hosts for their OSs (Claim 1 step 1 / Claim 2's "initial program load" query) and no OS-consonant interpretation step. It could arguably bear on the dependent-claim notion of controller-maintained per-system records, but it does not anticipate claims 1, 6, 11, 18, 19 or 20 as a whole.
  • Best use: § 103 combination (e.g., with US 5,758,125) rather than § 102.

US 5,471,609 — IBM

• Full citation: US 5,471,609, "Method for identifying a system holding a 'Reserve'," filed 1992-09-22, issued 1995-11-28.
• Description: Identifies which system holds a Reserve on a shared resource/device.
• § 102 assessment: Marginal on the identification element only. It relates to the "identifying which of said heterogeneous computing systems … is making said request" sub-step that Claim 1 (and Claim 6/11) recites — but identifying a reserve holder is not identifying a requesting host's OS and does not, alone or with the rest, meet any full claim. Not anticipatory.

US 5,625,841 — IBM

• Full citation: US 5,625,841, "Data processing system," filed 1994-04-20, issued 1997-04-29. (§ 102(e) art as of its 1994-04-20 filing date, since it issued on an application filed before the '833 application's 1997-03-24 date and is by "another.")
• Description: Not retrieved — the generic title "Data processing system" is uninformative, and my full-text search was cut off by the step limit. Per your rule I am not guessing at its substance.
• § 102 assessment: Undetermined. I cannot responsibly state that it does or does not anticipate any claim without reading its disclosure. Flag mentally: its § 102(e) date (1994-04-20) makes it potentially available art; whether it teaches the claimed OS-query/meta-data/offset features is unverified. Recommend a full-text pull before relying on it.

US 5,758,125 — Misinai et al. / Newframe Corporation Ltd. (the strongest cited reference)

• Full citation: US 5,758,125, "Method of sharing data in a heterogeneous computer system," filed (Appl. No. US 08/579,721) 1995-12-28, issued 1998-05-26; inventors Tsvi Misinai, Michael Rothschild, Shmuel Alazraki, Arie Kremer. (§ 102(e) art as of 1995-12-28.)
• Description (confirmed): Heterogeneous computer systems (different CPUs, disk organization methods, controller interfaces, access methods) share a single copy of data in a common mass storage, with each system accessing it independently and without relying on services from the others. The mass storage controller and/or host contain emulators that translate between each system's disk organization method (DOM1, DOM2) and the storage's DOM3; a "virtual device" read calls a translation module that converts a shared record into the host's format, and a write converts the host's format into the shared format. Contemplates a mainframe (DB2) + UNIX environment, shared cache, and heterogeneous locking.
• § 102 assessment: The closest reference, and the most dangerous — but still not a clean § 102 anticipation of the independent claims.
  • Overlap (substantial): multiple heterogeneous computer systems; a mass-storage controller; the controller interpreting/translating requests arriving in different system-specific formats so that heterogeneous hosts reach the same stored data; transparency to the applications.
  • Gap vs. Claim 1: US 5,758,125 discloses translation keyed to a known disk organization method implemented by emulators; it does not disclose (a) querying all attached hosts as to which operating system each runs, (b) creating and storing meta-data associating each host with its OS on the storage subsystem, or (c) the claim's specific retrieval protocol of identifying the requesting host → determining the LBAs holding that host's meta-data → reading the meta-data from those LBAs. Its translation is emulator-driven, not host-OS-meta-data-driven, and it is silent on the LBA-offsetting mechanism of claims 18–20.
  • Conclusion: Does not anticipate claims 1, 6, 11, 18, 19, 20 on its disclosed technique. It is, however, the best § 103 primary reference if combined with a host-OS-discovery/meta-data element (e.g., from US 5,463,754's controller-maintained per-system records, or from the same-family US 5,345,586/US 5,363,497 "heterogeneous"/"indiscernable" teachings). Note the two-way relationship: this same reference is the one later cited against the StorageTek WO 2001/042985 application — see § 4 below.

---

3. Where each claim's elements are (and are not) met

---

4. Forward-citation context (not prior art — flagged so it isn't confused)

The patent is cited as prior art against a later application: WO 2001/042985 A3, "Sharing data between operating systems," Storage Technology Corp. (PCT/US2000/033039, priority 1999-12-07), where US 5,926,833 A is listed as an "X" (particularly relevant) document against claims 1–21. That is a third-party patentability citation, not a validity ruling on the '833 patent. It confirms that examiners in the same art treat the '833 patent's host-OS-aware sharing concept as broad prior art. (Source: https://patentimages.storage.googleapis.com/66/b0/b6/cb5cc5497bd150/WO2001042985A3.pdf)

---

5. Explicit uncertainties and caveats

1. Full-text verification gap. I confirmed the disclosures of US 4,630,196, US 4,835,685, US 5,463,754 and US 5,758,125 from primary documents. For the other references I relied on the patent's own citation table plus abstracts/titles; US 5,625,841 in particular has an uninformative title and I could not retrieve its body before the step limit. My "anticipates no claim" conclusions for those references are provisional and should be re-run against full text before being treated as final.
2. § 102 vs. § 103. Anticipation requires a single reference disclosing every element arranged as claimed. Several references here overlap individual elements (transparency, identify-the-system, shared controller, heterogeneous translation) but none, on this record, meets the whole of any independent claim. The strongest grounds against the '833 claims would be § 103 combinations anchored on US 5,758,125 or US 5,463,754.
3. § 102(e) dates. US 5,625,841 and US 5,758,125 are available only under § 102(e) (as US patents granted on applications filed before the applicant's invention), not § 102(b). US 5,758,125's "swear-behind" exposure is minimal (filed 1995-12-28, ~15 months before the '833 filing).
4. Common ownership. Several cited references are IBM-owned (US 5,239,643; 5,325,517; 5,345,586; 5,363,497; 5,369,767; 5,369,749; 5,388,215; 5,462,841; 5,463,754; 5,471,609; 5,625,841). Common ownership does not defeat § 102, but it matters for pre-AIA § 103(c) obviousness-type disqualification if any combination is contemplated.
5. Claim-count discrepancy carried forward from the earlier section. The patent has 20 claims; the StorageTek ISR's reference to "claims 1–21" is an error in that document — not corrected here, just noted.

Primary source of record: https://patents.google.com/patent/US5926833/en (front-page citation list, claims, and legal-status data).

I'll research the cited prior art references to ground an element-by-element § 103 analysis.

Let me research the remaining key cited references to build the combination analysis.

Obviousness Analysis — U.S. Patent No. 5,926,833 under 35 U.S.C. § 103

Scope note. The patent has a 1997-03-24 filing/priority date, so pre-AIA § 103(a) governs (no AIA "reasonable certainty" gloss, and pre-AIA § 102(e) is available for U.S. patents and published applications filed before the applicant's date). Every reference I rely on below is from the "Citations (14–15)" / "Patent Citations" list on the patent's own record. I have full or substantial text for US 5,758,125, US 5,463,754 (and its sibling US 5,564,019), US 5,363,497, US 5,345,586, and US 5,214,768 / US 5,412,791; for US 4,630,196, US 4,835,685, US 5,239,643, US 5,325,517, US 5,369,767, US 5,369,749, US 5,388,215, US 5,471,609, and US 5,625,841 I have the title/assignee/subject matter as given in the citation table plus general knowledge, and I flag where that limits confidence. This is a technical obviousness analysis, not an invalidity opinion or legal advice.

Cross-reference / consistency check with earlier sections. Nothing in the earlier-generated summary and litigation sections contradicts what follows. One correction-by-reference: earlier sections correctly note the internal OCR artifacts ("logic flow chart of FIG. 5" vs. FIG. 3; "Approach ONE/TWO" as illustrative only). Those do not affect claim scope, and I do not rely on any specification value (e.g., LBA 22→28) as a claim limitation — the claims recite only "offsetting … as appropriate," which matters to the analysis in § 5.

---

1. Framework and the hypothetical person of ordinary skill

Under Graham v. John Deere, obviousness turns on (a) the scope and content of the prior art, (b) the differences between the prior art and the claims, (c) the level of ordinary skill, and (d) secondary considerations. Under KSR Int'l v. Teleflex, the "motivation to combine" may be found in the nature of the problem, the design incentives, and the predictable use of prior-art elements according to their established functions; the combination need not be taught by an explicit "teaching, suggestion, or motivation."

Level of ordinary skill (POSITA). For this field in March 1997, a POSITA would be a person with a bachelor's degree in electrical engineering or computer science (or equivalent) and roughly two to four years of experience in one or more of: (i) data storage subsystem/disk controller firmware, (ii) operating-system device drivers and logical volume managers, and (iii) storage networking/interconnect protocols. Such a person would be familiar with fixed-block (FBA) disk addressing, "reserve/release" and device-discovery protocols, per-host configuration tables in a controller, and the practice of reserving low-LBA regions on a device for controller/OS metadata.

Imperative caveat on the specification's own framing. The specification repeatedly asserts that "there is no known solution in the industry today" for Case 3 sharing and that "there is no known solution to this problem, other than duplicating the application and its data or partitioning the application and its data." That is the applicant's characterization of the art, and it is not controlling evidence of nonobviousness. In re Sneed / In re GPAC: the scope and content of the prior art is measured by what the references actually disclose or fairly suggest, not by the inventor's or attorney's description of the field. As shown below, the cited references do disclose or suggest the constituent elements.

---

2. The invention reduced to its claim elements

Independent claim 1 (method) recites, in substance:

Claim 18 adds: E4 implemented by (i) enabling the controller to interpret the OS-specific request, (ii) offsetting the requested LBA "dependent upon the character of said requested data and the amount and location of meta-data stored," and (iii) accessing the offset LBA. Claims 6/19 are apparatus (means-plus-function) counterparts of 1/18; claims 11/20 are program-product counterparts with "signal bearing means."

The governing design insight is therefore narrow and mechanical: the storage controller learns each host's disk-organization "dialect," stores that as a per-host metadata record on the storage device at known block addresses, and applies the correct translation (including an LBA offset) so that different hosts reach the same physical data transparently. That is exactly the class of subject matter in which the cited art is dense.

---

3. Primary combination — Claim 1 obvious over US 5,758,125 in view of US 5,463,754

3.1 US 5,758,125 (Newframe Corp., "Method of sharing data in a heterogeneous computer system")

This is the strongest single reference and, tellingly, it was cited by the examiner (it appears with the "*" (cited-by-examiner) marker in the record). Its date qualifies it as prior art: filed 1995-12-28, issued 1998-05-26 — a pre-AIA § 102(e) reference.

Its disclosure maps closely:

• Heterogeneous systems, one copy of data, direct access: "These systems share data so that every one of the said computer systems can access the data independently, not relying on services from the others. A single copy of the data is maintained, as opposed to replicated data…" — i.e., the Case 3 objective.
• Transparency to applications: the emulators "enable applications on every system to use the desired interfaces to the data, disguised as the ordinary local interfaces" — i.e., the "transparent" functional result of E4.
• Controller-side translation keyed to the requesting system's disk-organization method (DOM): the mass storage controller contains an emulator per attached system/interface — one translating DOM 2 ↔ DOM 3 for the second system and another translating DOM 1 ↔ DOM 3 for the first system. Practically, therefore, the controller must hold, per interface, an association between the attached system and its disk organization method (DOM 1 vs. DOM 2) to pick the right translation — a teaching of E2's "associate each system with an OS/its interface dialect" in substance.
• Cross-UNIX and cross-vendor: claim 5 of '125 expressly covers "one of said computer systems is a UNIX machine and the other … another UNIX machine," and claim 3 covers mainframe↔UNIX — precisely the "AIX vs. Vendor-2 UNIX vs. Vendor-3 UNIX" scenario of FIG. 4 of the '833 patent.

What '125 does not expressly state is (i) that the DOM/emulator association is stored as metadata on the storage subsystem itself at LBAs (E2's "storing" location and E3b's "determine the LBAs of the meta-data"), and (ii) a discrete "query" of each host for its OS (E1).

3.2 US 5,463,754 (IBM, "Shared direct access storage device for fixed block architecture devices")

Also examiner-cited and squarely on point. This reference teaches a shared FBA DASD controller serving multiple computer systems and, critically, the on-device control-file mechanism:

• A separate SDF lock file is maintained in a subdirectory of the directory that contains the actual shared data file on the shared device itself (e.g., Main:/First/SDF/Exempl.1) — i.e., metadata stored on the storage subsystem at known locations, not in host memory.
• Each map record contains: "a system identification which identifies the system accessing the shared volume, a starting block or cylinder number, the number of cylinders or blocks accessed (the extent), a link flag … [and] a status flag" — i.e., a per-host record identifying the host and the block addresses it is associated with. This directly reads on E3a (identify the requesting system) and E3b (determine the block addresses of the associated metadata).
• The control unit is coupled to the shared device and to all hosts and creates/reads/updates these records ("[t]he SETL unit 120 … provides a means for creating control files," "a means for storing access information to the SDF lock files," "a means for retrieving (reading) access information from the SDF lock files") — the controller-side create/store/retrieve steps of E2/E3.
• Its sibling US 5,564,019 claims this as a program storage device / computer program product ("computer readable first/second/third program code means"), which pre-figures the program-product format of claims 11/20 of the '833 patent.

'754 also supplies the initialization-time identification (relevant to claim 2): "when the operating system for a system 110 is initialized, a SETL CLEAR CCW is issued for each FBA device as it is attached to the system as part of the system initialization … the fields system identification … are all set." That is the controller learning which system is attached, at IPL, and creating the per-host record.

3.3 Motivation to combine, and reasonable expectation of success

The two references are in the same field, address the same problem (multiple independent computer systems sharing one storage device), and their combination uses each element for its known function:

• '125 supplies the why: heterogeneous hosts speak different disk-organization "dialects," so the controller (or its emulators) must translate per-host so all hosts transparently reach one copy of the data.
• '754 supplies the how to persist and locate that per-host association in the shared device itself, using per-host records placed on the device at (reserved) block locations and indexed by system identification.

A POSITA given '125's per-interface emulator architecture and asked where to keep the host↔DOM association (and how the controller identifies which translation to apply to an incoming request) would naturally look to '754, which the same assignee/industry already used to track per-host state on shared FBA DASD. Persisting metadata on the device is a predictable, beneficial design choice recognized in the art — it survives host reboots, is uniformly accessible to all hosts and to the controller, and mirrors how DASD control units already stored per-host lock/map records. There is no teaching away: '754 affirmatively teaches storing the per-host control file on the shared device, and '125 affirmatively teaches per-host translation at the controller.

Result: E1–E4 of claim 1 are disclosed or made obvious by '125 in view of '754. E3b ("determine the linear block addresses of the meta-data … and retrieve the meta-data from those addresses") is met by '754's creation/reading of the SDF lock file/map records containing system identification + starting block + extent. E4's "consonant with the operating system" and "transparent" are met by '125's DOM→DOM emulators disguised as local interfaces.

---

4. Alternative and secondary combinations (each independently supporting § 103)

Because the claims are functional and the elements are individually old, several alternative combinations reach the same result:

(a) Claim 1 over US 5,345,586 (IBM) in view of '125 or '754. '586 discloses a global data directory with an attribute table, a domain table, route table, and cross-reference table that store, per data entity, the physical data source, platform-level parameters, units/data-type per platform, and conversion routines, plus "a system contact for each platform … and the data source for that platform." This is a metadata/table mapping each source (host/platform) to the parameter set needed to access and convert the data — the substance of E2 and E4. Combined with a storage controller that receives requests (as in '125/'754), the mapping-table architecture supplies "create and store meta-data which associates each … system with [its] operating system" and "interpret … in a manner consonant with" the source.

(b) Claims 1/18 over US 5,214,768 / US 5,412,791 (E-Systems) in view of '754. These teach a directory archive that, on a host request, "locat[es] … the address containing the stored information and generat[es] a data address location output," with a control computer configuring the data channel between the requesting host and the recorder — i.e., request→identify→map-to-physical-address→access. '768/'791 also teach "hid[ing] not only the location of stored data … but also the type of medium," a transparency teaching. Combined with '754's on-device per-host records, they render E3/E4 obvious.

(c) The "offsetting" limitation of claims 18/19/20 over US 5,363,497 (IBM). '497 ("System for removing section of memory … in a manner indiscernible to both operating systems") teaches exactly the address-rebasing that claim 18 recites:

• at system initialization, a contiguous region of a shared physical resource is carved out for the second system ("removing … a contiguous area of storage of predetermined size … rendering said contiguous area unavailable to the storage manager of the first operating system");
• each system's view is rebased: "Each S/370 virtual operating system thinks its memory allocation starts at address 0," and the second OS "has exclusive control of the allocation of storage blocks of said removed portion"; and
• the whole arrangement is "in a manner indiscernible to both operating systems" — the transparency limitation.

The mechanism is literally offsetting a logical address by the amount of the reserved region to reach the true physical address, which is precisely claim 18's "offsetting a linear block address … as appropriate dependent upon … the amount and location of meta-data stored." A POSITA combining '497's initialization-time carve-out/rebasing with '754's on-device per-host metadata (or '125's per-host translation) would arrive at claim 18 as a predictable arithmetic consequence — reserving the low LBAs for metadata and adding the reserved-run length to each host's logical addresses. This is the paradigm of a design choice with a predictable, purely computational result.

(d) The "identify the requesting system" element over US 5,471,609 (IBM, "Method for identifying a system holding a Reserve"). On shared DASD it was known to identify which host holds state (a reserve) — cumulative evidence that "identify which of the heterogeneous computing systems … is making said request" (E3a) is a routine capability in a shared-storage control unit.

(e) The "query at initial program load" limitation (claim 2) over '754 + '497. '754 teaches per-host identification/record initialization "as part of the system initialization"; '497 teaches capturing/setting-up the shared resource at initialization. Independently, device discovery/enumeration at IPL (e.g., inquiry/configuration reads at device-attach) was a conventional storage-interconnect technique. Populating the controller's host/OS table at IPL is a design choice with no unexpected result.

---

5. The dependent claims and the "means-plus-function"/program-product claims

• Claim 3 (one metadata set per distinct OS, stored at the initial contiguous LBAs). '754 teaches per-shared-file control files created on the device at a reserved subdirectory location, and the art commonly reserves low-LBA regions for controller/OS structures. Placing metadata at "initial contiguous linear block addresses" is a predictable allocation choice; '497's contiguous-region carve-out supports reserving a leading region. Obvious over '754 (and/or '574 in view of '497).
• Claim 4 / 9 / 16 (mapping table: system → metadata region). '754's per-host map records, and '586's route/cross-reference tables keyed to source/platform, both teach a table mapping a system to the location of its data/metadata. Obvious.
• Claims 5/10/17 and 18/19/20 (offset as appropriate). Covered in § 4(c); '497 supplies the rebasing, and '754's starting-block/extent fields supply the "amount and location of meta-data stored." No specific offset values are claimed, so the specification's illustrative LBA arithmetic (e.g., 22→28) adds nothing patentable.
• Claim 6 (apparatus). "Means for …" elements are the structural counterparts of the method steps; under § 112 ¶ 6 the corresponding structure is a programmed storage controller. Where the method is obvious, the means-plus-function apparatus is obvious over the same references (In re Alappat / routine practice: apparatus claims reciting the same functions add nothing where the underlying functions are known).
• Claim 7/8/14/15. Same limitations as 2/3; obvious for the same reasons.
• Claims 11–13 and 20 (program product; recordable media, claims 12; transmission media, claim 13). "[I]nstruction means" plus "signal bearing means" is a conventional software-article format the art already used — US 5,564,019 ('754's sibling) claims the identical arrangement ("a computer usable medium having a computer readable program code means embodied in said medium…"). That a known method is embodied in known instruction means distributed on recordable media (floppies/CD-ROM) or transmission media (communication links) is a predictable implementation choice; the earlier summary correctly notes the specification itself lists these media as conventional, and claims 12/13 recite nothing more.
• Claims 8/15 and 9/16. Same as 3/4; obvious.

---

6. Anticipated counter-arguments and why they do not save the claims

1. "The specification says no solution existed." Not controlling. The references themselves ('125, '754) disclose the constituent elements; the inventor's characterization cannot narrow the art. In re GPAC Inc.; In re Sneed.
2. "'125 uses emulators, not stored metadata at LBAs." The combination does not require '125 alone; '754 expressly stores per-host records (system ID + starting block + extent) on the shared device, which the controller creates and reads. The combination is not a bodily incorporation of one into the other; it is the predictable use of '754's on-device per-host record to hold '125's per-host DOM association.
3. "Different problem (tape mass storage vs. disk)." '768/'791 concern tiered mass storage; but that argument does not defeat the '125 + '754 combination, both of which are disk/DASD references directly on the shared-DASD problem.
4. "Transparency is a patentable functional result." A result that is the inherent, disclosed function of the combination (hosts "disguised as the ordinary local interfaces" in '125; "indiscernible to both operating systems" in '497) carries no separate patentable weight. In re Merck / In re Keller: a party cannot show nonobviousness by attacking references individually where the ground of rejection is a combination.
5. Secondary considerations (Graham factor 4). The record here (per the earlier-generated sections) shows no litigation, no commercial-success or licensing evidence tied to these claims, and no industry praise specific to the claimed subject matter; the patent expired fee-related with no assertion activity found. Absent nexus-bearing evidence of nonobviousness, the objective-indicia prong does not rebut the prima facie case.

Contextual corroboration of the field's predictability: the '833 patent is itself cited as an "X" (particularly relevant) document in the international search report for WO 2001/042985 A3, "Sharing data between operating systems" (Storage Technology Corp.), where it is listed against that application's claims 1–21 (see the earlier litigation/prior-art sections). While that is a relevance finding about a later application and no ruling about the '833 patent, it reinforces that, by the late 1990s, the "store per-host metadata / translate per-host access in a shared storage controller" concept was established art around which later applicants had to navigate. (Note: the earlier summary flagged the ISR's "claims 1–21" as inconsistent with the '833 patent's 20 claims — an apparent error in the ISR document, and I do not treat it as substantive.)

---

7. Bottom line (claim-by-claim)

Concluding assessment. Independent claims 1/6/11 stand or fall on whether the combination of Newframe's per-host DOM translation (US 5,758,125) with IBM's on-device per-host metadata records (US 5,463,754) is within the ordinary creativity of a POSITA. Given the identity of field and problem, the complementary and predictable function of each element, and the absence of any teaching away, the combination renders them obvious under pre-AIA § 103(a) as construed in KSR. Independent claims 18/19/20 are additionally met by US 5,363,497's initialization-time, transparent address rebasing. The dependent claims recite nothing more than routine allocation, table, and media choices.

Confidence and limitations. High confidence as to the elements supplied by US 5,758,125, US 5,463,754 / US 5,564,019, US 5,363,497, US 5,345,586, and US 5,214,768 / US 5,412,791, for which I verified specification/claim text in this session. Lower confidence as to US 4,630,196, US 4,835,685, US 5,239,643, US 5,325,517, US 5,369,767, US 5,369,749, US 5,388,215, US 5,471,609, and US 5,625,841, which I did not retrieve in full; I use them only as cumulative/corroborating references and do not rest any independent claim's rejection primarily on them. A formal invalidity contention would require pin-citing each reference's column/line for every element and confirming its § 102 date.