US 5701432

I'll search for this specific patent number before summarizing.

US Patent 5,701,432 — Summary

Verification note on sources: My search tooling reached Google Patents, EveryPatent, and a USPTO PTAB document, but I could not directly query USPTO Patent Center or a CAFC docket system with it. The bibliographic data below comes from the authoritative full text provided and from Google Patents' record. I found no CAFC 2026 docket activity involving this patent; the only USPTO-adjacent hit was a document mentioning "US-5701432" as a prior-art citation in an unrelated ex parte proceeding, which is not litigation. See the uncertainty notes at the end.

Bibliographic data

Abstract (as issued)

A multi-threaded processing system has a cache commonly accessible to each thread. The cache has a plurality of entries for storing items, each entry identified by an entry number. The location of an item that includes a first key is determined by supplying the first key to a lockless-lookup engine, which provides a lookup output that is alternatively a lookup entry number or an indication that the item is not stored in the cache. The lookup entry number is alternatively a first or second entry number — the first pointing to an entry in which the item is stored, the second to an entry in which it is not. If the output is a lookup entry number, it is verified that the number is the first entry number by acquiring a mutual exclusion lock on the designated entry, reading the stored key from that entry, and comparing the first key with the stored key. If the keys match, the item has been located.

Plain-language overview of the independent claims

The patent is fundamentally about letting many threads read a shared cache concurrently while still serializing writes, by treating the fast lockless index as a "hint" that is always validated under a lock. Three independent claims are visible in the text.

Claim 1 (method). A method of locating an item in a shared multi-threaded cache:

1. Supply the item's key to a lockless-lookup engine.
2. Get back a lookup entry number.
3. Confirm the item is actually at that entry by (i) taking a mutual-exclusion lock covering at least that entry, (ii) reading the key stored there, and (iii) comparing the two keys. A match means the item is stored at that entry.

In short: query an unlocked index, then lock and verify — never trust the index alone.

Claim 2 (method, the "hint" framing). Same general flow, but expressly acknowledging that the returned lookup entry number may be a first entry number (item really is there) or a second entry number (item is not there). The claim is directed to verifying the number is the first entry number: lock the designated entry, read the stored key, compare, and report the lookup entry number as the first entry number only if the keys match. This is the broadest "validate the hint" claim, and dependent claims 3–9 hang off it.

Claim 10 (apparatus). The means-plus-function counterpart to claim 2 — means for supplying the key to the lockless-lookup engine, means for obtaining the lookup entry number, and means for verifying (lock-acquiring means, key-reading means, comparing means, and means for supplying the entry number as the first entry number only on a key match).

Dependent claims (for context)

• 3 / 11 — the lock covers only the designated entry (not the whole cache).
• 4 / 12 — on key mismatch, release the lock and repeat the lookup.
• 5 / 13 — on a reported miss, take the cache-wide lock (blocking inserts/deletes) and re-look-up to confirm the miss; item located if the second lookup returns the first entry number.
• 6 / 14 — if the confirmed second lookup is also a miss, write the key into a new cache entry and insert a new (key, entry-number) element into the lockless-lookup engine.
• 7 / 15 — the new entry is chosen by a modified LRU strategy: divide entries into sets, select a set (round-robin), pick the least-recently-used non-busy entry in that set, otherwise move to the next set.
• 8 — invoke a call-back function to flush the replaced entry's contents to main storage.
• 9 — the lockless-lookup engine is a lockless-lookup hash table.

Supporting disclosure worth noting: the lockless hash table is incorporated by reference from Tock et al., U.S. Ser. No. 08/543,215, filed 1995‑10‑13, "Efficient Hash Table For Use In Multi-Threaded Environments" (same assignee). The preferred embodiment is a fully associative directory name lookup cache on a Sun SPARC multiprocessor running Solaris, implemented in C++, with per-entry lock, last-access-time, reference-count, and call-back fields.

Uncertainty / caveats

• Claims 16–26 are not characterized above. The header states "Claims (26)," but the fetched text enumerates only claims 1–15. I do not have the remaining eleven claims and will not guess at them. Given the 1/2 and 10 pattern, additional independent claims (or their dependents) likely exist in that range, but I have no authoritative text for them.
• No CAFC 2026 docket entry found. Searches for 5701432 combined with CAFC/2026/litigation terms returned nothing on point. This is consistent with the patent having expired on 2015‑10‑13, but absence of a search hit is not proof that no such proceeding exists — I could not query PACER or the Federal Circuit's docket directly.
• Assignee chain: "Oracle America, Inc." as current assignee reflects a recorded merger/change-of-name, not a new purchase; the original assignee of record is Sun Microsystems, Inc.
• Publication/filing identifiers are reproduced verbatim from the source; I have not auto-corrected anything.

I'll search for litigation involving US patent 5701432 across patent litigation databases.

Let me dig deeper into litigation databases and the PTAB reference.

Let me run more targeted searches on litigation-specific sources.

Litigation Search — US Patent No. 5,701,432

Bottom line

I found no confirmed litigation — district court, ITC, or Federal Circuit — involving U.S. Patent No. 5,701,432. I cannot represent this as a verified nationwide negative, because I was unable to query the primary litigation databases directly (see Caveats below). What I can say is that on the searches actually run, no case asserting or challenging the '432 patent surfaced.

How to read the results I did get

The searches were dominated by a false-positive pattern that you should be aware of, because it is the main way a search for this number goes wrong: competitors, courts, and commentators routinely refer to asserted patents by their last three digits only ("the '432 patent"). Every substantive hit I retrieved using that shorthand concerned a different patent whose number happens to end in 432, including:

• USAA v. PNC Bank — the "’432 patent" there is USAA's mobile-deposit system patent (asserted in E.D. Tex. Case No. 2:20-cv-00319-JRG-RSP, and in BBVA counterclaims for declaratory judgment). That is not 5,701,432 — the claims are directed to mobile deposit with a "bank computer," not to multi-threaded cache coherency.
• ZS Pharma / AstraZeneca v. (ANDA defendants) — D. Del. complaint referencing a different '432 patent in a pharmaceutical ANDA context.
• O2 Micro, Bosch, Stratasys/Bambu, Cadence/Narwal — all involve other '432-suffixed patents, none of them 5,701,432.

I excluded all of these. They do not relate to US 5,701,432.

One unverified lead (not litigation)

One search result — a PTAB petition document hosted at ptacts.uspto.gov (petition reference #1557466) — contained the literal string "US-5701432-" in what appears to be a claim-chart or prior-art listing.

• This indicates the patent may have been cited as prior art in a PTAB proceeding, not asserted in litigation.
• I could not verify which proceeding, which petitioner, or which party cited it; my document-fetch attempts were cut off by a tool step limit.
• Treat this as a flag for further checking, not as a finding.

Why a negative result is plausible here

The patent's own record supports the absence of litigation:

• Priority/filing date: 1995-10-13.
• Anticipated expiration: 2015-10-13 (Google Patents legal status: "Expired – Lifetime").
• Original assignee: Sun Microsystems, Inc.; current assignee: Oracle America, Inc. (via the 2015-12-09 merger/name-change assignment).
• The disclosure is core Sun/Solaris operating-system infrastructure (directory name lookup cache, file attribute cache, disk buffer cache). Patents of this vintage on internal OS cache mechanics are not typical NPE assertion targets, and the ~2015 expiration forecloses most modern campaigns. The Oracle v. Google litigation (N.D. Cal. No. C 10-03561-WHA) asserted entirely different patents (the '104 and '520 patents) — not 5,701,432.

Requested table

Caveats you should weigh before relying on this

1. Sources not successfully queried. I was unable to reach the Unified Patents litigation portal (portal.unifiedpatents.com/litigation), Docket Alarm, CourtListener/RECAP, or PACER with a targeted query before hitting my search-step limit. A definitive negative should be confirmed against those sources plus the PTAB/Patent Center record for any IPR/PGR citing the patent.
2. Shorthand collision risk. Any search on "’432" will be polluted by the USAA, ZS Pharma, and other unrelated '432 patents identified above. Always search the full number 5,701,432 or 5701432.
3. Claim scope and expiration. Even if a case existed, a 2015 expiration means any infringement window is historical only.
4. Date inconsistency in my instructions. The system date and the date in your message differ (2026-09-30 vs. 2026-04-26). This does not affect the analysis, but I flag it so you can confirm the recency cut-off you want applied.

If you can authorize a direct query against PACER and the Unified Patents portal, I can convert this from "no case found" to a verified negative (or correct it) — and I would first chase the ptacts.uspto.gov petition artifact to determine whether 5,701,432 is merely cited prior art in some IPR.

I'll verify against the structured data and run web searches to check for any proceedings the ODP may not have indexed.

PTAB Proceedings — US 5,701,432

Patent: US 5,701,432 B1 — "Multi-threaded processing system having a cache that is commonly accessible to each thread"
Inventors: Thomas K. Wong; Theron D. Tock
Original assignee: Sun Microsystems, Inc. → Current assignee: Oracle America, Inc.
Filed: 1995-10-13 • Issued: 1997-12-23 • Anticipated expiration: 2015-10-13 (per Google Patents legal-status data)

---

Proceedings overview

Zero AIA trial proceedings are on file — the USPTO Open Data Portal returns no IPR, PGR, or CBM for US 5,701,432, and independent web searching surfaced no petition, institution decision, Final Written Decision, or Federal Circuit appeal involving this patent (0 active / 0 claims invalidated / 0 claims sustained / 0 settled / 0 institution denials), leaving a defendant facing assertion of the '432 patent with no PTAB record of any kind — but also with the far more decisive defense that the patent expired on 2015-10-13 and its entire claim set (claims 1–26 as issued, with 26 total claims) is therefore unenforceable for any prospective conduct.

I want to be explicit about the limits of what I can verify here: I did not find a single PTAB paper naming this patent as the challenged patent. The only PTAB-hosted document that references it at all (a petition exhibit at ptacts.uspto.gov/ptacts/public-informations/petitions/1557466/) lists US-5701432- inside a prior-art search-string log — i.e., the '432 patent was swept up as prior art against somebody else's later patent, which is the opposite of a challenge to it. I am flagging that artifact so it isn't mistaken for a proceeding; it is not one.

---

Proceedings on file

None. There is no proceeding to report at the level of detail the template requests (no proceeding number, petitioner, panel, grounds, institution decision, FWD, settlement, or appeal exists to describe). Per the operating instructions, I will not invent a docket number or panel to fill the schema.

Rather than leave that bare, here is the verified surrounding context a defendant actually needs:

Why there is no IPR — and why that absence is not "the patent is strong"

• PGR was never available. Post-grant review is limited to patents subject to the first-inventor-to-file provisions (effective filing date on or after 2016-03-16; statutory basis at 35 U.S.C. § 321 et seq.). This patent's priority date is 1995-10-13, so no PGR could ever have been filed.
• CBM was a non-starter and is now sunset. Covered Business Method review reached only patents claiming a financial product or service — this is a cache-coherence/operating-system patent, facially outside the CBM definition (35 U.S.C. § 18(d)(1)), and the CBM program expired for new petitions on 2020-09-16.
• IPR was technically available from 2012-09-16 but was commercially moot. The patent issued in 1997 and expired 2015-10-13. IPRs on expired patents are permitted, but the practical window was narrow (2012–2015) and the patent was a Sun/Oracle internal-OS patent rather than a licensing asset. The absence of IPRs here reflects low assertion value / an expired term, not a patent that was tested and survived. Do not let anyone tell you "no one ever beat it, so it must be good."

A sibling filing worth checking if a demand letter names a family: the specification incorporates by reference Tock et al., U.S. App. Ser. No. 08/543,215, filed 1995-10-13, "Efficient Hash Table For Use In Multi-Threaded Environments" (the lockless-lookup hash table used as the lookup engine here), and the Google Patents family listing shows a continuation of the '432 application, U.S. App. Ser. No. 08/773,258, which issued as US 5,909,695. I did not verify PTAB activity on either; if you are being asserted against the family, run those two numbers through PTAB E2E separately.

Link for independent verification: PTAB E2E / PTAB Center search — https://ptacts.uspto.gov/ptacts/public-informations (search by patent number 5701432).

---

Strategic summary

Claim status. Claims 1–26 issued on 1997-12-23 and were never narrowed, canceled, or amended in any AIA trial — there was no trial. So the technical answer to "which claims are canceled vs. sustained vs. untested" is: all 26 claims are untested; 0 are canceled; 0 are sustained. That distinction matters enormously. A defendant cannot point to a Final Written Decision canceling claim 1 or any dependent claim, because no such document exists. What a defendant can point to is the expiry date: the patent's term ended 2015-10-13, roughly eleven years before today (2026-09-30). Claims 1 and 10 (the two independent method/apparatus claims recited in the claim set) and everything depending from them are expired, and claim 18's article-of-manufacture claim likewise.

The real defense is § 286, not § 315(e)(2). Because no IPR, PGR, or CBM was ever instituted, no estoppel exists under 35 U.S.C. § 315(e)(2) or § 325(e)(2) — no petitioner and no privy is barred from anything. Practically, that cuts in the defendant's favor: there is no PTAB record to estop anyone, and a district-court or ITC invalidity case can use the full prior-art universe — patents, printed publications, public use, on-sale, and § 112 grounds — none of which are PTAB-limiting. But the stronger point is temporal: under 35 U.S.C. § 286, damages reach back only six years from the filing of the complaint, so a suit filed after 2021-10-13 cannot recover for any pre-expiration infringement at all. Any demand letter citing claims 1–26 to cover current products should be greeted with the expiry date and a § 286 / standing challenge, not with an IPR petition.

Pattern signals — none present. There is no repeat petitioner (there are no petitioners), no patent-owner appeal practice on this patent, and no defensive aggregator (Unified Patents or similar) in the chain. The patent's ownership history is corporate — Sun Microsystems → Oracle America, Inc. (merger/name change recorded 2015-12-09) — consistent with a portfolio patent that was never weaponized in AIA proceedings.

---

Recommended next steps

1. If you received a demand or complaint citing US 5,701,432: the dispositive fact is the anticipated expiration date of 2015-10-13 (Google Patents legal-status record, https://patents.google.com/patent/US5701432/en). Ask opposing counsel to identify the accused acts and the date range. If the accused acts post-date expiration, there is no infringement; if they pre-date it, run the § 286 six-year bar against the complaint's filing date.
2. Do not file an IPR. There is no § 315(b) one-year bar concern (no prior IPR), but there is also nothing to win — the patent is expired, and an IPR on an expired patent cannot yield the claim-cancellation leverage that makes IPRs worthwhile. Invalidity is better raised in the forum where the case already sits.
3. Verify the negative directly rather than relying on this memo. Since the ODP ingest showed no proceedings, confirm in PTAB E2E (https://ptacts.uspto.gov/ptacts/public-informations) by patent number, and separately search the family numbers US 5,909,695 (continuation) and the incorporated application 08/543,215 in case a plaintiff asserts the family rather than this patent alone.
4. If any proceeding surfaces that the ODP has not yet indexed: it would be pre-2016 given the expiry date, so expect an IPR filed 2012-09-16 through 2015; pull the FWD from the PTAB Decisions portal and check claim-by-claim, since I have no verified FWD to quote for this patent.

Confidence statement: I am highly confident there are no AIA trial proceedings on US 5,701,432 — the structured ODP block says so, and my searches (PTAB-hosted document indices, patent-family cross-references, and docket/opinion aggregators) surfaced nothing contradicting it. I cannot rule out a proceeding that is both unindexed in ODP and unindexed in general web sources, but that combination is very unlikely for an AIA trial paper, which is published as a matter of course. No proceeding numbers are reported here because none exist to report.

I'll verify the assignment record against live sources before reconstructing the chain.

Ownership Analysis — US 5,701,432

Patent: Multi-threaded processing system having a cache that is commonly accessible to each thread
App. No.: 08/543,105 · Filed: 1995-10-13 · Issued: 1997-12-23 · Priority: 1995-10-13
Current assignee of record (per Google Patents legal events): Oracle America, Inc.
Legal status: Expired – Lifetime (anticipated expiration 2015-10-13)

Source note / limitation up front. The authoritative record here is Google Patents' legal-events table for US 5,701,432, which is derived from the same USPTO assignment data as Assignment Center. That table exposes conveyance type, parties, and event dates, but not reel/frame or the correspondent of record. I was unable to retrieve the Assignment Center detail pages (the site is behind a session-based UI and my fetches returned no results). Accordingly, reel/frame numbers are stated only where I could corroborate them from a third source, and the correspondent fields are reported as "not retrievable" rather than guessed. No assignment has been invented in this report.

---

Inventors

• Both inventors' residential addresses sit in the Bay Area commuter radius of Sun's Palo Alto / Mountain View / Menlo Park campuses.
• The parallel European filing EP 0 768 608 A2 ("Maximal concurrent lookup cache for computing systems having a multi-threaded environment") lists the identical inventive entity — Wong, Thomas K. and Tock, Theron D. — with Sun Microsystems, Inc. as applicant, confirming both were Sun personnel at filing. The US case carries the same priority date (1995-10-13).
• No departure signal. Public inventor aggregators associate Thomas K. Wong with ~94 patents, the overwhelming majority Sun-assigned (e.g., US 5,812,998; US 5,922,049; US 5,909,695), and later EP 1 181 639 still showing Wong as inventor under Sun Microsystems Inc. That is a long-tenure signature, not a 12-month exit pattern. I found no evidence either inventor left Sun within 12 months of filing — treat any such claim as unsupported.
• Related sibling application 08/543,215 (Tock et al., "Efficient Hash Table For Use In Multi-Threaded Environments," filed the same day) is incorporated by reference into this patent and is listed in the spec as commonly assigned to Sun Microsystems.

---

Original assignee

Sun Microsystems, Inc. (Delaware; principal offices Palo Alto / Mountain View, California) — named as assignee on the face of the issued patent.

• Line of business: Enterprise computing — SPARC-based workstations and servers, the Solaris operating system, and Java. This was an operating company with a large shipping product line.
• Did Sun ship a product embodying the claims? Substantially yes, in the practical sense. The patent is an internal operating-system caching mechanism, not a saleable article. The spec states the preferred embodiment is implemented on a Sun workstation/server with multiple SPARC processing units under Solaris (Sun/Solaris are Sun trademarks, per the spec), and that C++ implementations of the get_cache_entry / delete_cache_entry routines run on a multi-CPU Sun SPARC machine. Solaris 2.x's directory name lookup cache — the exact application named in FIG. 3 of this patent — is the shipped embodiment. So the claims were practiced in Sun's own OS rather than licensed as a standalone product.
• Current status: Acquired. Oracle Corporation announced the acquisition of Sun on 2009-04-20 and closed it on 2010-01-27; the surviving US entity is Oracle America, Inc. Sun no longer exists as a separate registrant. Oracle America, Inc. is an operating company and remains the assignee of record.

---

Assignment timeline

The chain is short and, importantly, entirely intra-corporate. There is no third party anywhere in it.

• Executed on or before 1995-11-30 / recorded 1995-11-30 — Reel/Frame not retrievable from available sources

  • Conveyance: Assignment of Assignors' Interest (original assignment to the employer)
  • Assignor: Tock, Theron D.; Wong, Thomas K. (recorded in that order)
  • Assignee: Sun Microsystems, Inc.
  • Correspondent: Not retrievable. Assignment Center's correspondent field was not exposed in the sources I could reach; I will not name a firm I cannot cite.
  • Context: Ordinary employee-to-employer assignment of an invention made in the course of employment — the standard path for a corporate OS patent, not a sale.

• Executed 2010-02-12 (effective date) / recorded 2015-12-09 to 2015-12-16 — Reel/Frame 037303/0336 (see caveat)

  • Conveyance: Merger and Change of Name (not a sale, not an assignment for value)
  • Assignors of record: Oracle America, Inc.; Oracle USA, Inc.; Sun Microsystems, Inc.
  • Assignee: Oracle America, Inc. (California)
  • Correspondent: Not retrievable from the sources available to me.
  • Context: Internal corporate reorganization — the Sun→Oracle integration evidence recorded as a single blanket filing. Nothing left the Oracle/Sun corporate family.
  • ⚠ Reel/frame caveat: Google Patents' legal-events entry for this patent (2015-12-09, "MERGER AND CHANGE OF NAME") lists the same three entities but does not print the reel/frame. The reel/frame 037303/0336 with effective date 2010-02-12 and recording date 2015-12-16 is the Oracle merger record I could independently corroborate from INPADOC/Espacenet legal-status data — but on a different Sun-originated patent (US 7,409,710 B1), not on US 5,701,432. Oracle's Sun acquisition was recorded as a large blanket merger filing, so the same reel is highly likely to cover this patent, but treat 037303/0336 as probable, not confirmed for US 5,701,432. Verify on Assignment Center before relying on it.

• Terminal derivative (not an assignment of this patent): Continuation US 5,909,695 ("Maximal concurrent lookup cache…"), filed 1996-12-23 as app. 08/773,258, same inventors, same assignee. It appears in Google Patents' "priority to" list for the '432 family and should be tracked as a related asset under the same ownership chain — it does not add an assignment link to this patent.

No assignment records exist for this patent beyond these two events. There is no recorded sale, license, security interest, release, or correction. That itself is the finding.

---

Timeline diagram

timeline
    title Ownership of US 5701432
    1995 : Filed by Wong and Tock
         : Assigned to Sun Microsystems
    1996 : Continuation US5909695 filed
    1997 : Patent US5701432 issued
    2010 : Oracle closes Sun acquisition
    2015 : Sun merger recorded to Oracle America
         : Patent expires

---

NPE / troll-pattern signals

Aggregate: zero strong signals, zero weak signals, one "unclear" driven purely by a data-retrieval gap (correspondent fields), not by anything in the record.

---

Verdict

Insufficient data

Justification: the entire recorded chain comprises exactly two events — the 1995-11-30 employee assignment to Sun Microsystems, Inc. and the Sun→Oracle merger and change of name (Google Patents event 2015-12-09; reel/frame 037303/0336 corroborated via INPADOC on the companion Sun record), with no third-party transfer at any point. Under the rubric, "only the original assignment" plus an intra-corporate reorg means there is no NPE conduct to score — and none of the eight signals is present on the evidence. I am deliberately not calling this "operating-company assertion," because I found no litigation over this patent, and the patent expired 2015-10-13, which forecloses assertion entirely. This patent is a clean, non-asserted, operating-company OS patent that simply ran out its term.

Two items to close before this report is final:

1. Pull the correspondent of record for both the 1995 and 2015 recordings from Assignment Center — the only untested signal (#3).
2. Confirm whether reel 037303/0336 actually covers US 5,701,432 rather than relying on the corroborated sibling-patent record.

Verify at:

• USPTO Assignment Center — https://assignmentcenter.uspto.gov/ (search Patent No. 5701432)
• Legacy Assignment Search — https://assignment.uspto.gov/patent/index.html
• Google Patents legal events — https://patents.google.com/patent/US5701432/en
• Espacenet INPADOC legal status (merger reel corroboration) — https://worldwide.espacenet.com/patent/search?q=pn%3DUS5701432
• Continuation asset — https://patents.google.com/patent/US5909695/en

I'll research US patent 5701432 and its cited prior art.

Let me look for the cited references section specifically.

Let me look for the examiner-cited references in the patent's front page.

Summary of Search Results for US 5,701,432

Important caveat up front: The authoritative full text of US 5,701,432 that I was given (and the Google Patents rendering at https://patents.google.com/patent/US5701432/en) does not include a "References Cited" / "Patent Citations" table. My targeted searches for that list returned the citation tables of other patents (e.g., DE19983793B4 / US6349363 — an unrelated Intel/Compaq multi-threaded cache patent), and one search returned zero results. I therefore cannot give you a verified, verbatim list of the examiner-cited references for this patent, and I will not fabricate reference numbers, dates, or § 102 mappings. Below I separate what is verified from what is not.

---

1. Patent identification (verified)

The Google Patents "Prior art keywords" field lists only: entry, cache, lookup, key, entry number — indicating the examiner relied on keyword/classification searching, not a dense citation block.

---

2. Prior art that the patent itself identifies (verified from the specification)

This is the only prior-art material I can ground with certainty, because it appears in the body of the patent text you supplied:

(a) Tock et al., U.S. patent application Ser. No. 08/543,215, filed Oct. 13, 1995, entitled "Efficient Hash Table For Use In Multi-Threaded Environments," assigned to Sun Microsystems (same assignee), incorporated by reference in its entirety.

• Publication/filing date: filed 1995-10-13 — the same day as US 5,701,432's own filing.
• Description: The lockless-lookup hash table that serves as the "lockless-lookup engine" 217/303. The specification states it "requires serialization of only insertion and deletion operations, while permitting concurrent lookup operations to take place with the guarantee that no value will ever be returned that had not previously been written into the hash table."
• Claim relevance under § 102: Potentially relevant to the "lockless-lookup engine / lockless-lookup hash table" limitations of claims 1, 2, 9, 10, 17, 18, 19, and 26. However, this is a co-pending, same-assignee application, not classic prior art — it is more properly a § 102(e)/§ 103 or incorporation-by-reference issue, and because of the identical filing date it cannot be a § 102(a)/(b) reference.
• Family note (needs verification): The sibling patent US 5,909,695 describes Ser. No. 08/543,215 as "now abandoned." A granted patent, US 6,115,802, "Efficient hash table for use in multi-threaded environments." appears in the same family (I did not verify its exact filing/priority chain — treat as unconfirmed). The hash-table claims of US 6,115,802 (mutual-exclusion-lock verification of a "check entry") closely parallel the verification logic in US 5,701,432 claims 1/2.

(b) Non-patent literature incorporated by reference: A. Burns & G. Davis, Concurrent Programming, pp. 64-68, 175-184, Addison Wesley, 1993.

• Description: General background on mutual exclusion, semaphores, monitors, busy-wait loops, Test-and-Set, producer-consumer and reader-writer problems.
• Claim relevance: Background/obviousness context only. It discloses general locking, which is the problem the invention improves upon — it does not anticipate any of claims 1–26, since none of them discloses a lockless-lookup engine.

(c) Admitted prior art in the "Background" section (unnumbered): Conventional mutual-exclusion-lock caches, read-write locks, directly-mapped / fully-associative / set-associative cache paradigms, and the Solaris directory-name lookup cache, file attribute cache, and disk buffer cache. These are admissions about the state of the art but are not identified by any reference number.

---

3. Documents sometimes mistaken for prior art (they are NOT prior art)

• US 5,909,695 (Wong & Tock), "Maximal concurrent lookup cache for computing systems having a multi-threaded environment," filed 1996-12-23 as a continuation of US 08/543,105. Same inventors, same assignee — this is a child, not prior art.
• EP 0 768 608 A2/B1; DE 69625768 T2; CN 1087451 C; KR 970022764 A; JP H09204357 A; TW 324081 B — these are foreign counterparts of the same application (all claiming priority to US 08/543,105 / EP 96307364), not prior art.
• WO 2001038970 A3 merely lists US 5,701,432 in a "patent family member" table — it is a later document and has no § 102 effect.

---

4. What I could NOT verify

• The examiner-cited US patent references on the front page of US 5,701,432 (typically formatted as "References Cited / U.S. Patent Documents"). My searches did not surface this table, and the copy of the patent I was given omits it.
• Any foreign patent documents cited against it.
• The exact bibliographic chain of US 6,115,802.

Because the § 102 anticipation analysis you asked for requires the actual cited references, I cannot responsibly complete per-reference claim mapping without them. Any list I produced would be fabricated.

---

5. How to obtain the verified citation list

1. USPTO Patent Center / Patent Public Search (ppubs.uspto.gov) — open US 5,701,432, view the "References Cited" section of the front page and the "References Cited" tab.
2. USPTO PatentCenter "Application Data" — the file wrapper for application 08/543,105 contains the examiner's PTO-892 (Notice of References Cited) and any Office Actions, which list the references and the claims rejected over each.
3. EP Global Dossier / EPO Register for EP 96307364 (EP 0 768 608) — the European search report gives an independent assessment of the same subject matter with claim mapping.
4. Google Patents "Patent citations" tab at https://patents.google.com/patent/US5701432/en — the rendering I received did not include it, but the live page normally shows both patent and non-patent citations; the live page should be preferred over this cached dump.

---

6. Preliminary framework for the § 102 analysis once the list is obtained

For each candidate reference, test it against these independent-claim limitations:

• Claim 1 (method of locating an item): needs (a) supplying a first key to a lockless-lookup engine; (b) a lookup output that is a lookup entry number; (c) acquiring a mutual exclusion lock granting exclusive access at least to the entry designated by the lookup entry number, reading the stored key, and comparing. A reference that locks the whole cache for lookups, or that uses a locked/atomic hash table, does not anticipate claim 1.
• Claim 2 (adds the "hint" characterization: lookup entry number is alternatively a first entry number where the item is stored or a second entry number where it is not, and "supplying the lookup entry number as the first entry number only if the first key matches the stored key").
• Claim 5: on a miss, acquire a cache-wide mutual exclusion lock and perform a second lockless lookup.
• Claim 6: on a confirmed miss, store the key at a new entry and insert a new element into the lockless-lookup engine.
• Claims 7–8: modified LRU replacement over sets of entries, skipping busy sets; call-back flush.
• Claims 9 / 17: lockless-lookup engine is a lockless-lookup hash table.
• Claims 10–17, 18–26: apparatus and article-of-manufacture counterparts of the above.

The strongest conceivable anticipatory candidates are (i) the incorporated-by-reference Tock hash-table application (for the hash-table element only — but it is co-pending, same-day, and same-assignee, so it is not § 102(a)/(b) art), and (ii) whatever US patent references are listed on the front page — but those specific references remain unverified. If you can paste the front-page "References Cited" list (or the PTO-892), I will complete the full per-reference citation, date, description, and claim-by-claim § 102 mapping.

I'll research the prior art cited on this patent's face and in its family before analyzing.

Let me pin down the exact front-page references cited on the '432 patent.

I hit the search-tool step limit before I could finish verifying filing dates and the full citation list, so I'll flag what is and isn't verified. Here is the analysis.

---

Obviousness Analysis — US 5,701,432 under 35 U.S.C. § 103

0. Two handoff gaps I must flag before analyzing

A. The "Prior Art section of this page" was not in the material I received. The authoritative page text you supplied to me jumps from the image block → Classifications → Definitions → Description → Claims. It contains only the five auto-generated "Prior art keywords" (entry, cache, lookup, key, entry number), which are a Google Patents keyword extraction, not a citation list. There is no "References Cited," "Patent Citations," or "Non-Patent Citations" block in the text I was given. To do this task I therefore had to reconstruct the prior art of record from Google Patents / Justia / EveryPatent. Treat everything in §1 as reconstructed, not as the section you referenced. If a real Prior Art section exists in your source and differs from what I reconstructed, that section governs and this analysis must be re-run.

B. Date inconsistency. Your instruction says current date April 26, 2026; my system date is 2026-09-30. This is the same discrepancy the earlier litigation section flagged. It does not change the §103 analysis but it does affect any "as of today" recency statement.

Governing law. The application was filed 1995-10-13 and issued 1997-12-23 — both pre-2013-03-16. Pre-AIA 35 U.S.C. §§ 102/103 apply. Critically, pre-AIA §102(e) and pre-AIA §103(c) do a lot of work here (see §5).

Correction to the earlier sections. The earlier summary said claims 16–26 were uncharacterized. My searches recovered substantial text: claim 16 (apparatus-of-15, adds call-back flush), claim 17 (apparatus-of-10, lockless-lookup engine is a lockless-lookup hash table), claim 18 (independent, article-of-manufacture mirroring claim 1), claim 19 (independent, article-of-manufacture mirroring claim 2), claim 20 (apparatus... i.e. article-of-19, lock covers only the designated entry), claim 26 (article-of-19, lockless-lookup hash table). Claims 21–25 were still not retrieved; on the filing's internal pattern they are almost certainly the article-of-manufacture analogues of dependent claims 4–8 (release-and-repeat, second verification on miss, key-store-and-insert, modified LRU, call-back). Source: https://patents.justia.com/patent/[5701432](/patent/5701432) and http://www.everypatent.com/comp/pat5701432.html

---

1. The prior art of record (reconstructed)

1a. U.S. patents cited on the face of the '432

Sources: https://patents.justia.com/patent/5701432 (Referenced Cited list); https://patents.google.com/patent/[US5530958A](/patent/US5530958A)/en; https://patents.google.com/patent/US5535365; http://www.google.hu/patents/sitemap/en/Sitemap/G06/G06F/G06F_12_1414.html (listing both 5,530,958 and 5,530,834).

Date caveat (material). All three issued after the '432's 1995-10-13 filing date, so none is §102(a)/(b) art. Each can only be prior art under pre-AIA §102(e), which requires an effective U.S. filing date before 1995-10-13. I confirmed this for Agarwal: App. No. 08/363,542, filed 1994-12-23, continuation of Ser. No. 07/926,613 filed 1992-08-07 (source: PTAB artifact, https://ptacts.uspto.gov/ptacts/public-informations/petitions/[1531941](/patent/1531941)/...). I could not verify the filing dates of Colloff or Barriuso before hitting the step limit; both presumably filed 1993–1994, but I will not assert it.

1b. Non-patent literature and applicant admissions

• Burns & Davis, Concurrent Programming, Addison Wesley, 1993, pp. 64–68 (mutual exclusion) and 175–184 (Reader-Writer problems) — expressly incorporated by reference in the '432's own Background. Source: the patent text you supplied.
• Applicant-admitted prior art in the Background §2. The Background states that "the mutual exclusion lock used by a cache to maintain consistency may be replaced with a read-write lock," that "a read-write lock allows multiple concurrent cache lookups because these do not modify the contents of the cache," and that the residual problem is that a writer blocks all readers. This is a binding admission of the state of the art and supplies most of the motivation discussed below. Source: https://patents.google.com/patent/US5701432/en (Description, Background).

1c. The commonly-owned application — legally unavailable

The '432's specification incorporates by reference Tock et al., U.S. Ser. No. 08/543,215, filed 1995-10-13, "Efficient Hash Table For Use In Multi-Threaded Environments." That application issued as US 6,115,802 (App. No. 09/034,181, filed 1998-03-03). Source: https://companyprofiles.justatic.com/patent/[6115802](/patent/6115802) ; EP family cites it as "US-A-6115802" (https://patentimages.storage.googleapis.com/79/c4/0d/056169bac55e52/EP0768608B1.pdf).

This reference cannot be used in a §103 rejection against the '432. The '215 application and the '432 were filed on the same day (1995-10-13) and were both owned by Sun Microsystems (assignments recorded 1995-11-30 and 1995-12-23 respectively). The '215/'802 is therefore at best §102(e) art, and pre-AIA §103(c) disqualifies commonly-owned §102(e)/(f)/(g) art from use in an obviousness combination. Anyone building a §103 case on the '802 is building it on sand.

---

2. The claims to be tested

The independent claims are 1, 2, 10, 18, and 19. Claim 2 is the broadest framing and the best attack target: supply key → lockless-lookup engine → lookup entry number (which may point to an entry that does not hold the item) → verify by (i) acquiring a mutual exclusion lock granting exclusive access at least to that entry, (ii) reading the stored key, (iii) comparing, (iv) reporting the number as the first entry number only if the keys match. Claims 18/19 are the same subject matter as 1/2 in article-of-manufacture form; claim 10 is the means-plus-function mirror of claim 2.

The single novel kernel across all independents is: "treat an unlocked index lookup as a hint, then confirm it under an entry-scoped lock." Everything else is conventional cache machinery.

---

3. Grounds of obviousness

Ground 1 — Agarwal + Barriuso → claims 1, 2, 3, 10, 11, 18, 19, 20

• Agarwal supplies the index-to-location step. Its controller "indexes memory addresses to the cache data memory by applying at least one hashing function," and per-location "hash control data … direct[s] the cache system to a hashed location or a rehashed location," i.e. a hashed index is produced and then checked against a per-location control block before the data is trusted.
• Barriuso supplies the confirming step. It discloses reading a shared memory location and simultaneously determining that location's lock status in a single read operation, and it teaches that "the lock value must be a distinguished value, that is, a value which will never occur in normal operation." That is the same safety property the '432 demands of its lookup engine (never return an uninitialized entry number).
• Mapping. "Supplying the first key to a lockless-lookup engine" ← Agarwal's hash function applied to the lookup address/key. "Lookup entry number" ← Agarwal's hashed/rehashed index into the cache. "Acquiring a mutual exclusion lock that grants exclusive access at least to the entry designated by the lookup entry number" ← Barriuso's per-location lock. "Using the lookup entry number to read a stored key … comparing" ← Barriuso's combined read-and-lock plus Agarwal's control-block check. Claim 3 ("only to the entry") is squarely Barriuso's whole point — it locks individual shared memory locations, not the memory.
• Motivation. Both references are in the same field (multiprocessor memory subsystems), and the '432's own Background articulates the reason: a single cache-wide lock or a read-write lock lets one writer idle every reader, which "negatively affects the scalability of the system." A POSITA reading Agarwal's fast hash index and Barriuso's cheap per-location lock would predictably combine them to get concurrent reads with correct data. Under KSR, this is a combination of known elements with a predictable result.

Ground 2 — Ground 1 + Colloff → adds claims 4, 7, 12, 15 (and 24/25 if they are the LRU analogue)

Colloff's title is literally "Set-associative cache memory having an enhanced LRU replacement strategy." Claim 7/15 requires exactly two things Colloff supplies: (i) logically dividing the cache into sets, and (ii) picking the least recently used member as the replacement victim. The claim's extra filter — "not busy" — is supplied by Barriuso's lock/busy indication and by the general convention of pinning/reference-counting cache entries. Motivation: LRU replacement for a set-associative cache was a standard, well-understood design choice with a predictable benefit (higher hit ratio), and Colloff was cited on the face of the '432 precisely because it is that art.

Ground 3 — Grounds 1–2 + applicant admissions → adds claims 5, 6, 13, 14

Claim 5/13 (on a reported miss, take the cache-wide lock, re-look-up, and only then conclude "not present") is the classic double-checked locking / retry-on-miss pattern. It is also structurally anticipated by Agarwal's own hash-then-rehash retry on a first miss. Claim 6/14 (on a confirmed miss, store the key in a new entry and insert a new element into the index) is the ordinary cache-miss-fill path that any cache designer would add to Agarwal+Barriuso once the miss is confirmed; the Background already treats "cache miss → fetch from the larger collection of data → store it" as the definitional cache behavior.

Ground 4 — the "lockless-lookup hash table" limitation (claims 9, 17, 26) — weak

This is the hardest limitation. It would have to rest on general hashing art (Knuth, TAOCP Vol. 3, 1973/1972 — cited in the sibling '802) plus the §1c material as background-knowledge evidence only. Note that the '802 itself says: "Values obtained from such a hash table could be regarded as 'hints' that the user thread may be able to productively utilize. … The advantage of this approach is the elimination of locks." That is strong evidence of what the art knew — but because of §103(c) it can only be used to describe the knowledge of a POSITA, not as an element in a §103 combination. A rejection that leans on it as the missing element is vulnerable.

Ground 5 — useful non-patent candidates I could not verify in budget

I would want to check, but did not retrieve or verify: Agarwal & Pudar, "Column-Associative Caches," ISCA 1993 (a §102(b) statutory-bar candidate — published >1 year pre-filing; the reference list at https://dl.acm.org/doi/pdf/10.1145/[3613424](/patent/3613424).[3614295](/patent/3614295) confirms the paper exists); Mellor-Crummey & Scott, "Algorithms for Scalable Synchronization on Shared-Memory Multiprocessors," ACM TOCS 1991; and Herlihy's optimistic/lock-free object methodology papers. Any of these could carry the "hint-then-validate" kernel as known technique, which is exactly what Grounds 1–3 are missing. I am flagging them as leads, not as findings.

---

4. Why a POSITA would combine — the articulated reasoning

The strongest motivation is not in the references; it is in the patent's own Background, which is applicant-admitted prior art:

1. Shared caches in multithreaded systems are conventionally serialized.
2. A single cache lock is cheap but destroys scalability.
3. The obvious fix — a read-write lock — still lets one writer block every reader (admitted).
4. Lookups "occur much more frequently than insertions and deletions" (admitted).
5. Fine-grained, per-location locks give "more concurrent accesses" (admitted for directly-mapped and set-associative caches).

Steps 1–5 are a roadmap that terminates one short step from the invention: shrink the lock to the entry (Barriuso), let the index be read without a lock (Agarwal), and confirm the index result after taking the lock. Under KSR, an explicit teaching, suggestion, or motivation is not required where the combination is "the product of ordinary creativity." The Background supplies it anyway.

---

5. Weaknesses in these grounds (I would not call the claims obvious on this record)

1. The core limitation is missing from all three references. None of Colloff, Agarwal or Barriuso discloses a separate key→entry-number lookup engine, and none discloses accepting a knowingly-inexact index result as a "hint." Agarwal's hash index is not a hint engine; its rehash block assumes the index is the answer and merely records which hash was used. The "hint" concept is the inventive kernel, and the art of record does not contain it.
2. The examiner already considered these exact three references. They appear on the face of the issued patent, and the claims issued anyway in 1997. That is not binding, but it is evidence that the office did not view them as teaching the lockless-lookup-plus-verification architecture.
3. Claim 2's verify-then-report structure is narrower than a generic "lock and read." It requires conditional reporting ("supplying the lookup entry number as the first entry number only if the first key matches") and, by claim 4/12, a retry loop on mismatch. Barriuso's spin-wait is a loop, but on a lock, not on a key mismatch.
4. The best supporting art is legally walled off. The '215/'802 (same inventors, same assignee, same filing day) is exactly the reference that discloses the lockless-lookup hash table and the "hints" philosophy — and pre-AIA §103(c) makes it unusable in a §103 combination. A challenger must find a third-party or public source for that teaching.
5. Objective indicia cut the other way, weakly. The '432 asserts "substantial throughput improvements" and better scalability. That is the predictable consequence of removing a lock, so it is unlikely to rebut prima facie obviousness — but there is no litigation record (per the earlier section) in which anyone ever tested it.

Bottom line. The prior art actually cited on the face of the '432 supports, at most, a partial obviousness case for the peripheral dependent claims — the LRU/set-selection claims (7, 15, and presumably 24–25) via Colloff, and the miss-handling claims (5, 6, 13, 14) via Agarwal's rehash retry plus double-checked locking. For the independent claims 1, 2, 10, 18 and 19 — the lockless-hint-then-validate architecture — the record art does not, in my assessment, render the subject matter obvious, because the "hint" limitation is absent from Colloff, Agarwal and Barriuso and the one reference that does disclose it (§1c) is disqualified under §103(c).

---

6. Cross-reference note for the PTAB artifact

The earlier litigation section flagged a ptacts.uspto.gov petition (ref. #1557466) containing the string US-5701432-. From my searches, that occurrence is inside a patent-search log table — columns Ref # | Hits | Search Query | DBs | Default Operator | Plurals | Time Stamp — in which the '432 appears as one of six document numbers in an OR-ed string alongside US 6,938,130, US 6,263,407, US 6,625,694, US 5,428,761 and US 6,658,536, run against US-PGPUB. That is consistent with the '432 being swept up in a search report, not asserted or relied on as a ground. It does not change the §103 analysis, and I still cannot confirm which proceeding or party the report belongs to.

---

7. Caveats

• Filing dates of US 5,530,834 and US 5,535,365 are unverified. Their §102(e) status (and therefore their entire availability as §103 art) is an assumption, not a finding.
• I did not obtain the file wrapper. I do not know whether any of these three references was actually applied in a rejection, or whether they were merely listed in an IDS. Do not describe them as "applied by the examiner."
• The references I actually retrieved are the Google Patents/Justia/EveryPatent abstracts and claim text, not full certified copies. Where I quote Agarwal and Barriuso, I am quoting the Google Patents machine summary and the patents' own passages surfaced in search, not a citation-checked ORIGINAL.
• Ground 5 candidates (Agarwal & Pudar 1993; Mellor-Crummey & Scott 1991; Herlihy) are unretrieved leads. Verify before relying on any of them.
• "Prior art keywords" on the page are machine-generated and carry no evidentiary weight; do not cite them as prior art.