US 5481706

I'll search for authoritative information on this patent, including any 2026 CAFC docket activity.

Let me dig deeper into the IPR reference and any 2026 litigation activity.

Let me verify the patent's legal status and check specifically for any 2026 docket references.

Analysis of US Patent No. 5,481,706

Important caveat up front: I could not verify any CAFC 2026 docket entry specifically naming U.S. Patent No. 5,481,706. My searches returned no Federal Circuit appeal in 2026 involving this patent number, and this is consistent with the record showing the patent long since expired. I flag this as a negative finding, not a guarantee — I don't have a paid, exhaustive docket database.

---

1. Bibliographic Data (from the patent front page / Google Patents record)

2. Abstract (verbatim)

"Libraries for use in a multithreaded computer environment which must be thread-safe and cannot be recoded are identified. Such libraries, after identification, are repackaged. Export routines for such libraries will thereby acquire a front end which effects several steps. First a write-exclusive lock for a particular called function of one of the libraries is generically acquired. A call is then made to the underlying function whose name has been remapped. Upon return from the real routine, the write-exclusive lock is unlocked and a return to the user is executed. The system and method ensure correct functioning and integrity of the identified library functions accessible by multiple threads, as well as providing for creation of multithread-safe shared libraries without necessitating extensive library source modifications."

3. Plain-Language Overview

The problem: In a multithreaded (and/or multiprocessor) system, multiple threads can call functions in a shared library simultaneously. Because such functions often use a single global data area (the patent's example is printf, and also malloc), concurrent calls corrupt that data. Prior fixes either required rewriting library source (impractical for 70+ libraries, some >1 MB) or documenting which libraries were unsafe.

The invention: Rather than touching the library's internal code, the invention "wraps" each exported function at its entry/exit points. Specifically:

1. Extract the library's export list (ASCII list of exported symbols, e.g., lib.exp).
2. Save off the original function descriptor for each function.
3. Generate a wrapper for each function that (a) acquires a global lock, (b) calls the original (renamed) routine, (c) releases the lock on return.
4. Create a modified function descriptor whose entry-point pointer points to the wrapper's entry point (the copy of the original descriptor is embedded inside the wrapper, still pointing at the real code).
5. Modify the Table of Contents (TOC) so a call to the function name now resolves to the modified descriptor → wrapper → original code.

The same global lock is used for all wrappers, giving coarse (possibly over-serialized) but safe operation. The real routine code is never modified; the change lives "around" the library. The patent acknowledges this increases path length but achieves thread-safety without source changes.

4. Independent Claims in Plain Language

The patent has 6 claims total, with three independent claims: 1, 4, and 6 (claims 2, 3 depend from 1; claim 5 depends from 4).

Claim 1 — Method of making a pre-existing shared library thread-safe (apparatus/method for creation):
Given a pre-existing shared library with a pre-existing function descriptor, a pointer to it, and a non-thread-safe exported function:

• Create a wrapper (code surrounding the underlying call) that stores the pre-existing function descriptor inside it and creates a lock for the function; and
• Rebind the library with the wrapper by creating a modified function descriptor that (i) contains a pointer to the wrapper and (ii) is a copy of the original descriptor in which the wrapper pointer is substituted for the original pointer to the function; and
• Substitute the pointer to the modified descriptor for the original pointer to the function descriptor.

Claim 4 — Method of using/modifying a multithread library system at call time:
Given a library where a function call invokes a descriptor pointer, which invokes a routine pointer:

• Provide a wrapper including a lock and including the function descriptor;
• Provide a substitute function descriptor pointing to the wrapper;
• Change the pointer from the original descriptor to the substitute descriptor;
• Invoke the substitute-descriptor pointer → invoke the wrapper pointer → execute the wrapper, running the routine sequentially through the substitute descriptor and then the wrapper;
• Execute a lock on the routine; invoke the wrapper's embedded descriptor pointer to run the routine; and unlock on return.

Claim 6 — System (apparatus) counterpart to Claim 1:
"Means for" (means-plus-function) recitations mirroring Claim 1: means for creating a wrapper that stores the pre-existing descriptor and creates a lock; means for rebinding the library with a modified descriptor pointing to the wrapper; and means for substituting the new pointer for the old one.

Dependent claims: Claim 2 (calling the function before/after rebinding invokes the original vs. modified descriptor pointer respectively); Claim 3 (the function descriptor includes a pointer to the corresponding routine); Claim 5 (the lock/unlock precludes/permits execution of the routine from a subsequent function call from another thread while the routine is executing).

5. Family / Related-Matter Note

• The patent has a single US family member (application 08/143,586) and one publication (US5481706A); no foreign family applications are listed.
• U.S. Patent 5,481,706 is itself cited as prior art by later "shared library / user-mode critical system elements" patents, notably the VirtaMove/Trigence family (US 7,784,058 B2, "Computing system having user mode critical system elements as shared libraries," Rochette et al.) and US 2005/0066303 A1.
• Caution on a possible point of confusion: I found that US 5,481,706 appears as Petitioner Exhibit 1010 in PTAB IPR2025-00853, Microsoft Corp. v. VirtaMove, Corp. (filed Apr. 18, 2025; terminated/settled Sept. 5, 2025). In that IPR the challenged patent is US 7,784,058, not US 5,481,706 — the '706 patent was being used as a prior-art/background exhibit. So that 2025 PTAB matter is not an IPR against 5,481,706.

6. 2026 CAFC / USPTO Docket Finding

• No CAFC 2026 docket activity naming US 5,481,706 was found in my searches. Any 2026 "5481706"-style hits I did retrieve were false-positive matches to unrelated identifiers (e.g., the Japanese patent JP 5481706 for a "Weight Scale"/body-composition device, and an unrelated Lithuanian registry notice number), not the US patent.
• This is consistent with the patent's record status: Expired – Fee Related, with an anticipated expiration of 2013-11-01 (20 years from the 1993-11-01 priority). An expired, fee-lapsed patent would not normally be an active 2026 infringement/CAFC subject.

Uncertainty statement: I did not have direct, authoritative access to USPTO Patent Center/Public PAIR or a paid CAFC docket service in this session. My "no 2026 CAFC docket for 5481706" conclusion is based on web searches returning no such case; if you need a definitive negative, it should be confirmed against the CAFC docket and USPTO Patent Center directly.

Sources: Google Patents page for US5481706A (patents.google.com/patent/US5481706A/en); USPTO patent PDF (patentimages.storage.googleapis.com/.../US5481706.pdf); PTAB IPR2025-00853 records (Microsoft Corp. v. VirtaMove, Corp., Exhibit 1010 = US 5,481,706; challenged patent US 7,784,058).

I'll research litigation involving US patent 5481706.

Initial searches returned only unrelated hits (a Japanese patent JP5481706, an SEC filing ID, an Idaho statute § 48-1706, etc.). Let me search litigation-specific sources.

A key lead: US 5,481,706 appears as Exhibit 1010 in PTAB proceeding IPR2025-00853 ([Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.) as petitioner). Let me dig into that and search for any district court assertions.

Findings: Litigation involving U.S. Patent No. 5,481,706

Bottom line

I found no district court or appellate litigation in which U.S. Patent No. 5,481,706 was asserted as the patent-in-suit. No plaintiff(s), defendant(s), jurisdiction, case number, filing date, or outcome can be reported for such a case, because no such case surfaced in my searches.

About the patent

• Patent: U.S. 5,481,706 — "System and method for creating thread-safe shared libraries"
• Inventor: Jeffrey S. Peek
• Assignee: International Business Machines Corporation
• Filing/priority date: 1993-11-01; Grant date: 1996-01-02
• Legal status (per Google Patents): Expired – Fee Related; anticipated expiration 2013-11-01
• Source: https://patents.google.com/patent/US5481706/en

The patent's term ended in 2013, so it has been unenforceable for roughly a decade, which is consistent with the absence of any infringement action.

One closely related PTAB proceeding (not an assertion of the '706 patent)

The only substantive hit tying this patent number to a contested adversarial proceeding is a PTAB inter partes review in which the '706 patent was used as prior art, not as the challenged patent:

• Proceeding: IPR2025-00853
• Petitioner: Microsoft Corp.
• Patent Owner: VirtaMove, Corp.
• Patent challenged: U.S. 7,784,058
• Filed: April 18, 2025
• Status: Terminated – Settled (Sept. 5, 2025)
• Where '706 appears: as Petitioner Exhibit 1010, U.S. Patent No. 5,481,706 (a prior-art exhibit relied on in the petition)
• Source: https://www.docketalarm.com/cases/PTAB/IPR2025-00853/Microsoft_Corp._v._VirtaMove_Corp/

The parallel (and underlying) district court case is:

• VirtaMove, Corp. v. Microsoft Corp., No. 7:24-cv-00338-ADA (W.D. Tex.) — this is litigation over the '058 patent, not the '706 patent. The '058 patent was asserted by VirtaMove against Microsoft; the '706 patent was merely cited by Microsoft as prior art.

Important caveats

1. Direct-source verification was limited. I was unable to query the Unified Patents litigation portal (portal.unifiedpatents.com/litigation/caselist), PACER, or the CAFC docket directly through my available tools. My conclusions rest on general web searches rather than exhaustive litigation-database queries.
2. Do not confuse similar identifiers. My searches returned numerous unrelated matches that share the digits "5481706," including:
   • JP5481706B2 — a Japanese patent (Tanita Corp., "体重計"/body-weight scale) — a different patent entirely.
   • SEC EDGAR accession/link ID 5481706 (a Form 485APOS filing).
   • Idaho Code § 48-1706 (bad-faith patent assertion statute, cited in Micron v. Netlist briefing).
     None of these relate to U.S. 5,481,706.
3. The '706 patent is listed in Google Patents as having 78 citing documents and being cited by 151 later patents — these are citations, not litigation.

Recommendation

To confirm the negative result with authoritative sources, a targeted check of PACER's civil case index (searchable by patent number) and the Unified Patents litigation portal for "5,481,706" would be the appropriate next step. Based on everything I found, however, the correct answer at this time is: no known litigation in which U.S. Patent No. 5,481,706 was asserted as a patent-in-suit. The only adversarial proceeding tied to this number is IPR2025-00853, in which the '706 patent served as prior art against VirtaMove's '058 patent.

I'll start by verifying the canonical list against live sources.

Let me run a few more targeted searches to confirm there's no PTAB activity.

No PTAB activity surfaced. Let me do one final confirmation pass targeting litigation and post-grant databases.

Proceedings overview

Total AIA trial proceedings on file for US 5,481,706: 0. The structured "PTAB proceedings on file" block — sourced from the USPTO Open Data Portal — returns no IPR, PGR, or CBM proceedings, and my independent web searches (Google Patents, PTAB-related dockets, general assertion/litigation searches) surfaced no petitions, no PTAB decisions, and no Federal Circuit appeals tied to this patent number. There are therefore no proceedings to break down by active / invalidated / sustained / settled / institution-denied — every one of those buckets is empty. The bottom-line defensive posture is stronger than "survived two IPRs": US 5,481,706 expired on 2013-11-01 for failure to pay maintenance fees ("Expired - Fee Related"), so the patent is dead as a matter of record and cannot be asserted for any post-expiration conduct. An IPR-based defense is moot — you cannot invalidate claims in a patent that is no longer enforceable. The only residual exposure would be a pre-2013-11-01 damages theory within the § 286 six-year lookback, and any such theory is now time-barred as of 2019-11-01.

(No per-proceeding sections are included below because no proceedings exist — inventing proceeding numbers would be fabrication.)

---

Strategic summary

Claim status. US 5,481,706 issued 1996-01-02 with six claims (claims 1–6). None of those claims have been canceled by the PTAB, because no AIA trial was ever instituted. Claims 1–3 and 6 are the method/system claims directed to creating a wrapper around an exported, non-thread-safe shared-library function, storing the pre-existing function descriptor inside the wrapper, creating a modified function descriptor pointing to the wrapper, and substituting the table-of-contents pointer to the modified descriptor. Claims 4–5 are directed to the runtime side — the wrapper acquiring a lock on the routine, invoking the routine via the descriptor copy, and unlocking on return. All six claims are technically "untested" at the PTAB, but the more important classification is expired-unenforceable. There has been no narrowing, and equally, there is nothing left to narrow: the statutory term ran out on 2013-11-01 because maintenance fees were not paid. See the Google Patents legal-status record: https://patents.google.com/patent/US5481706/en.

Estoppel landscape. § 315(e)(2) estoppel is not applicable to anyone, because no petitioner ever filed, was instituted, and obtained a final written decision. There is no petitioner-side estoppel and no patent-owner-side IPR history. For a defendant currently facing a demand letter citing this patent, the practical defenses are not prior-art based at all: (1) expiration — the patent lapsed for non-payment on 2013-11-01; (2) § 286 time bar — the last date on which pre-expiration infringement damages could have accrued was 2013-11-01, and the six-year lookback window closed 2019-11-01; (3) absolute intervening rights / no ongoing royalty base for any product shipped after expiration. Prior-art invalidity under § 102/§ 103 remains available as a defensive theory, but it is low-value relative to the expiration point and would be litigated in district court, not the PTAB.

Pattern signals. There is no pattern to report. No repeat-petitioner activity (no petitioner exists), no patent-owner PTAB appeal strategy (no FWD to appeal), and no defensive aggregator such as Unified Patents in the chain — I found no evidence of any third-party challenge of any kind. The absence of PTAB activity is itself the signal here, and it points in the defendant's favor: this patent was filed in the pre-AIA era (1993), granted in early 1996, had a 2013 expiry date, and was never asserted aggressively enough during its enforceable life to attract an IPR. AIA trials were only available from 2012-09-16 onward (see the AIA effective-date discussion in the Solicitor General's briefing at https://www.justice.gov/osg/media/[1050596](/patent/1050596)/dl), leaving roughly fourteen months of enforceable term during which an IPR could even have been filed — a window too short for most challengers to justify the cost.

---

Recommended next steps

• If you are a defendant receiving an assertion letter on US 5,481,706: the dispositive response is expiration, not invalidity. Confirm the lapsed-maintenance-fee status directly on the face of the Google Patents legal-status record (https://patents.google.com/patent/US5481706/en — "Expired - Fee Related," anticipated expiration 2013-11-01) and, authoritatively, in USPTO Patent Center / the fee-history record for application 08/143,586. Any infringement theory premised on post-2013-11-01 conduct is meritless.
• If the assertion threatens suit over conduct within 2007–2013: the § 286 six-year damages lookback has been closed since 2019-11-01, so even that residual theory is time-barred. Request the patent owner's damages model in writing and demand the specific pre-2019 accrual dates.
• No active proceedings are pending, so there are no trial-stage milestones to track (no institution deadline, no oral hearing, no statutory one-year FWD due date). Nothing is live at the PTAB.
• Caution on scope of this conclusion: I found no PTAB activity on this patent, but my searches were web-based and the ODP API is the canonical source. If you need a belt-and-suspenders confirmation for litigation, pull the PTAB E2E docket (https://ptacts.uspto.gov/) by patent number and confirm zero results, and separately confirm the maintenance-fee lapse via the USPTO fee record — do not rely on this memo alone for a filed pleading.

Confidence note: I am highly confident there are no AIA trial proceedings on US 5,481,706, and highly confident the patent is recorded as expired for non-payment of maintenance fees. I could not independently confirm whether any pre-AIA ex parte/inter partes reexamination was ever requested, since that is not within the AIA trial data set — that is the one channel worth a direct Patent Center check if it matters to your matter.

I'll start by verifying the assignment record through available sources before reconstructing the chain.

Let me probe the assignment databases directly for any post-issuance records.

Assignment Record Reconstruction — US 5,481,706

Patent: US 5,481,706 A — "System and Method for Creating Thread-Safe Shared Libraries"
Application: US 08/143,586 · Filed: 1993-11-01 · Issued: 1996-01-02 · Assignee of record: International Business Machines Corp.
Status: Expired – Fee Related (anticipated expiration 2013-11-01)

Verification note / limitation. The USPTO Patent Assignment Search is a JavaScript-driven query interface that could not be executed directly from this environment. I reconstructed the chain from the authoritative full text (Google Patents, which mirrors the front-page assignment data and the legal-events feed) plus web cross-checks. No post-issuance assignment record and no reel/frame for any transfer were surfaced by any source reachable here. Reel/frame for the original assignment is also not exposed in the sources available (the front page shows only "ASSIGNMENT OF ASSIGNEE INTEREST (SEE DOCUMENT FOR DETAILS)"). Verify the negative result at the Assignment Center: https://assignmentcenter.uspto.gov/ and https://assignment.uspto.gov/patent/index.html (search 5481706).

Inventors

• Jeffrey S. Peek — sole named inventor. Employer at time of filing: International Business Machines Corporation (IBM). The inventor executed an assignment of interest to IBM on the filing date itself (1993-11-01), which is the standard "hired-to-invent" capture and establishes IBM as the original assignee from the outset.
• Unusual-pattern check: No evidence of inventor departure windows, co-inventor split-outs, or subsequent inventor-side assignments. Nothing indicative of a pre-fire-sale break-up. The application was filed directly by IBM with a same-day assignment, consistent with captive corporate R&D — not with an inventory being assembled for later sale.

Original assignee

• International Business Machines Corporation (IBM), Armonk, New York (New York corporation).
• Primary line of business: enterprise computing — hardware, system software, middleware, and services. The patent's own specification is grounded in IBM's product line: it references AIX version 3.2, the Distributed Computing Environment (DCE) process-model transition, and "in excess of 70 libraries" shipped with AIX (see Background of the Invention). This is a systems-software utility patent, not a standalone product.
• Did they ship a product embodying the claims? Yes — the disclosed technique (wrapper-based serialization of shared-library exports) was directed squarely at making the AIX shared libraries thread-safe for the multithreaded/DCE-era releases. The claimed wrapper/descriptor mechanism is an implementation detail of that library stack. IBM was a large-entity owner (the maintenance-fee records are tagged "LARGE ENTITY").
• Current status: Operating. IBM remains an active, publicly traded operating company (NYSE: IBM). There is no bankruptcy, dissolution, or divestment-of-portfolio event implicated by this patent.

Assignment timeline

Chronological list of every recorded assignment disclosed by the available sources:

• 1993-11-01 (executed) / recorded at filing, 1993-11-01 — Reel/Frame not exposed in available sources (Google Patents front page records it only as "ASSIGNMENT OF ASSIGNEE INTEREST (SEE DOCUMENT FOR DETAILS)")
  • Conveyance: Assignment of assignee interest (inventor-to-employer)
  • Assignor: Jeffrey S. Peek
  • Assignee: International Business Machines Corporation
  • Correspondent: Not surfaced in the sources reachable here (IBM-internal IP law department is the likely filer; unconfirmed — do not rely on this).
  • Context: Standard inventor-to-employer assignment executed on the filing date; not an acquisition, not a reorg, not a transfer to an asserter.

No post-issuance assignment records were found. Google Patents' legal-events feed for this patent shows only prosecution/grant and maintenance-fee activity — e.g. maintenance-fee payment and reminder events, and the "Expired – Fee Related" terminal status — with no assignments, security agreements, mergers, name changes, or releases after grant. Per the governing rule for such patents, this usually means the original assignee (IBM) retained ownership for the life of the patent. That is the finding here.

Timeline diagram

timeline
    title Ownership of US 5481706
    1993 : Filed by inventor Peek
         : Assigned same day to IBM
    1996 : Patent issued to IBM
    2013 : Term ends
         : Status Expired Fee Related

NPE / troll-pattern signals

All eight signals are assessed against the record above. Because there is no post-issuance transfer, no asserter, and no litigation artifact in the record, every signal resolves to not present — except where the record is simply silent, which I mark unclear rather than inventing a call.

1. Shell-entity transfer — Not present. No assignment out of IBM to any "IP / Patents / Licensing / Holdings / Ventures" entity. The only recorded link is the 1993 inventor→IBM assignment. No single-purpose LLC appears anywhere in the chain.
2. Known asserter in the chain — Not present. No assignee matches any NPE list (Acacia, Marathon, IV, IPNav, Wi-LAN/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, DGC, Spangenberg entities, etc.). The chain terminates at IBM, an operating company.
3. Repeat correspondent across the chain — Not present / unclear. No correspondent is exposed on the sole recorded link, and there is no multi-link chain in which a repeat filer could recur. (If a reel/frame is pulled from the Assignment Center, the correspondent on the original IBM filing should be captured, but with a one-link chain this signal cannot mature.)
4. Cascading transfers — Not present. Zero consecutive transfers; no set of chained LLCs within any time window.
5. Pre-litigation transfer — Not present. No assignment precedes any infringement suit, because no suit and no pre-suit transfer exist in the record. This patent is a 1990s IBM systems patent that does not appear in any assertion campaign surfaced by the searches.
6. Bankruptcy fire-sale — Not present. IBM did not file Chapter 7/11, and no assignment out of IBM is recorded. Not comparable to Kodak/Nortel/Polaroid fact patterns.
7. Privateering — Not present. No transfer from IBM to an NPE asserting on IBM's behalf; IBM's own licensing operation (if any) is not an NPE-on-competitors arrangement.
8. Defensive aggregator (anti-NPE) — Not present. Chain does not terminate at RPX, AST, LOT, Unified Patents, or OIN — it terminates at IBM.

Supporting dates/entries: the sole recorded assignment executed 1993-11-01 (inventor Peek → IBM); the only later legal events are maintenance-fee entries culminating in terminal status "Expired – Fee Related," anticipated expiration 2013-11-01. There is no reel/frame evidencing any of the above patterns because none exists in the record.

Verdict

Insufficient data — applying this bucket's literal definition ("no records, or only the original assignment").

Justification: the only assignment in the record is the inventor→IBM assignment executed 1993-11-01 and recorded at filing; the patent's legal-events feed contains no post-issuance assignment, security, merger, or release, and the term ended 2013-11-01 with status "Expired – Fee Related." There is therefore no NPE chain to evaluate — the chain is a single link terminating at an operating company (IBM), with zero assertion activity. I cannot label this "operating-company assertion" either, because IBM is not suing competitors over it; the honest characterization is that this is a routine captive corporate patent that was never transferred and never asserted. Verify the negative at the USPTO Assignment Center (https://assignmentcenter.uspto.gov/), where a search on 5481706 should return only the original IBM assignment.

I'll research this patent and its cited prior art references.

Let me gather more context on a few of the cited references and the current IPR usage of this patent.

Prior-Art Analysis — U.S. Patent No. 5,481,706

1. Patent Under Analysis (confirmed)

Verified against Google Patents: https://patents.google.com/patent/[US5481706A](/patent/US5481706A) . The number you supplied (5481706) resolves exactly to this document; no similar-number substitution was made.

Note on current relevance: US 5,481,706 is not only a patented invention — it is presently being used as prior art in a live PTAB proceeding, IPR2025‑00853, [Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.) v. VirtaMove Corp., where it is filed as Petitioner Exhibit 1010 (U.S. Patent No. 5,481,706, dated Apr. 18, 2025). It is cited against U.S. Patent No. 7,784,058. (Sources: PTAB docket listings, ai-lab.exparte.com IPR2025-00853 and GAEFlex docket pages.) This is a useful cross-check that the reference content is being relied upon today in the shared-library / user-mode library field.

---

2. What the claims actually require (the anticipation yardstick)

The §102 question is whether a single reference discloses every limitation, arranged as claimed. The independent claims are:

• Claim 1 — a method of rendering a pre-existing shared library multithread-safe by (a) creating a wrapper "comprised of program code extending around instantiation of said underlying call," including storing the pre-existing function descriptor therewithin and creating a lock to the function; and (b) rebinding the library, including creating a modified function descriptor with a pointer to the wrapper, and substituting a pointer to the modified function descriptor for the pointer to the function descriptor.
• Claim 4 — a method of (a) providing a wrapper with a lock that includes the function descriptor, (b) providing a substitute function descriptor with a pointer to the wrapper, (c) changing the pointer to the function descriptor into a pointer to the substitute descriptor, (d) invoking the chain call → substitute descriptor → wrapper → routine, (e) executing a lock on the routine, and (f) unlocking on return.
• Claim 6 — the system (means‑plus‑function) counterpart of claim 1.
• Claims 2, 3, 5 — dependent (pre/post‑rebinding call routing; descriptor contains pointer to routine; lock precludes/permit's subsequent‑thread execution).

The inventive core is the structural rewiring: wrapper code + a modified function descriptor + rewriting the table‑of‑contents pointer, so the unmodified binary routine executes under a global lock without source changes.

---

3. The cited references (examiner citations, 11 patents + non‑patent literature)

All dates below are as they appear in the patent's front page (literal). The patent has a 1993‑11‑01 filing date, so the §102 categories available are §102(a) (before invention), §102(b) (more than one year before filing → before 1992‑11‑01), and §102(e) (earlier U.S. filing).

A. The single closest citation

US 5,375,241 A — "Method and system for dynamic-link library"

• Inventor: James E. Walsh · Assignee: Microsoft Corporation · Filed 1992‑12‑21 · Granted 1994‑12‑20
• Description (from the reference): A dynamic-link library for the Macintosh OS. A code resource holds service routines; stub routines carry selection information; a selector routine receives that information and accesses the associated service routine via an interface routine that "translate[s] an index to the code resource into a selector pointer to the selector routine." Includes a resource initiation routine that "loads and locks the code resource into memory" and allocates global‑variable space. (https://patents.google.com/patent/[US5375241A](/patent/US5375241A))
• §102 relevance: This is the only citation that touches on indirect dispatch to routines and a "lock" — but the "lock" is a memory‑resident lock of a code resource, not a synchronization mutex serializing threads. There is no wrapper that stores a function descriptor, no modified/substitute function descriptor, and no table‑of‑contents pointer substitution.
• Potential anticipation: None of claims 1–6. At most it is §102(a) art relevant to the "pointer-to-dispatch-structure" concept. It cannot anticipate because it lacks the wrapper‑with‑retained‑descriptor and the descriptor/TOC rewiring.
• (It is also, notably, filed as Petitioner Exhibit 1032 in IPR2025‑00853 alongside the '706 patent — further evidence it is treated as adjacent, not anticipatory, art.)

B. Locking / serialization-of-shared-resource citations

US 4,847,754 A — "Extended atomic operations"

• Assignee: IBM · Filed 1985‑10‑15 · Granted 1989‑07‑11
• Description: Atomic read‑modify‑write primitives for serializing access to shared data in tightly coupled multiprocessors — a foundational lock/dispatch primitive reference. (The '706 specification expressly discusses it as a two‑step serialization approach requiring access‑initiation then access‑completion.)
• §102: §102(b) (pre‑1992‑11‑01). Anticipates no claim; discloses only the atomic‑lock building block, not library repackaging.

US 5,109,511 A — "Shared resource managing method and system"

• Assignee: Hitachi, Ltd. · Filed 1988‑05‑31 · Granted 1992‑04‑28
• Description: Serializes access by many processes to data elements in a main‑storage pool using hash‑table entries updated by CS/CDS (compare‑and‑swap) instructions, explicitly aiming to manage shared resources "with no lock operation." (https://patents.google.com/patent/US5109511)
• §102: §102(b). The '706 background specifically distinguishes it: "in this system no lock operations are provided for." Anticipates no claim (it is essentially the opposite approach — lockless hashing).

US 5,226,143 A — "Multiprocessor system includes operating system for notifying only those cache managers who are holders of shared locks on a designated page by global lock manager"

• Assignee: IBM · Filed 1990‑03‑14 · Granted 1993‑07‑06
• Description: A global lock manager that notifies only cache managers holding shared locks on a page. Establishes "global lock" and shared‑lock vocabulary.
• §102: §102(b). Anticipates no claim; no wrapper/descriptor mechanism.

US 5,305,448 A — "Shared access serialization featuring second process lock steal and subsequent write access denial to first process"

• Assignee: IBM · Filed 1990‑07‑02 · Granted 1994‑04‑19
• Description: Write‑exclusive shared‑access serialization with lock‑stealing; write‑access denial to the first process.
• §102 relevance: Directly underlies the '706 abstract's "write‑exclusive lock" language. But it is a lock‑semantics reference only.
• §102: §102(a)/§102(b). Anticipates no claim (no library wrapper/descriptor/TOC element).

US 5,339,427 A — "Method and apparatus for distributed locking of shared data, employing a central coupling facility"

• Assignee: IBM · Filed 1992‑03‑30 · Granted 1994‑08‑16
• Description: Distributed locking of shared data via a central coupling facility.
• §102: §102(e) (earlier U.S. filing, 1992‑03‑30). Anticipates no claim; directed to coupling‑facility locking, not in‑process library wrappers.

C. Threading / multiprocessing environment citations

US 5,353,418 A — "System storing thread descriptor identifying one of plural threads of computation…"

• Assignee: MIT · Filed 1989‑05‑26 · Granted 1994‑10‑04
• Description: Stores a thread descriptor identifying a thread, made ready only when its operands are ready — a dataflow‑style threading reference.
• §102: §102(b). Anticipates no claim; "thread descriptor" here is unrelated to the claimed function descriptor.

US 5,339,415 A — "Dual level scheduling of processes to multiple parallel regions of a multi-threaded program on a tightly coupled multiprocessor computer system"

• Assignee: Cray Research, Inc. · Filed 1990‑06‑11 · Granted 1994‑08‑16
• Description: Schedules processes into parallel regions of a multithreaded program.
• §102: §102(b). Anticipates no claim; scheduler‑level, not library‑level.

US 4,663,709 A — "Control system for tightly-coupled multiprocessing units"

• Assignee: NEC Corporation · Filed 1983‑10‑07 · Granted 1987‑05‑05
• Description: Hardware control for tightly coupled multiprocessor units.
• §102: §102(b). Remote from the claims; anticipates no claim.

US 5,047,919 A — "Method and apparatus for monitoring software execution in a parallel multiprocessor computer system"

• Assignee: Harris Corporation · Filed 1986‑04‑03 · Granted 1991‑09‑10
• Description: Monitoring/tracing software execution in a parallel multiprocessor.
• §102: §102(b). Anticipates no claim; instrumentation, not library augmentation.

US 5,230,070 A — "Access authorization table for multi‑processor caches"

• Assignee: IBM · Filed 1989‑09‑08 · Granted 1993‑07‑20
• Description: Access‑authorization table governing multi‑processor cache access.
• §102: §102(b). Anticipates no claim; cache‑coherence/authorization, not shared‑library function dispatch.

D. Non‑Patent Literature (1 item, listed twice)

"Memory Protection Software Facility for OS/2 Shared Data Applications," IBM Technical Disclosure Bulletin, Vol. 34, No. 4A, September 1991, pp. 81–89.

• Description (per the '706 background): Isolates memory areas on Intel 386‑architected systems so that DLLs can protect their critical shared global data regions. The '706 specification criticizes it because "no protection is provided for the DLLs from each other," it requires altered process address spaces, and has undesirable hardware dependencies.
• §102: Printed publication, §102(b) (Sept. 1991 < 1992‑11‑01 cutoff). It discloses protecting global data, but not the wrapper + modified function descriptor + TOC substitution of claims 1/4/6. Anticipates no claim.

---

4. Anticipation summary (§102)

Bottom line: Applying the ipsissimis verbis / "arranged as claimed" standard (see the Board's restatement of §102 in the SurfCast decision cited in my search results), none of the eleven patent citations or the IBM TDB publication anticipates any of claims 1–6, individually. Each is directed to a sub‑component of the environment in which the '706 invention operates — locks, lock managers, atomic operations, threading, scheduling, cache authorization, or generic dynamic linking. None discloses the two-limbed heart of the claims:

1. creating a wrapper that "extends around instantiation of said underlying call," stores the pre‑existing function descriptor inside it, and carries a lock; and
2. rebinding the library by creating a modified/substitute function descriptor pointing to that wrapper and substituting its pointer into the table of contents in place of the original function‑descriptor pointer.

Because all six claims require that wrapper‑descriptor‑TOC combination, the cited art is properly characterized as background/state‑of‑the‑art references (which is consistent with their being the examiner's citations in a 1996 grant), not anticipatory art. If any of them are asserted for §102, the closest candidate is US 5,375,241 (Microsoft/Walsh), but it fails on at least the "wrapper storing the pre‑existing function descriptor" and "modified function descriptor substituted into the TOC" limitations.

5. Confidence and caveats

• The reference metadata above is taken directly from the front page of US 5,481,706 (authoritative per your instructions) and cross‑checked against Google Patents where available.
• I have high confidence in the citation list, dates, assignees, and titles. I have high confidence in the §102 conclusion (no single reference anticipates), based on the full text of the '706 claims and specifications quoted therein.
• I did not obtain the full text of every cited patent to quote specific columns; where I state a reference's substance, it is either (a) restated in the '706 specification itself, or (b) drawn from the reference's own abstract/summary returned in search. If you need element‑by‑element claim charts against any specific reference (e.g., US 5,375,241), full‑text retrieval of that reference would be the next step.
• Where live search results and my training data could conflict, I have deferred to the retrieved sources (per your rule). One such result worth flagging: the PTAB exhibit caption writes the number with a comma as "5,481,706" — that is the same patent, not a different number.

I'll analyze the obviousness of US 5481706 using the prior art cited on the page. Let me first verify key reference details.

Obviousness Analysis — U.S. Patent No. 5,481,706

Patent: U.S. 5,481,706 — "System and method for creating thread-safe shared libraries"
Inventor: Jeffrey S. Peek｜Assignee: International Business Machines Corp.
Filed / Priority: 1993-11-01｜Granted: 1996-01-02
Legal status: Expired – Fee Related (anticipated expiration 2013-11-01)
Source of record: https://patents.google.com/patent/US5481706/en

This analysis builds on the previously generated sections (claim construction and prior-art mapping) and does not repeat them. It uses only the references appearing in the Prior Art sections of the patent page: the 11 "Citations (11)" (all marked "cited by examiner") and the non-patent citation. Two documents appearing in the page's "Cited By" section but bearing earlier effective dates (US 5,832,265 and US 5,630,136) are treated separately in §8.

---

1. Executive summary

The patent claims a two-part idea: (a) interpose a wrapper in front of each exported, non-thread-safe shared-library routine, and (b) serialize those routines with a lock, implemented — in the patent's AIX-flavored embodiment — by rewriting the library's table-of-contents/function-descriptor indirection so calls land on the wrapper. Neither half was new in November 1993.

• The interposition/redirection half is taught by US 5,375,241 (Microsoft, Walsh et al., filed 1992-12-21) — stub routines, a selector routine, and an interface routine that translates an index into a selector pointer for a service routine in a shared code resource, with "load and lock" of the resource.
• The serialization half is squarely old: US 5,109,511 (Hitachi), US 4,847,754 (IBM), US 5,226,143, US 5,230,070, US 5,305,448, US 5,339,427 all teach lock/unlock or equivalent serialization of concurrent access to shared data, and the patent itself concedes this in its Background (see §5 in the previously generated section).
• The problem statement itself (protecting a DLL's critical shared global data) was published in the IBM Technical Disclosure Bulletin in September 1991, three years before filing.

Conclusion: claims 1–6 would have been obvious under § 103(a) over US 5,375,241 in view of US 5,109,511 and/or US 5,305,448, optionally further in view of the IBM TDB article. The only genuinely case-specific limitation — rebuilding the library by substituting a modified function descriptor that is a copy of the original with a wrapper pointer spliced into the entry-point field — is a predictable implementation choice within the interposition teaching and, on this record, does not rescue the claims.

---

2. The claimed subject matter (key limitations)

Claim 1 (method) — in a system with a pre-existing shared library having a function descriptor, a pointer to it, and a non-thread-safe function with an exported underlying call:

1. create a wrapper = program code extending around instantiation of the underlying call, responsive to that call;
2. store the pre-existing function descriptor within the wrapper and create a lock to the function;
3. rebind the library: create a modified function descriptor having a pointer to the wrapper, i.e. a copy of the function descriptor with the wrapper pointer substituted for the pointer-to-function;
4. substitute a pointer to the modified function descriptor for the pointer to the function descriptor.

Claim 2 — a call before rebinding hits the original pointer; after rebinding it hits the modified descriptor pointer.
Claim 3 — the function descriptor includes a pointer to the routine.
Claim 4 — wrapper (with lock and with the function descriptor) → substitute descriptor pointer → invoke chain → execute lock → invoke the descriptor's pointer to the routine → unlock on return.
Claim 5 — the lock/unlock precludes/permits execution of the routine from a subsequent call by another thread.
Claim 6 — means-plus-function counterpart of claim 1.

---

3. Legal standard

Under 35 U.S.C. § 103(a) the question is whether the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art. The Graham v. John Deere factors govern: (1) scope and content of the prior art; (2) differences between the prior art and the claims; (3) level of ordinary skill; (4) secondary considerations. Under KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007), a claimed combination is obvious where the improvement is the predictable use of prior-art elements according to their established functions, where the combination is of known techniques to solve a known problem, or where there is a design incentive / market pressure and a finite number of identified, predictable solutions. A motivation to combine may arise from the references themselves, from the knowledge of a PHOSITA, or from the nature of the problem, and need not be stated expressly (KSR; In re Kahn; DyStar).

---

4. Person of ordinary skill in the art (POSITA)

As of November 1993: a bachelor's degree in computer science or electrical engineering and approximately 3–5 years' experience in operating-system and systems programming, including familiarity with (i) shared/dynamic libraries and the runtime linking-and-loading path, (ii) AIX/UNIX function descriptors and tables of contents (the patent itself calls this "conventional"), and (iii) mutex/lock primitives for multiprocessor and multithreaded environments — the very vocabulary the patent's Background treats as well understood.

---

5. The prior art of record (as listed on the page)

Verified reference content (Google Patents): US 5,375,241 — https://patents.google.com/patent/[US5375241A](/patent/US5375241A) ; US 5,109,511 — https://patents.google.com/patent/US5109511 ; US 4,847,754 — https://patents.google.com/patent/US4847754.

---

6. Decomposition of the invention into two old teachings

Every claim limitation falls into one of two bins, each of which was independently known:

Bin A — Interposition / call redirection through an added layer of indirection.
US 5,375,241 teaches a caller invoking a stub whose selection information is passed to a selector via an interface routine that converts an index into a selector pointer — i.e., an added indirection layer inserted in front of an unmodified service routine, without editing the service routine or copying it into the caller. That is Bin A. The patent's wrapper + modified descriptor + rebuilt table of contents is the same architectural move applied to an AIX-style descriptor table.

Bin B — Serializing concurrent access with a lock.
US 5,109,511, US 4,847,754, US 5,305,448, US 5,339,427, US 5,226,143, and the patent's own Background establish that guarding shared data with a lock/mutex, and releasing it on return, was routine. Claim 5's "preclude/permits execution from a subsequent call from another thread" is the definition of an exclusivity lock (cf. US 5,305,448).

The claimed invention is the combination: put a lock inside a layer interposed in front of each exported routine. Because both bins are known, and the combination merely applies each element to its ordinary purpose, the combination is presumptively obvious under KSR.

---

7. The obviousness grounds

Ground 1 (primary): US 5,375,241 + US 5,109,511

Motivation to combine — from the references and the nature of the problem. US 5,375,241 exists precisely to let multiple programs share one copy of service routines while keeping the library "physically distinct" and separately updatable — and it already acknowledges resource protection and locking of the code resource. US 5,109,511 is directed to the same environment (parallel processes sharing main-store resources) and states that serializing access to shared resources is conventionally realized by "lock" and "unlock" operations. A POSITA seeking to protect a shared library's global data against concurrent threads would (i) choose interposition because US 5,375,241 shows how to insert a layer without touching the routine, and (ii) choose a lock because the serialization literature (US 5,109,511) identifies it as the standard, predictable remedy. This is a finite, predictable solution set applied to a known problem.

Mapping to claim 1: "wrapper… extending around instantiation of said underlying call" ← US 5,375,241's stub/selector/interface structure; "creating a lock to said function" ← US 5,109,511; "modified function descriptor… pointer to said wrapper… copy of said function descriptor with the wrapper pointer substituted" ← US 5,375,241's interface routine substituting a selector pointer for the index, and its load-and-lock of the code resource. Claims 2–3 are inherent in the two-path indirection (before/after rebinding) and in the descriptor's pointer-to-routine. Claim 4 is the runtime corollary. Claim 5 is met by US 5,305,448/US 5,109,511.

Ground 2: US 5,375,241 + US 4,847,754

For the case where the examiner treats the patent's serialization as "lock-free." US 4,847,754 teaches serialization of shared-resource access without delaying a process, using an initiation/completion partition that brackets the use of the resource — functionally the acquire/release bracket of claim 4. Combined with the US 5,375,241 interposition, the bracket-around-the-call limitation is met.

Ground 3: IBM TDB (9/1991) + US 5,109,511 (or US 5,305,448)

The TDB article is the closest thing to a statement of the problem: protecting DLL critical shared global data regions. The applicant distinguished it in the Background on the grounds that it does not protect DLLs from each other, requires altered address spaces, and has hardware dependencies. That distinction targets the TDB's memory-isolation implementation, not the idea of guarding shared data. Combining the TDB's problem statement with a conventional lock (US 5,109,511; US 5,305,448) supplies the claimed solution; the "protect DLLs from each other" gap the applicant identified is exactly what a single global lock acquired by every wrapper provides — which is precisely what the patent discloses ("all wrappers will obtain the same lock"). That the patent's own solution is the coarse version undermines rather than supports non-obviousness.

Ground 4 (claim 5): US 5,305,448 (or US 5,339,427) + US 5,375,241

US 5,305,448 discloses write-exclusive serialization with denial of access to a second requester while the first holds the lock — a direct reading on claim 5's "precludes execution of said routine from a subsequent said function call from another of said multiple threads while said routine is executing."

---

8. Documents outside the examiner's "Citations" list

The page lists under "Cited By" two references whose effective dates precede the 1993-11-01 filing, and which are therefore candidates for § 102/§ 103 art that the record shows was not in the "Citations" set:

• US 5,832,265 — Siemens Nixdorf, "Reentrant libraries" (PCT/DE1993/000256 filed 1993-03-22; WO 94/22080). Verified at https://patents.google.com/patent/US5832265. It claims and describes: renaming a non-reentrant library subroutine, providing a "shell subroutine" (a wrapper) bearing the original name, which sets an exclusive control means, calls the renamed subroutine, and resets the exclusive control means — i.e., the wrapper + lock + renamed-underlying-call architecture of claim 1/claim 4, including per-class lock assignment (cf. the patent's global-lock discussion). It does not appear to disclose the AIX-style function-descriptor/table-of-contents pointer-substitution mechanism. Its status as § 102(e) art turns on its PCT/US national-phase and publication facts, which I have not independently verified; treat this as a lead, not a conclusion.
• US 5,630,136 — Sun, "serializing access to multithreading unsafe resources" (filed 1995-06-09) — post-dates the 1993-11-01 filing and is therefore not prior art against this patent under § 102(a)/(b)/(e). It is relevant only as evidence that the interposition-plus-serialization approach became the industry norm shortly after.

Practical significance: US 5,832,265, if it qualifies, is the single most damaging reference because it discloses the interposition + lock combination generically, reducing the patent's remaining novelty to the descriptor-rewriting mechanics — and, as shown in §9, that residual is a predictable implementation detail.

---

9. The residual limitation: "modified function descriptor"

The one element not literally shown by any single citation is the specific mechanism of claim 1: rebuilding the library so that the table-of-contents pointer is redirected from the original function descriptor to a modified descriptor that is a copy of the original with the entry-point pointer swapped for the wrapper pointer, the original descriptor being preserved inside the wrapper.

This is not a saving distinction:

1. The patent itself calls the function-descriptor/table-of-contents structure "conventional." Where the architecture is conventional, wiring a wrapper into it is a predictable design choice within the skill of the art (KSR).
2. US 5,375,241 already performs the same kind of substitution — an interface routine translating an index into a selector pointer to a selector routine — which is an added-indirection-layer redirection functionally identical to pointer substitution in a descriptor table.
3. The claims recite the descriptor mechanics at a functional level ("a pointer to said wrapper," "a copy of said function descriptor"), not with the specificity of an AIX TOC layout; the specification supplies no criticality or unexpected advantage for the copy-and-substitute step.
4. The specification's own discussion frames descriptor rewriting as a "rebuilding"/"rebinding" housekeeping consequence of adding wrappers, not as the inventive contribution.