US 6182141

I'll search for this specific patent number across USPTO and litigation sources.

Let me check for any 2026 CAFC litigation or PTAB proceedings involving this specific number.

US Patent 6,182,141 — Analyst Summary

Search scope and caveats

I searched for the literal string 6182141 / 6,182,141 across patent databases (Google Patents, USPTO-derived mirrors such as uspto.report and searchlight.law) and for Federal Circuit / PTAB activity. I found no CAFC 2026 docket, appeal, or district-court case in which US 6,182,141 is the asserted patent. I cannot rule out a 2026 proceeding that is not indexed in the sources I can reach; treat the "no litigation found" statement as a negative search result, not a guarantee. The only proceedings I located that touch this number are PTAB IPRs in which 6,182,141 was submitted as prior art against a third party's patent (see below), not challenges to 6,182,141 itself.

---

Bibliographic data (as literally reported)

Notices worth flagging verbatim: the front page carries the notice "This patent issued on a continued prosecution application filed under 37 CFR 1.53(d), and is subject to the twenty year patent term provisions of 35 U.S.C. 154(a)(2)" and "Under 35 U.S.C. 154(b), the term of this patent shall be extended for 0 days." It is a CPA-derived patent, and the 20-year term runs from the 1996-12-20 filing, consistent with the 2016-12-20 expiration.

Identifier discrepancies (reported, not corrected): one third-party aggregator (patents.searchlight.law) labels the document "US 6,182,141 B2" — the authoritative sources consistently show B1. A Unified Patents listing shows a priority date of 1996-12-19, whereas the patent front page, Google Patents, uspto.report, and the document itself all state 1996-12-20; I treat the 1996-12-19 entry as a database artifact.

---

Abstract (verbatim)

"A transparent proxy. In a computer system, a layered service provider intercepts a communications request from a client application in the native protocol of the communications request wherein the communications request requests communication with a remote server. The service provider bundles and passes the communications request to a predetermined port. A transparent proxy application listening on the predetermined port receives the communications request in the native protocol of the request and establishes the requested communication."

---

Plain-language overview of the independent claims

The patent has five independent claims: 1 and 13 and 21 (method / machine-readable medium), 7 (apparatus), and 17 (client computer). Claims 2–6, 8–12, 14–16, and 18–20 depend from them.

Claim 1 — Method (client side). A layered service provider — sitting above a transport service provider in a protocol stack on the client computer — intercepts a communications request from a client application in the request's native protocol. The LSP decides whether the request is aimed at a remote server. If so, the LSP packages the request and forwards it to a transparent proxy application, which receives it still in the native protocol and sets up the requested connection to the remote server. The novelty is that the client app never learns about the proxy and the request is never re-encapsulated in a different protocol.

Claim 7 — Apparatus (client side). An apparatus comprising a layered service provider stored on the client computer that intercepts a client application's communications request in the request's native protocol and forwards it to a transparent proxy which controls communication with the remote server.

Claim 13 — Machine-readable medium (client side). Instructions that cause a first computer to do the Claim 1 sequence, with the added specifics that the LSP passes the request to a predetermined well-known port on which the transparent proxy listens, and again requires the request to be received in the native protocol.

Claim 17 — Client computer. A hardware apparatus claim: bus, processor, and memory storing (i) an application program, (ii) a transport service provider, and (iii) a layered service provider above the transport service provider in the stack, the LSP intercepting a request directed to a remote server and forwarding it to a transparent proxy application, with the transport service provider carrying the data.

Claim 21 — Machine-readable medium (proxy/server side). From the proxy's perspective: instructions causing a first computer to receive a communications request that a layered service provider (above a transport service provider in the client's stack) intercepted from a client application and directed to a remote server, and to establish the requested communication with the remote server on behalf of the client application.

Notable dependent-claim limitations: Claim 2 restricts Claim 1 to a connection request handled by a layered API-tunneling service provider; Claim 3 to an address-resolution request handled by a name-space service provider stub. Claim 6 adds the pass-through branch — if the request is for a local computer, it is handed to local communications services. Claim 18 requires the memory to store a Winsock TCP/IP stack; Claim 19 requires a Windows operating system. Claims 22–25 add dial-out mechanism control, native-protocol receipt, a protocol filter look-up/application step, and bidirectional tunneling.

Claim 1 caveat: as issued, Claim 1 recites only the remote-server determination and forwarding; the local-request pass-through appears in Claim 6 rather than the independent claim.

---

Cited prior art (front page)

Seven US patents: 5,218,699 (Brandle, IBM); 5,604,896 (Duxbury, ICL); 5,623,601 (Vu, Milkway Networks); 5,699,513 (Feigen, Motorola); 5,781,550 (Templin, Digital Equipment — "Transparent and secure network gateway"); 5,826,014 (Coley, Network Engineering Software); 5,987,517 (Firth, Microsoft). Non-patent literature: Rolf Oppliger, "Internet security enters the Middle Ages," IEEE, Oct. 1995; Bellovin et al., "Network Firewalls," IEEE Communications Magazine, Sep. 1994.

---

Related proceedings (prior-art use, not assertions of this patent)

The document was filed as Exhibit 1063 (US 6,182,141) in IPR2014-00237 and IPR2014-00238 (VirnetX's US 8,504,697). It is also cited as an "A" reference in WO2006093079A1 (NEC). I found no record of 6,182,141 being asserted in litigation or challenged at the PTAB, and no 2026 appellate activity.

---

Uncertainties

• No CAFC 2026 docket found for this patent. I do not have authoritative confirmation either way for 2026 dockets beyond my searches.
• The 1996-12-19 vs. 1996-12-20 priority discrepancy is unresolved in third-party databases; the patent itself and primary mirrors say 1996-12-20.
• The B1 vs. B2 label discrepancy at searchlight.law is a mirror-site error as far as I can tell, but I have not corrected it per the literal-identifier rule.
• Current ownership could have changed post-issuance; the only assignment of record shown is Intel Corporation, with the 1997-07-24 inventor-to-Intel assignment.

Primary source URLs: https://patents.google.com/patent/US6182141/en ; https://uspto.report/patent/grant/6182141 ; PDF: https://patentimages.storage.googleapis.com/88/99/61/45892326444623/US6182141.pdf

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

Let me search more specific litigation databases and case sources.

Let me run additional targeted searches on litigation databases.

Litigation Search: US Patent 6,182,141

Bottom line: I could not identify any known litigation (district court, ITC, or Federal Circuit) in which US Patent 6,182,141 was asserted.

What the searches returned

I searched for the patent number in the context of infringement complaints, docket listings, and the Unified Patents litigation/PTAB portals. None of the results reflected an assertion of the ’141 patent against any party. Instead, every hit was one of the following non-litigation contexts:

1. Prior art / citation usage — The ’141 patent appears repeatedly as a reference cited by later patents, not as an asserted patent. Examples:

   • WO2006093079A1 (NEC Corporation, "Communication system…") lists "US 6182141 B1 (Intel Corp.), 30 January 2001" in its search-report/prior-art table (patentimages.storage.googleapis.com mirror).
   • Justia pages for later patents — e.g., US 8,604,917 and US 9,444,791 ("Method and system for providing secure access to private networks") and US 8,037,125 ("Method for uniform network access") — cite "6182141 | January 30, 2001 | Blum et al." merely as a related/referenced patent.
   • The VirnetX agile-network patent family documents (e.g., the ITC/CAFC submission at cryptome.org, "agile-network-secure-comms-patent-14-1202.pdf") list "6182141 January 2001 Blum et al." as prior art.

2. Unified Patents portal / docket records — The Unified Patents portal entries I retrieved list the ’141 patent only as a related patent alongside many others (assignee listed as Intel Corp., priority date given variously as 1996‑12‑19/20). No PTAB or litigation case in which it is the challenged/asserted patent appeared.

3. Inventor/assignment records — Patent Leaderboard confirms the ’141 patent (Scott Blum / Jonathan Lueker, Intel) but contains no litigation data.

Important caveats

• I was not able to directly query PACER or the Unified Patents case list in this session (the targeted queries returned no case-list page for the ’141 patent), so this is not an affirmative "no litigation ever existed" finding — it is a statement that no litigation is known/reported based on the sources I could reach.
• The patent is expired (anticipated expiration 2016‑12‑20 per the Google Patents family data), which reduces — but does not eliminate — the likelihood of recent assertion activity.
• Some litigation databases (Docket Alarm, Justia Dockets, Unified Portal case lists) are partly paywalled or not fully indexed by general web search, so a definitive negative would require a direct PACER/Docket Alarm search.

Recommended verification steps

To conclusively confirm the absence of litigation, I would recommend directly checking:

• PACER (all district courts and the Federal Circuit) — search by patent number 6,182,141.
• Unified Patents Portal – https://portal.unifiedpatents.com/litigation/caselist (filter by patent number).
• USPTO Patent Trial and Appeal Board — for any IPR/PGR/CBM involving the ’141 patent.
• Docket Alarm / Justia Dockets / Lex Machina / RPX — patent-number search.

If you'd like, I can draft the exact search strings to run on each of those platforms, or attempt a fresh web search on a specific docket database.

I'll research whether any AIA trial proceedings exist on US 6,182,141, starting with the canonical structured source and then verifying via web search.

The first searches surfaced the '141 patent only as a prior-art exhibit (Ex. 1063) in VirnetX IPRs, not as a subject patent. Let me run more targeted checks.

No proceedings surfaced. Let me do a final confirmation sweep for CBM/PGR activity and any USPTO PTAB docket entries.

Proceedings overview

Zero AIA trial proceedings — no IPR, PGR, or CBM — have ever been filed against US 6,182,141 ("Transparent proxy server," Blum & Lueker, Intel Corp., filed 1996-12-20, granted 2001-01-30). The structured "PTAB proceedings on file" block confirms the USPTO Open Data Portal returns no AIA trials as of the most recent ingest, and my independent web checks (Google Patents' litigation/PTAB links, Docket Alarm, FreePatentsOnline, uspto.report, and general PTAB-decision searches) surfaced no trial number naming this patent as the subject patent. The only PTAB appearances of the '141 patent are as prior art (Exhibit 1063) in VirnetX-targeted IPRs against a different patent — discussed below as a near-miss. Bottom line for a defendant: there is no PTAB-based invalidation record to lean on, but the reason is structural, not because the patent is bulletproof — the patent expired 2016-12-20 (20-year term from the 1996-12-20 filing; Google Patents legal status "Expired - Lifetime"), which killed the economic incentive to challenge it at the Board.

---

No proceedings to report

There is no {PROCEEDING_NUMBER} to populate for this patent. To be explicit about what I verified and what I did not:

• No IPR/PGR/CBM petition, institution decision, FWD, or appeal naming US 6,182,141 as the challenged patent was found in any source I could query. I do not have a PTAB trial number for this patent, and I will not invent one.
• No Federal Circuit appeal (no VirnetX-style CAFC docket) exists because there was no underlying PTAB decision to appeal.
• No ex parte or inter partes reexamination certificate appears in the file history either.
• Caveat on completeness: my searches hit a step limit before I could exhaustively query PTAB E2E / USPTO Patent Trial & Appeal Board endpoint by patent number and the CourtListener docket API. Given the ODP default is "no PTAB activity," the absence of any trial number in five independent search angles, and the patent's expiration, I assess the risk of a missed proceeding as low — but a defendant should confirm via a direct PTAB E2E party/patent search before relying on it.

The one "near-miss" (not a proceeding against '141)

• IPR2014-00237 and IPR2014-00238 (VirnetX-issued U.S. 8,504,697) — the '141 patent was filed as Petitioner's Exhibit 1063 on 2013-12-06 in these VirnetX-targeted reviews. It was submitted as prior art to invalidate someone else's patent, not challenged itself. (See the exhibit as hosted on Docket Alarm: https://www.docketalarm.com/cases/PTAB/IPR2014-00237/Inter_Partes_Review_of_U.S._Pat._8504697/docs/12-06-2013-Petitioner/Exhibit-1063-US_Patent_No_6,182,141.pdf.) I did not independently verify the petitioner identity in those two proceedings within my search budget, so I flag that attribution as unconfirmed. Defensive value: irrelevant to validity of '141, but it confirms the patent is known and used as art by sophisticated litigants — i.e., the prior-art space around it is well-mapped.

---

Strategic summary

Claim status — all 25 claims UNTESTED at the PTAB. No claim of 6,182,141 has been canceled, disclaimed, or held unpatentable in any AIA trial, and none has been judicially invalidated in any decision I could locate. Claims 1–25 therefore all retain their statutory presumption of validity. The patent is, however, expired as of 2016-12-20, so no post-expiration damages accrue; any assertion today is limited to past damages within the 35 U.S.C. § 286 six-year lookback window (i.e., roughly mid-2020 forward, which for an expired patent is a shrinking and essentially closed window).

Estoppel landscape is empty. Because no IPR/PGR ever reached a final written decision, there is no § 315(e)(2) estoppel binding any petitioner or privy, and no § 325(e)(2) estoppel from a PGR. There is no prior Board claim construction to leverage and no patent-owner disclaimer in an IPR record to hold the owner to (contrast the ParkerVision-style prosecution-disclaimer trap). For a defendant being asserted against today, the full prior-art field remains available — § 102/§ 103 in district court, and, if desired, a fresh IPR (the Board can institute on an expired patent, 35 U.S.C. § 311(c) notwithstanding). The 1996-12-20 priority date gives an unusually deep art window: the examiner's own cited references — US 5,781,550 (Templin, DEC "Transparent and secure network gateway"), US 5,826,014 (Coley firewall), US 5,699,513 (Feigen), US 5,623,601 (Vu), US 5,987,517 (Firth/Microsoft — a library of protocol-independent reentrant network interface functions, i.e., the layered-Winsock concept), plus US 5,604,896 (Duxbury) and US 5,218,699 (Brandle) — are all fair game and several map directly onto the "layered service provider above a transport service provider" limitation. The specification itself concedes the transparent-proxy concept and admits the "well-known port" was not yet registered with IANA (see the '141 specification), which narrows the claim-differentiation story.

Pattern signals — none. No petitioner filed multiple IPRs; the patent owner (Intel, then its successors) never appealed anything to the Federal Circuit; there is no third-party challenger or defensive aggregator (e.g., Unified Patents) in the chain. That profile is consistent with a patent that was simply never worth attacking: it expired with no visible assertion campaign, and its citation lineage (later patents from Cisco, Juniper, Nomadix, VirnetX, Neoteris, etc. cite '141 as background art) shows it functioned as prior art rather than as an enforcement asset.

---

Recommended next steps

1. Treat the "no PTAB activity" as firm but verify directly. Run a patent-number search on PTAB E2E (https://ptacts.uspto.gov/) and the USPTO ODP API for 6182141 before finalizing any opinion. If a stray trial number exists, it will surface there; my searches found none.
2. Do not expect a PTAB shortcut. There is no FWD to point to and no canceled claims to cite. A defendant cannot say "claim 1 is dead" — all 25 claims are live (though expired). Any invalidity case must be built from scratch: district-court §§ 102/103, or a new IPR petition grounded in the examiner-cited art above plus other pre-1996 references. Note the practical headwind — because the patent expired 2016-12-20, an IPR's value is limited to defeating past damages, and the Board will weigh whether the petition serves any live controversy.
3. Lead with the expiration and § 286 timing, not validity. The single strongest defensive fact is that the patent expired 2016-12-20, capping damages to the six years before filing (§ 286) and eliminating injunctive relief for ongoing conduct. If a demand letter cites any of claims 1–25, the exposure is bounded past damages — and any pre-2016-12 conduct is time-barred.
4. If litigation is threatened, mine the layered-service-provider art first. Claims 1, 13, and 17 hinge on the "layered service provider above a transport service provider in a stack" element; US 5,987,517 (Firth/Microsoft) and the Winsock 2 layered-provider architecture are the natural § 103 anchors, combined with a transparent-gateway reference such as Templin '550 or Vu '601 for the "transparent proxy application on a predetermined port" element.
5. Because nothing is on file at the Board, the absence is the signal. Well-asserted, high-value patents attract IPRs; this one attracted none across a 20-year term. That is weak evidence of commercial irrelevance and useful context for a damages/royalty narrative — but it is not evidence of invalidity, and a defendant should not represent it as such.

Sources consulted: USPTO/ODP "PTAB proceedings on file" block (canonical, default = no activity); Google Patents US6182141B1 (legal status "Expired - Lifetime"; cited-by and citation lists) at https://patents.google.com/patent/US6182141B1/en; Docket Alarm IPR2014-00237/00238 exhibit 1063; uspto.report grant page https://uspto.report/patent/grant/6182141. No PTAB FWD, CAFC opinion, or E2E trial number for this patent was located, and none is cited here because none was found.

I'll research the assignment record for US 6182141. Let me run several searches.

Let me search for the specific assignment record and any subsequent transfers.

Let me look for the specific reel/frame record and any NPE/directory data.

Assignment & Ownership Analysis — US 6,182,141 ("Transparent proxy server")

Important provenance note

I retrieved the Google Patents legal-events record and third-party mirrors (uspto.report, Espacenet INPADOC, Unified Patents portal, Patent Leaderboard). What I could not retrieve in this session is the USPTO Patent Assignment Search (Assignment Center) detail page for this patent, which means I do not have the recorded reel/frame numbers or the recording correspondent for the single assignment in this chain. I am flagging that gap rather than inventing reel/frame data. The Google Patents legal-events line for the assignment is quoted verbatim below; everything else is grounded in the front-page/INPADOC data.

---

Inventors

• Both inventors are listed as Intel personnel; Patent Leaderboard confirms Scott Blum — 7 US patents "while listed as an inventor at Intel."
• Unusual-pattern check: I found no evidence in the sources retrieved of both inventors departing Intel within 12 months of filing. The application was filed 1996‑12‑20 and the inventors' interest was assigned to Intel the following year (see timeline), which is the opposite of a pre-fire-sale departure pattern. I cannot confirm or deny departure timing — that would require employment records I did not access. No departure finding.
• Caution: "Scott Blum" is also the name of the founder of Buy.com, and "Jonathan Lueker" matches the name of a well-known computer-science academic (Booth–Lueker). I did not verify any identity linkage and I am not asserting it.

---

Original assignee

• Intel Corporation, Santa Clara, CA (named on the issued patent, (73) Assignee: Intel Corporation).
• Primary line of business: semiconductor / platform and software products. The patent claims a transparent proxy implemented via a Winsock 2.0 layered service provider — squarely within Intel's 1990s client-networking-software work.
• Did Intel ship a product embodying the claims? Unclear/likely-adjacent. Intel was building LAN/connectivity software in this era, but I found no evidence tying this specific patent to a named shipped Intel product. I decline to assert embodiment I cannot source.
• Current status: Operating (large publicly traded semiconductor company). The patent itself is Expired – Lifetime (anticipated expiration 2016‑12‑20 per Google Patents family data).
• Current assignee (Google Patents): still Intel Corp — no downstream assignee is listed.

---

Assignment timeline

Chronological list of recorded assignments found:

• ~1996‑12‑20 (execution presumed at/near filing) / recorded 1997‑07‑24 — Reel/Frame: not retrieved (see provenance note)
  • Conveyance: Assignment ("ASSIGNMENT OF ASSIGNORS' INTEREST")
  • Assignor: Blum, Scott B.; Lueker, Jonathan
  • Assignee: Intel Corporation
  • Correspondent: not retrieved from the recordation. (Note: the attorney of record on the patent face is Cynthia T. Faatz, (74) Attorney, Agent, or Firm—Cynthia T. Faatz — this is prosecution counsel, not necessarily the assignment-recording correspondent; do not conflate the two.)
  • Context: Invention-capture / employee assignment to the original operating-company employer. Routine pre-issuance assignment of inventor rights to Intel.
  • Source (verbatim Google Patents legal events): "1997‑07‑24 Assigned to INTEL CORPORATION … ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BLUM, SCOTT B., LUEKER, JONATHAN."

No post-issuance assignments were found. There is no record of any transfer to an IP-holding entity, NPE, or defensive aggregator. This is itself a finding: the chain appears to be a single link, and the patent was held by Intel from issuance (2001‑01‑30) until expiration (2016‑12‑20).

---

Timeline diagram

timeline
    title Ownership of US 6182141
    1996 : Filed by Blum and Lueker
         : Inventors assign rights to Intel
    1997 : Assignment recorded to Intel
    2001 : Patent issued to Intel
    2016 : Patent expired

---

NPE / troll-pattern signals

Each signal judged only on evidence found; absent evidence is called out as such.

1. Shell-entity transfer — Not present. No transfer to any "IP / Patents / Licensing / Holdings / Ventures" successor appears in the record. Current assignee remains Intel Corporation; no registered-agent-only LLC in the chain.

2. Known asserter in the chain — Not present. Neither assignee of record (Intel) nor assignors match any public NPE list (Acacia, Marathon, IV, IPNav, Wi-LAN/Conversant, Vringo, Pendrell, Round Rock, etc.). The Unified Patents portal entry for US-6182141-B1 lists only Intel Corp as assignee. The only IV-adjacent document that surfaced (an Intellectual Ventures Assets 156 LLC → Innovative Silicon Solutions LLC assignment) covers unrelated patents (e.g., power-saving/cache patents by other inventors) and does not list the ’141 patent — I checked and it is not part of that conveyance.

3. Repeat correspondent across the chain — Unclear / cannot assess. No assignment-recordation correspondent was retrievable, and there is only one link in the chain, so no recurrence can exist. No NPE assertion-list correspondent matches were found. The patent's prosecution attorney Cynthia T. Faatz is noted for completeness but is a prosecution-side name, not evidence of NPE activity.

4. Cascading transfers — Not present. Only one recorded assignment (inventors → Intel); no chained LLC hops.

5. Pre-litigation transfer — Not present. No transfer exists to measure against a suit date; and per the prior section there is no known litigation naming this patent.

6. Bankruptcy fire-sale — Not present. No evidence Intel patents of this vintage were sold in a proceedings-based sale tied to this patent; Intel remained the assignee.

7. Privateering — Not present. No operating-company-to-NPE transfer and no competitor-assertion evidence.

8. Defensive aggregator (anti-NPE) — Not present. The chain does not terminate at RPX, AST, LOT, Unified, or OIN; it terminates with the original operating company and expires.

---

Verdict

Insufficient data — only the original assignment is recorded. (Functionally: no NPE activity; original operating-company assignee retained ownership.)

Justification: The sole recorded conveyance is the inventors → Intel Corporation assignment recorded 1997‑07‑24, and no post-issuance assignment to any IP-holding or licensing entity appears in Google Patents, Espacenet INPADOC, uspto.report, the Unified Patents portal, or Patent Leaderboard — where the current assignee is listed as Intel Corp. With just the initial employee-to-employer link on record and no downstream transfer, this lands squarely in the "only the original assignment" category, and every NPE signal evaluates to not present or unclear. I could not retrieve reel/frame numbers or the recording correspondent from the USPTO Assignment Center in this session, so those fields are explicitly left unresolved rather than fabricated.

Verify at: https://assignmentcenter.uspto.gov/ (search "6182141" / application 08/770,918) and https://assignment.uspto.gov/patent/index.html . Also see the Google Patents legal-events page: https://patents.google.com/patent/[US6182141B1](/patent/US6182141B1)/en

---

Cross-reference flag (vs. the earlier litigation section)

The earlier "Litigation summary" found no known litigation involving the ’141 patent and noted it appears only as cited prior art (e.g., WO2006093079A1, the VirnetX agile-network family documents, and as an exhibit in VirnetX IPRs). That is consistent with the ownership finding here: a patent that stayed with Intel and expired was never weaponized, so the absence of litigation and the absence of any NPE assignment reinforce each other. No contradiction between sections.

I'll build on the prior sections by verifying the prosecution-cited prior art directly. Let me run targeted searches against USPTO and the individual reference numbers.

I have the first four references confirmed. Now let me verify the remaining three front-page references (Feigen, Templin, Coley, Firth) plus the two NPL items.

Prior-Art Analysis for US 6,182,141 B1 ("Transparent proxy server")

Building on the earlier bibliographic and claim-mapping sections; this section adds the reference-by-reference § 102 analysis and does not repeat the claim summaries.

---

0. USPTO record confirmation (exact number)

I searched specifically for 6182141 and confirmed the record is U.S. Patent 6,182,141 B1 — not 5,182,141, 6,182,140, or any similar number.

Sources: https://uspto.report/patent/grant/6182141 ; https://patents.google.com/patent/[US6182141B1](/patent/US6182141B1)/en ; Espacenet INPADOC family (https://worldwide.espacenet.com/publicationDetails/inpadocPatentFamily?CC=US&NR=[6182141B1](/patent/6182141B1)&KC=B1&FT=D). The Espacenet family page independently lists the cited-art set as US5218699, US5604896, US5623601, US5699513, US5781550 (and the Google front page adds US5826014, US5987517), which matches the seven references analyzed below.

Flag: the Espacenet family page confirms the priority date of 1996-12-20, which reinforces that the 1996-12-19 entry some aggregators show is a database artifact (consistent with the earlier section's finding).

---

1. Legal framework used for the § 102 mapping

Because this patent was filed 1996-12-20, it is governed by pre-AIA 35 U.S.C. § 102. Critical dates:

• § 102(b) statutory bar → reference must be patented or described in a printed publication before 1995-12-20 (one year before filing).
• § 102(a) → reference published/knows before the applicant's invention date (presumed ≈ filing).
• § 102(e) → a US patent granted on an application filed before the applicant's invention. Because every one of the six post-1993 references below was filed in the US before 1996-12-20, each qualifies as potential § 102(e) art even though it issued after the ’141 filing date.

Important framing caveat: No single cited reference appears to anticipate independent claims 1/7/13/17/21 outright. Claim 1 requires a "layered service provider above a transport service provider in a stack" on the client that intercepts the request and forwards it to a transparent proxy that receives it in the native protocol. The cited art splits this concept: some references teach the transparent intermediary (Vu, Templin, Feigen), while others teach the layered interface library (Firth, Brandle). Accordingly, the honest § 102 assessment below identifies the claims each reference is closest to, while flagging that most of these are stronger § 103 combinations than true single-reference anticipations.

---

2. Patent references (front page)

(a) US 5,218,699 — Brandle et al. (IBM)

• Full citation: US 5,218,699 A, "Remote procedure calls in heterogeneous systems," Brandle et al., International Business Machines Corp.
• Dates: filed 1989-08-24; issued 1993-06-08. (A secondary source, radaris, lists a "Jun 8, 1992" date and app. 07/895,221 — likely a continuation date; the Google front-page data used here is 1989-08-24 / 1993-06-08.)
• Description: RPC system across mixed-language computer networks. An application on a local node issues a procedure call via a stub procedure / service director that does not know whether the target library procedure is local or remote; the director selects service directories, determines local vs. remote, and if remote, initiates a communications session and passes a procedure identifier to the remote node, executes, and returns results to the caller.
• § 102 status: § 102(b) (issued >1 yr before 1996-12-20), also § 102(a)/(e).
• Claims potentially affected: Closest to claim 1 / 13's "determining whether the … request requests communication with a remote server" and the stub-interception concept, and to claim 7's "layered service provider … to intercept … and forward." However, it discloses no proxy and no native-protocol forwarding to a proxy, so it does not anticipate claims 1, 7, 13, 17, or 21; it is background/§ 103 material on the "intercept → determine local/remote → transparently forward" step.

(b) US 5,604,896 — Duxbury et al. (International Computers Ltd.)

• Full citation: US 5,604,896 A, "Computer with terminal emulation interface for multi-environment client/server applications," Duxbury et al., International Computers Limited.
• Dates: filed 1993-07-13; issued 1997-02-18.
• Description: Two processing environments joined by a gateway. The gateway includes terminal-emulation means and converts client service requests into dialogues on the emulated terminal. The specification states the client "is not aware that it is communicating with the server" through the gateway — i.e., communication is "completely transparent to the clients."
• § 102 status: § 102(e) only (US filing 1993-07-13 precedes the applicant's filing; issued after, so not § 102(a)/(b)).
• Claims potentially affected: Speaks to claim 5 (client does not include information about the proxy) and generally to the "transparent" intermediary concept in claims 1/7. But it is a terminal-emulation/scripting gateway, not a proxy that receives the request in its native protocol and opens a socket to a remote server, so no anticipation of any independent claim; § 103 background.

(c) US 5,623,601 — Vu (Milkway Networks Corp.) — most relevant to the "transparent proxy" core

• Full citation: US 5,623,601 A, "Apparatus and method for providing a secure gateway for communication and data exchanges between networks," Hung T. Vu, Milkway Networks Corporation.
• Dates: filed 1994-11-21 (App. 08/342,772, per uspto.report); issued 1997-04-22. Flag: the Google front-page "cited by" table in the provided text shows 1994-11-18; uspto.report shows 1994-11-21. I have not corrected either — both precede the ’141 filing, so § 102(e) status is unaffected.
• Description: A firewall gateway station with a modified OS kernel. It "transparently initiate[s] a first communications session with a client … and a second independent communications session with the network host," and application-level proxies relay the data between the two sessions. Client users issue native commands ("telnet host") that appear to execute as if no gateway existed. Customized proxies bind to standard ports, and a generic proxy bound to an arbitrary port (59813) handles any service for which no dedicated proxy exists.
• § 102 status: § 102(e) (US filing 1994 precedes applicant's filing; issued 1997, after).
• Claims potentially affected: Strongest reference for the transparent-intermediary limitations — claim 1 / 13 ("establishes the requested communication … in the native protocol"), claim 11 (bidirectional tunneling through the proxy), claim 21 (proxy "establish[es] the requested communication with the remote server on behalf of the client application"), and claim 25 (bidirectional tunneling). It does not disclose a client-side layered service provider above a transport provider intercepting the request; interception is at the network/kernel boundary. Accordingly it is an excellent § 103 primary reference combined with Firth (b)(e) below, but a standalone § 102 anticipation of claim 1/7/13/17 is doubtful.

(d) US 5,699,513 — Feigen et al. (Motorola, Inc.)

• Full citation: US 5,699,513 A, "Method for secure network access via message intercept," Feigen et al., Motorola, Inc.
• Dates: filed 1995-03-31; issued 1997-12-16.
• Description: A filter intercepts a client's first connection request and routes it to a security host, which holds it unacknowledged; the client then makes a second connection to the security service, authenticates, and the security host releases the first connection request into the inside network. The spec states the security provisions are "transparent to existing client applications."
• § 102 status: § 102(e) (US filing 1995-03-31 precedes applicant's filing).
• Claims potentially affected: Relevant to claim 1/13 (intercepting a communications request) and claim 5 (transparency). However, the client must make an explicit second connection and the interception is at a network filter rather than a client-side LSP, and no transparent-proxy application establishes the connection on the client's behalf in the claimed manner. § 103 background; not a standalone anticipation.

(e) US 5,781,550 — Templin et al. (Digital Equipment Corp.)

• Full citation: US 5,781,550 A, "Transparent and secure network gateway," Templin et al., Digital Equipment Corporation.
• Dates: filed 1996-02-02; issued 1998-07-14.
• Description: By title and front-page data, a gateway that transparently provides secure connections between a client and an external network. (Retrieval note: I obtained only the bibliographic/front-page data for this reference — the full-text fetch exceeded the search-step limit — so the description relies on the title and metadata, not verified column text.)
• § 102 status: § 102(e) (US filing 1996-02-02 precedes applicant's 1996-12-20 filing; issued after, so not § 102(a)/(b)).
• Claims potentially affected: The "transparent … gateway" framing is directly on point for the transparency limitations of claims 1, 7, 13 and the proxy-side claim 21. Caution: because I could not verify the full text, I do not assert that it discloses a client-side layered service provider; treat this as a candidate § 102(e)/§ 103 reference requiring full-text confirmation.

(f) US 5,826,014 — Coley et al. (Network Engineering Software)

• Full citation: US 5,826,014 A, "Firewall system for protecting network elements connected to a public network," Coley et al., Network Engineering Software.
• Dates: filed 1996-02-06; issued 1998-10-20.
• Description: A firewall system using proxy components to protect network elements connected to a public network. (Same retrieval caveat as (e): front-page/metadata only.)
• § 102 status: § 102(e) (US filing 1996-02-06 precedes applicant's filing).
• Claims potentially affected: Proximity to the proxy-side claims 21–24, especially claim 24 (determining whether a protocol filter corresponds to the native protocol and applying it) — firewall/proxy systems commonly apply protocol- and port-based filters. Not a standalone anticipation of claims 1/7/13/17, which require the client-side LSP.

(g) US 5,987,517 — Firth et al. ([Microsoft Corp.](/litigations/by-plaintiff/Microsoft%20Corp.)) — most relevant to the "layered service provider" element

• Full citation: US 5,987,517 A, "System having a library of protocol independent reentrant network interface functions for providing common calling interface for communication and application protocols," Firth et al., Microsoft Corp.
• Dates: filed 1996-03-27; issued 1999-11-16.
• Description: A library of protocol-independent, reentrant network interface functions providing a common calling interface between applications and lower-level transport/communication protocols — i.e., a generic application/transport interface layer that sits between the application and the transport protocols. (Same retrieval caveat: metadata only.)
• § 102 status: § 102(e) (US filing 1996-03-27 precedes applicant's filing; issued 1999, after).
• Claims potentially affected: Closest to the structural heart of claim 1 / 13 / 17 — the "layered service provider above a transport service provider in a stack" — and to claims 18–19 (Winsock TCP/IP stack / Windows OS environment, since a protocol-independent reentrant interface library is the architectural antecedent of the Winsock 2 service-provider interface). It does not teach proxying to a remote server, so it cannot alone anticipate; it is the ideal § 103 combination partner with Vu or Templin.

---

3. Non-patent literature (front page)

• Rolf Oppliger, "Internet security enters the Middle Ages," IEEE, Oct. 1995, pp. 100–101. → Published Oct. 1995, i.e., before the 1995-12-20 § 102(b) critical date → § 102(b) printed publication. Survey of Internet security/firewall approaches; background for the security/proxy framing, not an anticipation of the LSP-plus-transparent-proxy claims.
• Steven Bellovin et al., "Network Firewalls," IEEE Communications Magazine, Sep. 1994, pp. 50–57. → Published Sep. 1994, before the critical date → § 102(b). The classic firewall taxonomy that describes application-level (proxy) gateways; relevant background to claims 21–24 (proxy-side) and to the "transparent gateway" concept, but does not disclose the claimed client-side layered service provider.

---

4. Synthesis — most relevant prior art and claim impact

Ranking of relevance:

Bottom line on § 102: The likely prosecution posture is that no single cited reference anticipates the independent claims. The transparency element is best evidenced by Vu (’601) and Templin (’550); the layered-service-provider-above-the-transport-provider element is best evidenced by Firth (’517) (with Brandle (’699) as corroboration of the intercept/determine/forward pattern). The likely validity challenge would therefore be a § 103 combination of Vu (or Templin) + Firth, with Coley, Feigen, and Duxbury supplying secondary teaching, and Bellovin/Oppliger as § 102(b) background. This is consistent with the earlier "Litigation summary" section's finding that the ’141 patent is presently used only as prior art against third-party patents (e.g., as Exhibit 1063 in IPR2014-00237/00238), not asserted against anyone.

---

5. Uncertainties and flags

• § 102(e) "invention date" nuance (pre-AIA): For this 1996-filed application, § 102(e) is measured against the applicant's invention date. I have treated the invention date as on/before the 1996-12-20 filing date, which is the standard assumption absent contrary evidence; if an earlier conception date were established, only the two references issued before that date would remain § 102(a)/(b) art. All six post-1993 references still have US filing dates before 1996-12-20, preserving their § 102(e) status.
• Full-text not verified for four references. I retrieved full text for US 5,218,699, US 5,604,896, US 5,623,601, and US 5,699,513. For US 5,781,550, US 5,826,014, and US 5,987,517 I obtained only front-page/metadata (searches for these three returned the "maximum number of steps" notice). The descriptions in items (e), (f), and (g) therefore rely on title and bibliographic data, and their claim mappings should be confirmed against column text before being relied upon.
• Vu filing-date discrepancy (1994-11-18 vs. 1994-11-21) reported, not corrected (per the literal-identifier rule); immaterial to § 102(e) status.
• US 5,218,699 filing-date discrepancy (1989-08-24 vs. the radaris "Jun 8, 1992"/app. 07/895,221) reported, not corrected; immaterial since the ’699 patent issued 1993-06-08 and is § 102(b) art regardless.
• Consistent with the earlier section, the "no 2026 CAFC litigation involving the ’141 patent" finding stands; this prior-art analysis does not change it.

I'll ground this obviousness analysis in the actual prior-art references listed on the '141 front page. Let me verify their disclosures.

Let me verify the remaining references (Coley, Brandle, Duxbury) and the Bellovin/Oppliger NPL.

Obviousness Analysis — US 6,182,141 ("Transparent proxy server") under 35 U.S.C. § 103

Built on the previously generated summary and litigation sections; those sections are not repeated. Cross-references and one flagged consistency note appear at the end.

---

0. Scope, method, and evidentiary grounding

This analysis uses only the references cited on the face of the '141 patent (the seven U.S. patents and two IEEE non-patent items listed in the "Prior Art section of this page"), plus what each reference's own text discloses. I verified the disclosures of the three most important references (Templin, Vu, Feigen) and of Firth and Coley by direct retrieval; I flag below where I could not independently verify full text (Brandle, Duxbury) and where I rely only on title/abstract-level content.

Prior-art status (for a 1996-12-20 critical date) — this matters because four references issued after the '141 filing and therefore are not § 102(b) art against it:

All four post-filing references preceded the '141 filing date in the U.S., so each is available at least as § 102(e) art. The two NPL items are the same references the '141 specification itself uses to frame the "background" problem.

POSITA (Dec. 1996): a person with a B.S. in CS/EE (or equivalent) and roughly 2–4 years of experience writing TCP/IP and socket/network-API code on a Microsoft Windows platform, familiar with the Winsock service-provider architecture then being standardized, with working knowledge of firewalls, application gateways/proxies, DNS/name resolution, and remote-access (dial-up) stacks. This is not an unusually high skill level; the '141's own specification treats Winsock 2.0, the layered-provider concept, well-known ports, and IANA registration as routine background knowledge.

---

1. The claim-1 element set and where each prior-art reference lands

Claim 1 (from the issued text) requires: (a) interception of a client application's communications request in its native protocol, by a layered service provider above a transport service provider in a stack; (b) the LSP determining whether the request is directed to a remote server; and (c) if remote, the LSP packaging and forwarding the request to a transparent proxy application that receives the request in the native protocol and establishes the requested communication with the remote server.

Net reading: every element of claim 1 except the client-side, in-stack, above-the-transport-provider location of the interceptor is taught expressly by Vu (proxy behavior, native protocols, no client reconfiguration, bidirectional tunneling, designated-port listener) and/or Templin (in-stack interception, diversion to an application-layer proxy, payload-unchanged forwarding). The single genuine point of novelty over the cited art is where the interception sits — a layered provider above the transport provider on the client, rather than in a gateway's kernel/Internet layer.

That is precisely the element that Firth supplies.

---

2. Primary combinations

Combination A — Vu (US 5,623,601) + Firth (US 5,987,517)

Why Vu as the base: Vu is, of the cited art, the strongest teaching of transparent proxying. Its abstract states the gateway "transparently initiate[s] a first communications session with a client … and a second independent communications session with the network host," with "application level proxies" passed the packets by a modified kernel, producing "a transparent firewall." Vu's own background criticizes prior application-level firewalls because they "are not transparent to the user" and require client-side changes (the Telnet-firewall example) — i.e., Vu expressly identifies and solves the same transparency problem the '141 states in its background. Vu even discloses a dedicated proxy bound to a designated port (59813) handling any service for which no specific proxy exists, which corresponds to claim 1's "transparent proxy application" and to claim 13's "predetermined well-known port."

Why Firth: Firth teaches interposing a layered library of networking functions between the client application and the transport, callable by multiple applications and protocol-independent. A POSITA reading Vu together with Firth would understand that the interceptor Vu implements in a gateway kernel can equivalently be implemented in Firth's client-side layered networking layer.

Gap and why it closes: Vu's interceptor is the gateway kernel; Firth's is a client-side layer. Substituting one interposition point for another, where both are known in-stack interception points, is the kind of predictable substitution KSR recognizes. The motivation is supplied by Vu's own stated goal (transparency without client reconfiguration) plus Firth's stated goal (a shared client-side networking layer usable by many applications). Result: claim 1, and by extension claims 7, 13, 17, 21, obvious.

Motivation to combine (KSR factors):

• Same field, same problem: both address transparent network access without modifying existing client/server applications.
• Known technique applied to known problem: layering/interposing a networking service provider was, as of Dec. 1996, the routine Winsock mechanism; the '141 specification itself treats it as such.
• Predictable result: moving interception to the client layer yields the expected benefit (no per-application proxy configuration) with no unexpected behavior.

Combination B — Templin (US 5,781,550) + Firth (US 5,987,517)

Why Templin as the base: Templin expressly claims and describes a transparent gateway in which "the Internet layer intercepts the packet, and diverts the packet to the transport layer," which "associates the diverted packet with a proxy server operating in the application layer," and in which the proxy "generat[es] a new packet … [with the] first payload unchanged." This tracks claim 1's "packages and forwards" + "receives in the native protocol" language almost term-for-term. Templin also distinguishes local vs. non-local destinations by netid, supporting the claim-1 determination and dependent claim 6.

Why Firth: same role as in Combination A — supplies the client-side layered networking-function module that yields the "layered service provider above a transport service provider in a stack" limitation.

Gap and why it closes: Templin's interceptor is in the gateway's stack; the '141 recites it in the client's. Relocating an in-stack divert-and-proxy mechanism from a gateway stack to a client stack, using the client's own layered provider facility, is a predictable architectural move, especially where the goal is a small network (single ISP account) rather than an enterprise firewall.

Combination C — Coley (US 5,826,014) + Firth (US 5,987,517)

Coley teaches a firewall whose proxy agents are "specifically assigned to an incoming request in accordance with the service protocol (i.e., port number)" and "complete[] the connection to the protected network element on behalf of the source." This supplies claim 1's authorized-proxy-on-behalf-of-source behavior and directly supports dependent claim 24 ("protocol filter corresponding to a native protocol"). Combined with Firth for the client-side layered provider, the same claim-1 result follows.

Combination D — Feigen (US 5,699,513) as the express "motivation" reference

Feigen is important less as an anticipation-style base and more as the articulated motivation for the '141's central design choice. Feigen states that existing client/server applications "do not accommodate communication through a proxy," and that its intercept scheme makes "security provisions … transparent to existing client applications," such that "the user may use any client application." That is exactly the problem the '141 frames in its background ("client programs need to know how to contact the proxy server") and solves via the LSP. Feigen therefore supplies the reason a POSITA would have been motivated to combine a transparent proxy (Vu/Templin/Coley) with a client-side interception layer (Firth): to avoid forcing every client application to be proxy-aware.

Combination E — NPL: Bellovin & Cheswick + Oppliger, combined with Vu/Templin/Coley + Firth

Bellovin & Cheswick ("Network Firewalls," IEEE Communications Magazine, Sep. 1994) and Oppliger (IEEE, Oct. 1995) are the survey/background references the '141 itself uses. They describe the tradeoff between packet filters (transparent, but coarse and protocol-blind) and application-level proxies (robust, but not transparent and requiring modified clients). A POSITA reading those surveys would be directly motivated to seek a transparent mechanism that preserves native-protocol handling — i.e., to combine Vu's transparent proxy with a client-side layering approach. These NPL items reinforce the motivation element rather than supplying missing structure.

---

3. Dependent claims

Dependent-claim conclusion: claims 2, 4–6, 8–12, 14–15, 18–21, 23–25 are obvious over the combination(s) above with a high degree of confidence. Claim 3 (and its analogues 9, 15) is the weakest, because I found no cited reference expressly disclosing a layered name-space service provider stub; the case there depends on treating Winsock name-space layering as routine design knowledge.

---

4. Why a POSITA would have combined these references (KSR synthesis)

1. Common problem, common field. All four principal references address granting a protected/local host access to a remote/public network without modifying the client application. Vu, Templin, Feigen, and Coley each state this goal in their backgrounds.
2. Express motivation in the art itself. Feigen states that existing applications do not accommodate proxies and are made transparent instead. Vu criticizes prior application gateways for requiring client changes. Bellovin/Oppliger frame the transparency-vs.-security tradeoff. This is articulated motivation, not hindsight.
3. Predictable, known technique. Winsock-layer interposition (a service provider between the application and the transport provider) was the standard Windows mechanism as of the '141 filing; the '141 specification itself describes Winsock 2.0 and layered service providers as the implementation substrate. Applying a known interposition technique to a known transparent-proxy design is a predictable combination.
4. No unexpected results. The '141's asserted advantages (no client proxy configuration; native-protocol handling; no protocol-specific proxy code; local pass-through) are each exactly the advantages Vu, Templin, and Feigen already attribute to their transparent designs. Nothing in the '141 record suggests a result beyond the predictable aggregation of these known benefits.

Under Graham v. John Deere and KSR v. Teleflex, the strong combination is Vu + Firth, with Templin + Firth and Coley + Firth as alternatives, and Feigen and the two IEEE surveys supplying motivation. Claim 1 (and independent claims 7, 13, 17, 21) would have been obvious.

---

5. Secondary considerations

• No proffered evidence of nexus. The record I could reach shows no secondary-considerations evidence tied to the '141 claims (no commercial-success/nexus showing, no licensing program identifiable as a proxy for validity, no long-felt-need narrative beyond the specification's own background).
• Status reduces the practical stakes. As established in the earlier sections, the patent is Expired – Lifetime (anticipated expiration 2016-12-20) and I found no assertion/litigation in which the '141 is the asserted patent. Secondary considerations are moot for an expired, unasserted patent, but I note the absence of any evidence that would rebut the § 103 case.
• Caution: secondary-consideration evidence, if it exists, would live in litigation/PTAB files or Intel licensing records I could not query (PACER/Docket Alarm/Lex Machina behind paywalls), so this is a negative search result, not a proven absence.

---

6. Weaknesses, uncertainties, and honesty flags

1. The "layered service provider above a transport service provider in a stack" limitation is the crux, and it is the one element not squarely in the cited art. Firth / US 5,987,517 is a client-side library of protocol-independent reentrant networking functions — not, on its face, a Winsock SPI interceptor that hijacks an existing application's socket calls. A skilled advocate could argue Firth is an application-facing helper library (application voluntarily links to it), whereas the '141 LSP intercepts unmodified applications' calls. If so, Firth alone may not teach the limitation, and the combination would need to lean on the proposition that Winsock service-provider chaining was routine knowledge as of Dec. 1996. This is the most attackable part of the § 103 case.
2. Unverified references. I did not independently retrieve the full specifications of Brandle / US 5,218,699 and Duxbury / US 5,604,896; their role above is corroborative only, based on title/abstract-level content. Their § 102 status (especially Duxbury's filing date) is likewise unverified.
3. Vu's "port 59813" is not literally a "well-known port." Vu calls 59813 an "arbitrary assignment," whereas claim 13 recites a "predetermined well-known port." This is a wording mismatch that slightly weakens a literal claim-13 mapping to Vu, though Vu's designated-port listener still supplies the concept.
4. Claim 3/NSP-stub remains the weakest dependent claim for the reasons in § 3.
5. Note on the '141's own admissions. The specification expressly concedes that proxies, well-known ports, IANA registration, Winsock layering, and DNS resolution were all known — admissions that a POSITA would have had all the building blocks in hand, strengthening the obviousness case.

---

7. Cross-reference / consistency check with earlier sections

• No contradiction with the earlier summary and litigation sections: this analysis is consistent with the earlier finding that the ’141 was cited only as prior art (e.g., Exhibit 1063 in IPR2014-00237/00238 against VirnetX's US 8,504,697), that it is expired, and that no litigation asserting it was found. The "no litigation found" caveat from the earlier sections also governs here.
• The earlier sections' B1 vs. B2 label discrepancy (searchlight.law) and the 1996-12-19 vs. 1996-12-20 priority discrepancy are unchanged and do not affect this § 103 analysis; I use the authoritative 1996-12-20 date and B1 label, per the literal-identifier rule, without correcting the third-party entries.
• One item worth flagging: the earlier summary lists the seven cited references by name; this section adds the § 102 category for each and identifies Firth / US 5,987,517 as the decisive reference — a point the earlier sections did not develop, because they addressed bibliographic and litigation data rather than the merits.

Bottom line: Independently and in combination, US 5,623,601 (Vu) and US 5,781,550 (Templin) disclose transparent, native-protocol proxying with designated-port proxy listeners and bidirectional tunneling; US 5,699,513 (Feigen) and the Bellovin/Cheswick and Oppliger surveys supply the express motivation to make proxying transparent to unmodified client applications; and US 5,987,517 (Firth) supplies a client-side layered networking-function module above the transport. Their combination renders claim 1 — and, with high confidence, claims 2, 4–8, 10–25 — obvious under § 103. The residual risk concentrates entirely in the "layered service provider above a transport service provider" limitation and in dependent claim 3's name-space-provider-stub element.

Primary source URLs verified for this analysis:

• https://patents.google.com/patent/US5781550 (Templin)
• https://uspto.report/patent/grant/[5623601](/patent/5623601) and https://patents.google.com/patent/US5623601 (Vu)
• https://patents.google.com/patent/[US5699513A](/patent/US5699513A) and https://uspto.report/patent/grant/[5699513](/patent/5699513) (Feigen)
• https://uspto.report/patent/grant/[5987517](/patent/5987517) and https://patentimages.storage.googleapis.com/3c/ea/47/67c3bd3164783d/US5987517.pdf (Firth)
• https://patents.google.com/patent/[US5826014A](/patent/US5826014A) (Coley)
• https://patents.google.com/patent/US6182141/en (the '141 itself)