US 5941988

I'll search for this specific patent number, including any litigation/litigation-docket activity.

Let me run more targeted searches on the USPTO record and any litigation mentions.

Summary — US Patent 5,941,988

Important search limitation up front: I could not directly query the USPTO Patent Center/PAIR or the Federal Circuit's own docket system — my access is limited to web search. Multiple targeted searches (including "5,941,988" Federal Circuit, 5941988 patent CAFC 2026 docket, and "5,941,988" patent litigation OR infringement OR complaint) returned no 2026 CAFC docket activity and no litigation involving this patent number. The only hits at that number were (a) the Google Patents/USPTO record itself, (b) a citation of it in third-party patents/search reports, and (c) an unrelated Japanese grant, JP‑5941988‑B2 (tobacco flavor-component carrier) — the same eight digits, different jurisdiction and different invention. Do not conflate them. Treat "no litigation found" as absence of evidence from my searches, not as a verified negative.

Bibliographic data (per the Google Patents/USPTO record)

Abstract (as recorded)

A method of merging two separate TCP connections terminating at a common host and "gluing" them into a single connection between two end systems, where the single connection preserves TCP end-to-end semantics. The technique retains the session setup functions of the transport layer proxy but pushes the data copying into kernel space to improve relay efficiency. A byte stream arriving on one end of the split connection is mapped directly into the sequence number space of the other split connection. The gluing operation involves updating a subset of TCP/IP header fields — source and destination addresses, port numbers, sequence numbers, and checksum — on-the-fly as packets are relayed.

Plain-language overview of each independent claim

Seven claims are independent: 1, 7, 17, 24, 25, 26, and 31 (2–6 depend from 1; 8–16 from 7; 18–23 from 17; 27–30 from 26; 32–38 from 31; claim 24 and 25 stand alone).

• Claim 1 — core "gluing" method. Two connections both end at a common host (a proxy). At that host, the proxy rewrites the headers of packets arriving from the first endpoint so they look like packets belonging to the second connection, and forwards them; it does the symmetric rewriting for packets arriving from the second endpoint. The header modification happens on-the-fly as packets arrive. This is the broadest, most generic statement of the invention.

• Claim 7 — firewall-proxy method. Narrows to the firewall setting: a proxy on a firewall host that mediates between a protected local host and an outside remote host. Steps: (a) reject connections from unapproved hosts and terminate connections failing authentication/authorization; (b) an approved local host connects and names the remote host; (c) the proxy rewrites headers of packets from the local host so they appear to come from the proxy and forwards them out; (d) it does the same in reverse for packets from the remote host; (e) it repeats this for every packet of that connection; and (f) any packet arriving that is not part of an authorized/authenticated connection is treated as an attempted security violation.

• Claim 17 — TCP session-layer-proxy method, four functional steps. Enable synchronization between the two end systems and the proxy; map the TCP sequence space of one end system onto the other; as each TCP segment arrives, modify its header information to address it to the other end system; and tear down the glued connection when it is closed. This is essentially the four-part solution described in the specification (synchronization, mapping function, header modification, tear‑down).

• Claim 24 — splicing method at a session-layer proxy. A first and a second connection terminating at first and second hosts are spliced into a single end-to-end connection at a session-layer proxy by (i) enabling synchronization between both hosts and the proxy and (ii) modifying headers of packets on each connection to correspond to the headers of the other connection, with header modification done on-the-fly at the proxy. (Note: the claim text as published contains a minor antecedent/typographical irregularity in its preamble — the phrase "at a session layer proxy" is appended mid-sentence — but the recited elements are as above.)

• Claim 25 — the only system/apparatus claim. A packet communications network comprising: a local host on a local network; a network firewall protecting that network; a remote host reachable by the firewall; and a session layer proxy running on the firewall with the right to send/receive data across it, acting as mediator. The proxy enables synchronization between the local host, the remote host, and itself, and is operative to modify headers of packets of the local-host/firewall connection to correspond to headers of the remote-host/firewall connection, on-the-fly as packets are received.

• Claim 26 — firewall-host method, security-framed. Substantively parallel to claim 7 but drafted as a method implemented on the network firewall: reject unauthorized connections; approved local hosts connect and specify the remote address; the proxy rewrites headers in both directions so packets appear to originate from the proxy; repeat for every packet of the connection; and treat any packet not part of an authorized/authenticated connection as a security violation. (Claim 26 does not itself recite "on-the-fly" header modification; that language appears in its dependent claim 30 and in claim 28's address/port/sequence/checksum rewrite list.)

• Claim 31 — "glue after data exchange" method. A method of gluing two TCP connections (remote host↔proxy and local host↔proxy) that expressly permits arbitrary data to be exchanged first on each connection, then gluing them together, after which packets sent to the proxy by either side are altered and forwarded to the other side. This claim captures the specification's point that gluing need not occur immediately after setup.

Notes and uncertainties

• Technical content is well corroborated. The disclosure is the "TCP glue" / TCP-splicing technique in which the proxy acts as a "layer 3.5 router": sequence-number remapping seq_num = (seq_num_in − glue_irs) + out_glue_iss and ack_num = (ack_num_in − glue_iss) + out_glue_irs, with base points glue_irs = rcv_nxt and glue_iss = snd_nxt. The inventors' related publication "TCP Splicing for Application Layer Proxy Performance" (Maltz & Bhagwat, Mar. 1998) is cited as prior art against later patents.
• Claim construction caveats. The specification is framed around SOCKS v4/v5 (authentication, CONNECT/BIND) and HTTP caching proxies, but the claims are written generically ("session layer proxy," "packet communication network"), and the specification expressly extends the concept to OSI, XNS, Novell, Netbios, and IPX.
• Termination. The patent expired around 2017‑01‑27 (20 years from filing; the record shows no term extension). Any 2026 litigation over this patent would be legally notable, since an expired patent cannot be infringed prospectively (damages would be limited to the pre-expiration period).
• What I could not verify. I found no Federal Circuit or district court docket entry naming US 5,941,988, and I could not independently confirm current USPTO fee/status entries beyond the "Expired – Fee Related" designation shown in the aggregated record. If a 2026 CAFC docket item is the specific target of your request, I would need to be pointed to a case name or docket number, because the number-only searches did not surface one.

Sources: Google Patents, https://patents.google.com/patent/US5941988/en (full text, claims, classification, legal events); Plainsite patent assignment record, https://www.plainsite.org/patents/assignment.html?id=[1336903](/patent/1336903) (Reel 8433/Frame 0837, executed 1997‑01‑27).

I'll research litigation involving US Patent 5,941,988. Let me search multiple sources.

Let me refine with more targeted searches.

Let me search more specifically in litigation databases.

Summary Finding

I found no litigation involving U.S. Patent No. 5,941,988.

Based on multiple searches of patent-focused sources, litigation aggregators, and general web indexes, I could not identify any federal district court case, ITC investigation, PTAB post-grant proceeding, or Federal Circuit appeal in which U.S. Patent 5,941,988 ("Session and transport layer proxies via TCP glue") was asserted, challenged, or otherwise at issue.

To be explicit about the limits of my confidence: I could not directly query PACER, Docket Navigator, Lex Machina, or the Unified Patents litigation caselist (the searches against those specific endpoints returned no relevant records within my tool budget). So this is a "no known litigation found" conclusion rather than a certified negative. If you need a legal-grade clearance, a PACER/Docket Navigator run on the patent number is advisable.

What the searches did return (and why it is not litigation)

False positives I deliberately excluded (per your "do not return results for similar numbers" instruction):

• U.S. 8,894,988 — Purdue Pharma OxyContin patents (e.g., Purdue Pharma L.P. v. Amneal Pharmaceuticals, 1:17-cv-00210-RGA, D. Del.) — different patent by ~3 million numbers.
• 42 U.S.C. § 1988 — civil-rights attorney-fee statute in R&W / Unity Ventures-type fee opinions — not a patent.
• U.S. 4,538,188 — Lex v. Ulead video-composition patent — different number.
• U.S. 10,820,117 / 10,659,885 — Taction Technology v. Apple (haptic feedback) — different numbers entirely, from the 2026 news cycle.

Related context (not litigation)

• Priority/filing date: 1997-01-27; grant: 1999-08-24; assignee IBM.
• Related family member: Korean counterpart KR100255501B1 ("How to Improve Session and Transport Layer Proxies with Transport Control Protocol Glue"), filed 1997-11-19, claiming the same 1997-01-27 priority. No litigation on the KR member surfaced either.
• Status: Google Patents records the U.S. patent as "Expired – Fee Related," with anticipated expiration 2017-01-27 (20-year term). A patent that expired in 2017 cannot be asserted in new infringement litigation, which materially reduces the likelihood of any recent or ongoing cases.
• Technical significance: This patent is widely regarded as an origin point for TCP splicing / "TCP glue" (kernel-level splicing of two TCP connections by on-the-fly header modification of a subset of TCP/IP fields). It is heavily cited by later patents (the Google Patents "Cited By" list runs to 282 entries) — citations, however, are prior-art references and are not evidence of litigation.
• One of the inventors, Pravin Bhagwat, later appears on U.S. 7,139,268 ("Performance of intermediate nodes with flow splicing") in the cited-by list — again, a citation, not a case.

Bottom line

No known litigation involving U.S. Patent 5,941,988. The only public records located for this number are its issuance, its assignment to IBM, its Korean family member, and its use as prior art cited by later patents.

If you want me to keep digging, the next best steps would be: (1) a direct Docket Navigator / Lex Machina "patent number → cases" report, (2) a PACER "party" search on "International Business Machines" filtered for 1999–2017, and (3) a USPTO Patent Center "Litigation" / maintenance-fee event history review to confirm the exact lapse date and any § 1.985 litigation notifications.

I want to flag one uncertainty plainly: because I could not reach the dedicated litigation portals in this session, I cannot rule out a low-profile, short-lived, or settled case that never generated a searchable web record. The statement above is "no litigation found," not "litigation provably never existed."

I'll verify the structured data against live sources before concluding.

No PTAB proceedings found. Detail below, with the verification trail and the two non-PTAB issues that matter more for a defendant anyway.

Proceedings overview

Total AIA trial proceedings on file: 0 — 0 active, 0 claims invalidated, 0 claims sustained, 0 settled, 0 institution denials (USPTO ODP ingest returns no AIA trials; my independent web/PTAB-document searches surfaced none either). The defensive posture is therefore "nothing decided, nothing estopped, and nobody has ever bothered to attack this patent at the Board" — but that is far less important than the patent's own paper status: US 5,941,988 reached its anticipated 20-year expiration on 2017-01-27, so a 2026 assertion runs straight into a § 286 damages bar long before it runs into any validity fight.

Per-proceeding detail

None to report. There is no IPR####-#####, PGR####-#####, or CBM####-##### number to populate here, and I will not manufacture one.

Near-miss verifications (so you know the zero is real, not a retrieval gap):

Two things I could not verify and would confirm directly in USPTO PatentCenter for application 08/789,447 before relying on them:

1. Maintenance-fee history. Google Patents carries the legal-status label "Expired – Fee Related" alongside "2017-01-27 Anticipated expiration." If the 11.5-year maintenance fee was paid in 2011, that is simply full-term expiration. If it lapsed earlier, the patent died earlier still and the § 286 analysis below gets more favorable, not less. Pull the fee record.
2. Pre-AIA reexamination. Inter partes reexamination (pre-AIA § 311) was never an "AIA trial" and wouldn't appear in ODP's trial data. No reexamination certificate appears in the family, but check the Post-Issuance tab to close the loop.

Strategic summary

Claim status: all 38 claims are UNTESTED. No claim of US 5,941,988 — not independent claim 1 (the core "gluing" step of modifying headers on-the-fly at the common host), not claim 17 (the four-part session-layer-proxy method: synchronize, map sequence space, modify headers, tear down), not claim 24 (splicing at a session layer proxy), not claim 25 (the apparatus claim to the firewall-resident proxy system), not claim 31 (gluing after arbitrary pre-glue data exchange) — has ever been canceled, confirmed, or construed by the Board. There is also no motion-to-amend history, so there are no substitute claims. If a demand letter or complaint cites claims 1–38, nothing in the PTAB record undercuts a single one of them; conversely, nothing in the PTAB record hardens them either.

Estoppel landscape: empty on both sides. Because no IPR/PGR/CBM was ever instituted, no petitioner is burdened by § 315(e)(2), and no patent-owner-side estoppel or adverse-judgment baggage attached to the claims. Practically, that means a defendant today faces no § 315(a)/(b) traps from prior petitioners — but also that a defendant would be the first to test the claims, bearing full institution risk with no prior panel reasoning to lean on. Two statutory points limit what a defendant could even bring: IPR remains available for an expired patent but is restricted by § 311(b) to § 102/§ 103 grounds on patents and printed publications, so § 112 and § 101 arguments are unavailable in an IPR; PGR is unavailable because the application was filed 1997-01-27 (PGR reaches only first-inventor-to-file patents filed on/after 2013-03-16); and CBM is unavailable both because the program sunset on 2020-09-16 (37 C.F.R. § 42.300(d)) and because this disclosure is almost certainly a "technological invention" outside § 18's financial-services scope. Validity here is governed by pre-AIA §§ 102/103, and any IPR ground must be built from pre-1997 art — which is plentiful (the specification itself concedes that SOCKS and user-space TCP proxies were known, and the patent's own background section is a § 102(b) roadmap).

Pattern signals: none. No serial petitioner, no defensive aggregator (the Unified Patents hits my search returned are for the unrelated '932 patent in Unified Patents v. [PO], IPR2022-01125), and no IBM appeal to the Federal Circuit on this patent. That is a genuine negative signal: this patent belongs to the TCP-splicing generation that was superseded commercially, and IBM's enforcement activity in this space ran through other assets — e.g., the PRODIGY-era '849 patent litigated against Priceline/Booking, Kayak, and OpenTable (CAFC No. 18-1574) and the ITC/ASUS action on the '829/'741/'852 patents — not through the '988. Note for awareness only: co-inventor Pravin Bhagwat is the named inventor on a subsequent, related flow-splicing asset, US 7,139,268 ("Performance of intermediate nodes with flow splicing," filed 1999-01-29), which appears in this patent's cited-by list; that is a different patent with a different owner and its own (now-lapsed) term, and it is not part of the 5,941,988 family.

The decisive point is not validity — it's the calendar. The patent expired 2017-01-27. Section 286 caps damages at six years before suit; a complaint filed on or after 2023-01-27 reaches back only to acts after 2017-01-27, and there is no such window left. A demand letter invoking this patent in 2026 is asking for royalties on an expired right with no recoverable past-damages tail.

Recommended next steps

1. Do the date math before anything else. Confirm the expiration date and maintenance-fee history in PatentCenter for application 08/789,447, then run the § 286 six-year lookback against the filing date of whatever complaint or demand you're facing. If the last arguable infringing acts predate the lookback, the correct response is a short non-infringement/expiration letter, not an IPR.
2. If suit is filed anyway: move on § 286 (no recoverable damages for pre-lookback conduct), and consider whether subject-matter jurisdiction for a DJ counterclaim on an expired, unassertable patent survives — a live controversy requires a concrete damages exposure.
3. If past damages are somehow in play (e.g., an earlier-filed case you've been pulled into), an IPR is theoretically still available on an expired patent, but weigh it honestly: you'd be buying a ~$250k–$500k trial for claims that can only support a shrinking pre-2017 royalty base. Marking/notice (§ 287) and laches-style equitable defenses are cheaper first moves.
4. If you do petition: § 315(b) gives you one year from service of the complaint. Grounds must be pre-AIA § 102/§ 103 on patents and printed publications only — no § 112, no § 101. Start from the patent's own background section (SOCKS, user-space proxy data copying) as the admitted prior art.
5. Re-verify nothing changed: the PTAB record is clean as of the ODP ingest date, but search PTAB E2E and the PTAB decisions page again before you file anything that asserts "no IPR exists."

Bottom line for a defendant: there is no PTAB outcome to leverage or fear — but you likely don't need one. This is a 1997 priority, 1999-issued, fully expired patent with no IPR, no reexam, no CAFC history, and no live damages window. Treat a 2026 assertion as a records-and-dates problem first, and a validity problem only if the dates somehow don't close the door.

I'll start by pulling the authoritative assignment data and cross-referencing sources.

Found the key recording (8433/837). Now let me verify details and check for any post-issuance transfers.

Ownership record — US 5941988 "Session and transport layer proxies via TCP glue"

Data-access note up front: the USPTO Assignment Center UI (https://assignmentcenter.uspto.gov/, mirrored at https://assignment.uspto.gov/patent/index.html) is not directly queryable from my tools. The facts below come from (a) the authoritative full text of the patent as provided, and (b) public indexes that mirror the USPTO Patent and Trademark Assignment System (PTAS) record for this patent. Where a field was not returned by any retrievable source, I say so rather than filling it in.

Inventors

Pattern observed — departure from assignee: both inventors left IBM for other employers (Bhagwat → AT&T/AirTight → Mojo/Arista; Maltz → Microsoft). I could not establish precise departure dates, so the specific "all inventors gone within 12 months of filing" trigger cannot be confirmed or ruled out from the evidence retrieved — mark unclear. Note that in this case the departure pattern did not precede a portfolio sale: the patent stayed with IBM (see below).

Related follow-on filing worth noting: US7139268B1, "Performance of intermediate nodes with flow splicing," filed 1999-01-29, naming Pravin Bhagwat — a continuation of this research thread filed two years after US 5941988. It appears in Google Patents' "Cited By" list for this patent.

Original assignee

International Business Machines Corporation (recorded on the assignment document as "IBM Corporation"), Armonk, New York 10504 — a New York corporation.

• Primary line of business: enterprise computing, software, cloud, and services; IBM is a perennial top-three US patent recipient and runs one of the largest corporate patent-licensing programmes in the world.
• Did IBM ship a product embodying the claims? Indirectly, yes — the patent's own specification describes the technique applied to SOCKS firewall gateways and HTTP caching proxies, and the inventors' March 1998 IBM Research Report (RC-21139) reports lab measurements of SOCKS firewalls using TCP Splice at roughly twice the throughput and ~30× lower forwarding latency versus a normal firewall. So IBM clearly built and benchmarked a working kernel-level implementation. I found no evidence of a separately marketed IBM product branded on this feature.
• Current status: operating, publicly traded, no bankruptcy. Still listed as assignee of record.

Assignment timeline

Only the original inventor-to-employer assignment is recorded. There are no post-issuance assignments in the chain.

• 1997-01-27 (executed) / recorded date not returned by any source I could retrieve — Reel 08433 / 0837

  • Conveyance: Assignment — "Assignment Of Assignors Interest" (recorded by PTAS as Assignment of Assignors Interest)
  • Assignor: Bhagwat, Pravin; and Maltz, David A.
  • Assignee: International Business Machines Corporation (officially listed as "IBM Corporation"), Armonk, NY 10504
  • Correspondent: Douglas W. Cameron, IBM Intellectual Property Law, P.O. Box 218, Yorktown Heights, NY 10598 — an IBM in-house IP Law Department address. Not a repeat NPE-filing correspondent. No other recording in this chain, so there is no recurrence to flag.
  • Context: inventor-to-employer assignment, executed the same day the application was filed (USSN 08/789,447) — routine employment-based title vesting, not an acquisition or transfer.

• Superseded/defective earlier recording, date field 1997-01-27 — Reel/frame not returned

  • Conveyance: recorded document flagged by the USPTO index as "INVALID ASSIGNMENT, SEE RECORDING AT REEL 8433, FRAME 0837", same assignors (Bhagwat, Maltz) and same assignee (IBM).
  • Context: a recordation defect corrected by re-recording at reel 08433/0837 — an administrative cleanup, not a change in ownership. Google Patents lists both entries under 1997-01-27. I could not retrieve this record's own reel/frame, so I cannot date the correction precisely.
  • Caveat: I could not verify whether the "invalid" label reflects a defect in the original document or a data-entry error in the initial recording. Either way, IBM's title is unaffected.

Downstream legal status (for completeness, not an ownership event): Google Patents' legal-status label is "Expired – Fee Related," with an anticipated expiration of 2017-01-27 (20 years from filing). I could not verify the maintenance-fee payment history, so treat the reason for expiry as tentative; what is not in doubt is that the patent is long expired and its term has run out.

No records found for any assignment of this patent to Acacia, Marathon, Intellectual Ventures, Wi-LAN/Conversant, Pendrell, Vringo, Round Rock, Innovatio, an Erich Spangenberg vehicle, or any other entity. No litigation naming US 5941988 surfaced in the searches performed; the large "Cited By" list on Google Patents is patent citations only, not assertions.

Timeline diagram

timeline
    title Ownership of US 5941988
    1997 : Filed by IBM inventors Bhagwat and Maltz
         : Assigned same day to IBM reel 08433 frame 0837
    1999 : Patent issued
    2017 : Patent term ends

NPE / troll-pattern signals

1. Shell-entity transfer — not present. The only recorded assignee in the chain is International Business Machines Corporation, a large operating company with a real Armonk, NY corporate address. No LLC/IP-Holdings/Patents-style entity appears at any reel/frame. No Delaware or Texas single-member LLC was recorded.

2. Known asserter in the chain — not present. No recorded assignee matches any public NPE roster (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp, Spangenberg entities), and no entity surfaced via Unified Patents or RPX in the searches run. The single recorded assignee is IBM.

3. Repeat correspondent across the chain — not present. There is only one assignee-side recording, and its correspondent is IBM's own in-house IP Law Department (Douglas W. Cameron, IBM Intellectual Property Law, P.O. Box 218, Yorktown Heights, NY). This is the employer's routine filing channel, not an outside NPE recording specialist. There is no second link, hence no recurrence — and therefore no signal, since the signal requires recurrence. I could not retrieve reel/frame data for the superseded "invalid assignment" record, but it is the same assignor/assignee pair, so it would not change this call.

4. Cascading transfers — not present. Zero post-issuance assignments; no chained LLC transfers at all, let alone within 24 months. There is one link, executed 1997-01-27, and nothing thereafter.

5. Pre-litigation transfer — not present. No assignment postdates issuance, and no infringement suit naming this patent was found, so there is no transfer-within-6-months-of-suit window to evaluate.

6. Bankruptcy fire-sale — not present. IBM has not filed for bankruptcy, and no sale-in-bankruptcy record exists for this patent. (Contrast the Kodak/Nortel/Polaroid pattern — nothing comparable here.)

7. Privateering — not present. No transfer from IBM to an assertion vehicle to litigate on IBM's behalf. IBM's historical patent monetisation has run through direct licensing and, in some later eras, portfolio sales to aggregators — but no such transfer is recorded against this patent.

8. Defensive aggregator (anti-NPE) — not present. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates where it started: at IBM.

Verdict

Insufficient data — the Assignment Center record for this patent consists of only the original inventor-to-employer assignment executed 1997-01-27 and recorded at reel 08433/0837 (plus a superseded/defective earlier recording under the same date that directs to reel 08433/0837). Per the rubric, "only the original assignment" is precisely the insufficient-data case: there is no post-issuance chain to analyse for NPE behaviour. Substance of the finding: there is no evidence of any NPE pattern here. The assignee of record is a large operating company (IBM) that built and benchmarked a working embodiment of the claimed TCP-glue mechanism (IBM Research Report RC-21139, March 1998), the recording correspondent is IBM's own in-house IP Law Department rather than an outside assertion-side filer, and the patent reached the end of its term and is now expired (anticipated expiration 2017-01-27), which moots assertion regardless. Any claim that this patent is or ever was in an NPE chain would require a recorded assignment that does not exist in the public record.

Verification links:

• USPTO Assignment Center (search by patent number 5941988): https://assignmentcenter.uspto.gov/
• USPTO Assignments on the Web mirror: https://assignment.uspto.gov/patent/index.html
• Assignment 8433/837 record (PTAS data mirror): https://www.plainsite.org/patents/assignment.html?id=[1336903](/patent/1336903)
• Google Patents legal events / current assignee: https://patents.google.com/patent/US5941988/en

Open data gaps (flagged rather than guessed): the recording date of reel 08433/0837; the reel/frame of the superseded "invalid assignment" record; the precise departure dates of both inventors from IBM; and the maintenance-fee history underlying the "Expired – Fee Related" status. A direct Assignment Center query and a PEDS/ODP transaction-history pull would close all four.

I'll search for this patent's specifics, including its cited prior art references.

Let me locate the patent's front-page "References Cited" list (the examiner/applicant-cited prior art).

I need the patent's front-page "References Cited" list. Let me pull it from the PDF/front page and corroborate.

Prior‑Art Analysis — US 5,941,988 B1

1. Patent identified (verified, interpreted literally)

The number was searched as given: 5941988. I did not substitute or normalize to any similar number (e.g., I did not conflate it with 5,941,991, 5,940,843, etc.).

Important scoping warning: the Google Patents page reproduces a "Cited By (282)" list. Those are forward citations (later documents citing '988). They are not prior art to '988 and are excluded from the analysis below. The prior art proper is the "References Cited" on the '988 face (+ the specification's own discussion of the art).

2. The prior art of record (face of US 5,941,988)

2a. U.S. Patent Documents (10 references)

§102 date trap you should flag: five of these (5,668,809; 5,692,124; 5,781,715; 5,802,287; 5,848,227; 5,852,721 — six, actually) issued after the 1997‑01‑27 filing date of '988. They can only be prior art under pre‑AIA §102(e) if their U.S. filing (or earliest effective U.S. filing) predates 1997‑01‑27. I could not verify those filing dates in this session, so treat any §102(e) assertion as provisional until the filing dates are pulled from PAIR/Global Dossier.

2b. Other Publications (7 references) — the substantive technical art

Additionally, the specification itself concedes as background: Cheswick & Bellovin, Firewalls and Internet Security, Addison‑Wesley (1994), and states the known state of the art — "All known current transport layer proxies perform the data copying function in user space… a user process waits in a tight loop reading data from one socket and writing it to another one."

3. § 102 anticipation analysis, reference by reference

Standard applied: a reference anticipates under §102 only if it discloses every element of the claim as arranged in the claim. The '988 independent claims each require, in substance:

• (A) two connections terminating at a common host (the proxy), with the proxy itself holding the sockets;
• (B) on‑the‑fly modification of the TCP/IP headers (source/destination IP, ports, seq, ACK, checksum) so packets of one connection are made to look like packets of the other;
• (C) mapping of the TCP sequence space from the incoming connection's space to the outgoing connection's space via glue base points (glue_irs/glue_iss) — claims 5, 17, 29;
• (D) synchronization between end systems and the proxy (client "OK" message / server "ACK suppression") — claims 8, 9, 17, 24, 31/32, 34;
• (E) end‑to‑end semantics preserved (no proxy buffering/termination of the data stream).

Bottom line on anticipation

• No reference of record appears to be a clean §102 anticipatory reference for any independent claim (1, 17, 24, 25, 26, 31). The two clusters of citations serve different purposes: (i) the SOCKS/RFC 1928/Chinitz/Bellovin/Siyan/Parker items are the admitted background that '988 improves upon (and would most plausibly support a §103 obviousness challenge only in combination, and only against the firewall/auth‑related dependent claims 7, 20, 26); (ii) the ten U.S. patents are largely switching / node‑hardware / forwarding art that the examiner apparently cited for the generic notion of forwarding packets between ports.
• The strongest §102 exposure, if any, lies with the ISO/US 5,02x,949 and 5,852,721‑type references against the broadest "two connections at a common host" language of claim 1 / claim 24, and with Chinitz (Snare Works) against the firewall/authentication language of claims 7 and 26 — but only if those references independently disclose per‑packet TCP/IP header re‑writing with sequence/ACK remapping (element (B)/(C)), which the summaries above do not establish.

4. Explicit uncertainty / limitations of this report

• I hit the tool step limit mid‑session; I verified the citation list and dates for the front page, but I did not retrieve and read the full text of the ten U.S. patent references. Their subject‑matter descriptions above are flagged accordingly and should be confirmed before being relied on in a §102/§103 chart.
• I could not confirm the filing (not issuance) dates of the six post‑1997 references. Since '988 was filed 1997‑01‑27, only references with an earlier effective U.S. filing date can serve as §102(e) art. This materially affects the analysis and should be the next verification step.
• "Prior art date 1997‑01‑27" and the "expired – fee related" status are Google Patents' own assumptions; the patent's term ran to the 2017‑01‑27 expiration. Any §102 analysis here is therefore retrospective — the practical modern role of '988 is as prior art against later filings (hence the 282 forward citations), a role borne out by its classification into H04L 69/16x (TCP/IP stack implementation) and the many later "TCP splicing"/proxy‑offload patents citing it.

I'll ground this in the actual prior-art record on the page, plus quick verification of the field's pre-1997 state of the art.

Obviousness Analysis — U.S. Patent 5,941,988 ("Session and Transport Layer Proxies via TCP Glue")

Filed/priority: 1997-01-27 · Granted: 1999-08-24 · Inventors: Bhagwat, Maltz · Assignee: IBM · Status: Expired – Fee Related (anticipated expiration 2017-01-27) · Family: US 08/789,447 only; KR counterpart KR100255501B1.

1. What the "Prior Art" section of this page actually contains (read this first)

Two things on the fetched page fall under a "Prior Art" heading, and neither supports a § 103 combination the way a normal examiner-citation list would:

1. "Prior art keywords": proxy, connection, host, packets, tcp. This is a machine-generated keyword tag list, not evidence and not a reference. It has no probative value.
2. "Cited By (282)". This is a forward-citation list. Almost every entry post-dates the 1997-01-27 filing (e.g., US 6,157,944 with a 1997-05-14 priority date; US 6,167,438 at 1997-05-22; US 6,219,803 at 1997-07-01; the big F5, Citrix, Nvidia, NetScaler clusters from 1998–2009). Documents post-dating the critical date cannot be § 102/§ 103 prior art at all for this patent.

Scanning all 282 entries, only four have a priority date before 1997-01-27:

Note the near-misses: Lucent US 6,587,877 (1997-03-25), IBM US 7,020,700 (1997-02-28), Nomadix US 8,027,339 (1997-03-12), and the inventor's own later US 7,139,268 B1 "Performance of intermediate nodes with flow splicing" (1999-01-29) — all after 1997-01-27 and therefore not prior art.

The fetched page contains no examiner "References Cited" / patent-citation (backward citation) list. I cannot analyze the art the examiner actually cited without it, and I will not invent it.

Consequence: the substantive § 103 record for this patent must be built from (a) the references the applicant named in the Background, which operate as applicant admissions about the state of the art, and (b) contemporaneous public literature I verified below. That is the approach taken here.

Critical dates. With a 1997-01-27 filing and no earlier priority document, § 102(b) art must predate 1996-01-27 and § 102(a)/(e) art must predate 1997-01-27. Level of ordinary skill: a network systems engineer with a few years of TCP/IP stack and firewall/proxy implementation experience (the specification assumes working familiarity with snd_nxt/snd_una/rcv_nxt and socket internals).

2. The prior-art references available for combination

3. Claim-group obviousness analysis

Group I — Core header-rewriting splice: claims 1, 4, 17, 24, 26, 27, 31

Combination: PA-1/PA-2 + PA-6 + PA-8 + PA-7 (with PA-3, PA-4 as context).

Every element is disclosed or suggested:

• Two connections terminating at a common host, each to a different endpoint — PA-1/PA-2 (SOCKS proxy holds both sockets).
• Establishing/negotiating the sessions in the application layer and then relaying — PA-1/PA-2 plus the applicant's own Background admission.
• Modifying source/destination addresses and ports so packets of one connection "correspond to headers of packets of the [other] connection," with checksum recalculation — PA-8 literally teaches this (address/port rewriting + incremental IP/TCP checksum update at a middlebox).
• Modifying the sequence-number and ACK-number fields by a mapping — PA-8 teaches the offset/delta with a per-flow table, and PA-6 supplies the sequence-space framework.
• Executing the forwarding in the kernel rather than by a user-space read/write loop — PA-7.

Motivation to combine (KSR factors): the problem is stated in the patent's own Background — the proxy spends 2× the CPU of an endpoint on copying, protocol processing and context switching, and buffering packets. PA-7 identifies the same problem and the same solution class (an in-kernel splice between descriptors, 25–65% CPU-availability improvement, up to ~1.8× throughput on fast devices), and PA-8 identifies the other necessary element (a middlebox that rewrites headers/checksums/sequence numbers on the fly). Both are in the same field (operating-system networking / internetworking), both solve sub-problems of the same task, and the result — a proxy that relays without a user-space copy — is the predictable product of the combination. The inventors' own later measurements (SOCKS ≈3.2 ms mean forwarding latency vs. 102 µs for an in-kernel splice) are powerful evidence that the motivation was the ordinary, expected incentive to remove the user-space hop. Claims 1, 4, 17, 24, 26, 27 and 31 therefore appear obvious as a matter of law on this combination.

Claim 31's extra step ("exchanging arbitrary data … before glueing the two TCP connections") is addressed in § 4 below — it is the strongest candidate for non-obviousness.

Group II — Specific header fields: claims 3, 28

Combination: PA-8 (primary) + PA-6/PA-1 (secondary). Claim 3(a)–(f)/(g)–(l) — change destination IP, change source IP to the outbound interface, change TCP port, change send sequence field, change ACK field, recompute/update checksum — map one-to-one onto RFC 1631's NAT/NAPT translation plus FTP sequence adjustment, which explicitly recites address translation, port translation, "NAT must modify the IP checksum and the TCP checksum," incremental checksum arithmetic, and a table correcting "TCP sequence and acknowledge numbers." PA-1 supplies the two-connection proxy context. These claims carry essentially no independent weight. The fail-safe/incremental checksum-update limitation in the spec is also PA-8's express teaching.

Group III — Sequence-space mapping: claims 5, 6, 29

Claims 5, 29: choose the mapping so the next byte received on one connection gets the sequence number the peer expects — this is the definition of the RFC 1631 delta mapping (PA-8) applied to TCP (PA-6). Obvious.

Group IV — Synchronization: claims 8, 9, 10, 32, 33, 34 (and the "OK" message of FIGS. 2–3)

Combination: PA-2 + PA-6 + PA-1.

• Claim 9 ("synchronizing … by the sending and receiving of pre-existing messages of an authentication and authorization protocol") reads almost verbatim on the SOCKS v5 CONNECT-reply message of RFC 1928 — the very "OK message" FIG. 2 labels as the glue boundary. The applicant's own figure uses the SOCKS success reply.
• Client surge (data sent before glue exists) is handled by the proxy holding/discarding-or-queuing the client's early bytes until the success reply issues — an obvious consequence of the sequencing of SOCKS negotiation itself.
• Server surge (claims 33, 34) is handled by withholding ACKs so the server's TCP will retransmit. Deferring or suppressing acknowledgments is basic TCP receiver behavior (RFC 793/1122 delayed-ACK and zero-window flow control), so suppressing ACKs to throttle a peer until a fast path is installed is an available, predictable technique.

This is the thinnest part of the record (I did not locate a single pre-1997 reference that expressly says "suppress ACKs until the data path is spliced"), but a petitioner would argue, and likely prevail, on KSR's "known technique, predictable result" ground, particularly for claims 8, 9, 32 and 34, which merely claim synchronization performed with pre-existing protocol messages.

Group V — Firewall / authentication / security: claims 2, 7, 20, 21, 25, 26

Combination: PA-4 + PA-5 + PA-1/PA-2 + PA-8. Claim 7(a)–(f) and claim 26(a)–(f) are a recitation of what a SOCKS firewall already does — reject unauthorized connections, authenticate, take the destination address from the client, mediate — plus the PA-8 modification step. The only arguably added element is (f) treating a non-connection packet as a security violation, which is the definition of a stateful packet filter. Obvious.

Group VI — Caching / tap: claims 11–15, 22, 23, 35–38

Combination: PA-10 + PA-1 + PA-7. A proxy that "silently keep[s] a copy of the information" is expressly acknowledged in the patent's own Background as known HTTP caching-proxy behavior, and the specification admits "retaining a copy of the data stream is not a requirement." The decision factors of claims 15/38 (packet inter-arrival time, request history, available CPU/disk/memory, current cache contents, data content) are standard cache-admission and resource-management heuristics with no asserted unexpected result. Claims 11–15, 22, 23, 35–38 are obvious. Claims 14/37 (copy into a buffer readable by another process) are met by any socket buffer or "tee" — and note the inventors themselves later described exactly this as "TCP Tap."

Group VII — Teardown: claims 16, 18, 19

Combination: PA-6 + PA-8. FIN↔ACK exchange and RST as connection-termination triggers, plus retention of state "for a timeout period" after close, are exactly RFC 793's close state machine (FIN_WAIT_1/FIN_WAIT_2/CLOSE_WAIT and the 2MSL TIME-WAIT hold). RFC 1631 independently teaches deleting the mapping-table entry "soon after" a FIN is seen. Claims 16, 18, 19 are straightforwardly obvious over the TCP specification alone, with PA-8 corroborating the timeout retention of translation state.

4. Where the patent is strongest (and where a § 103 case is contestable)

1. Claim 6 and claim 31 — "glue can be established even after an arbitrary amount of data have been exchanged over each connection." The inventor's own technical report says this feature "is unique to TCP Splice" relative to NAT-based approaches and to the Cisco PIX, and distinguishes it from "previously existing techniques." A pre-1997 art combination built only on RFC 1631 + Fall/Pasquale does not plainly teach splicing two live connections that have already carried application traffic, because RFC 1631's delta table is created at session setup and Fall/Pasquale's splice() binds descriptors (including socket-to-socket splices), not pre-existing arbitrary protocol conversations. This is the best non-obviousness argument.
   Counter (why it likely still fails under KSR): the specification itself says "in general, there is no such restriction," i.e., it presents the timing as an implementation choice. Generalized NAT-based rewriting (PA-8) plus a proxy that already owns both sockets (PA-1) makes the choice of splice instant a matter of ordinary design, and KSR permits rejection where there is a finite number of predictable implementation options with an art-recognized incentive.
2. Removing the proxy's TCP state machine entirely (no socket buffers, no proxy-generated retransmissions, ACKs strictly end-to-end) is the genuinely elegant contribution. Because the patent claims this only indirectly ("on-the-fly," "no state maintenance," claims 1/17/24), the argument reduces to whether PA-7 + PA-8 together suggest discarding the endpoint state machine. A skilled advocate will say PA-7's splice keeps sockets and buffers alive, so the combination does not reach "there is no input or output buffer." That is the single most defensible line in the patent.
3. Claim 26(d) is facially inconsistent (literally: "modifying the headers of all packets sent to the remote host … and forwarding them to the local host," whereas claim 7(d) says "packets sent by the remote host"). Per the instruction to read identifiers and text literally, the claim as issued should be read as written; that is a § 112(b) problem, not a § 103 one, but it narrows the practical scope and reduces the value of invalidating it for § 103 purposes.
4. PA-9 (Cisco PIX cut-through proxy) is the most dangerous single reference (it combines firewall authentication, packet queuing during authentication, and sequence-number-mapping header modification) but its precise public-availability date before 1997-01-27 needs documentary proof; the only source I have is the applicants' own 1998 characterization, which is corroborative but dated.

5. Bottom line

• Likely obvious: claims 1, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 16, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 32, 33, 35, 36, 37 — primarily over Koblas/Koblas 1992 + RFC 1928 (SOCKS) in view of RFC 1631 (NAT) and/or Fall & Pasquale 1993, with RFC 793 for the sequence-space and teardown limitations and Cheswick & Bellovin / Chapman & Zwicky for the firewall limitations.
• Contestable but probably still obvious: claims 15, 34, 38 (synchronization and cache-admission specifics); the record here rests on the "known technique, predictable result" branch of KSR rather than on an express teaching.
• Strongest non-obviousness position: claims 6, 30 and 31 (splicing connections that have already carried arbitrary application traffic), and the implicit "proxy keeps no TCP state/buffers" limitation embedded in claims 1/17/24.
• What I could not do: the fetched page supplies no examiner/backward citation list, and its "Cited By" set is forward citation; only the four documents with 1995–1996 priority dates (Citrix '570/'529 family; Nvidia RE39,501) are even potentially § 102(e) art, and neither teaches on-the-fly TCP header splicing at a common host in kernel space. Any definitive obviousness opinion should be re-run against the file wrapper (USPTO PatentCenter / Global Dossier) and the actual PIX product literature to confirm dates before those references are relied upon.