US 6088796

I'll run several targeted searches in parallel — for the patent itself, its claims, and any 2026 CAFC activity.

Let me confirm whether any 2026 litigation or Federal Circuit activity exists for this number specifically.

US 6,088,796 — Verification Summary

Search scope. I searched for the literal identifier "6088796" / "6,088,796" (plus title, inventors, and assignee terms) across patent databases and for 2026 Federal Circuit activity. I did not auto-correct the number, and I have flagged the one same-string collision I found (below).

---

Bibliographic record

Abstract (as issued): "A secure access query system incorporating a messenger system. The system includes a communication server for receiving queries from a user and transmitting replies to the user, an application server for providing replies to queries, a network firewall for preventing unauthorized access to the application server and a messenger system, coupled to the communication server for receiving queries from the communication server, transmitting the query across the network firewall along a secure pathway established by the application server between the messenger system means and the application server, receiving replies from the application server along the secure pathway and transmitting the replies to the communication server. Queries from the user, outside of the network firewall, are thus communicated in a secure fashion to the application server, within the firewall, and replies are provided to the user from the application server through the secure pathway with the messenger system and the communication server."

U.S. prior art cited on the face (13 references): 5,550,984 (Gelb); 5,623,601 (Vu); 5,699,513 (Feigen); 5,768,503 (Olkin); 5,784,463 (Chen); 5,790,809 (Holmes); 5,826,029 (Gore); 5,828,833 (Belville); 5,828,893 (Wied); 5,835,726 (Shwed); 5,898,830 (Wesinger); 5,903,732 (Reed); 5,915,087 (Hammond); 5,983,350 (Minear). (US 6,088,796 is in turn cited as prior art on the face of US 6,751,677, Ilnicki/HP.)

---

Independent claims in plain language

• Claim 1 — Secure access query system (the core claim). Four elements: (a) a communication server that takes queries from a user and sends replies back; (b) an application server that establishes a secure connection and answers queries; (c) a network firewall that blocks unauthorized access to the application server; and (d) a "messenger system means," coupled to the communication server, that receives the query, pushes it across the firewall over a secure pathway established by the application server, receives the reply over that same pathway, and forwards it to the communication server. The closing "whereby" clause states the point of novelty: the user outside the firewall is served securely by an application server inside the firewall, over a path the inside server created.

• Claim 16 — Middleware control system. Addresses the same architecture at the middleware level: a gateway module at the communication server converting the communication-server protocol ↔ messenger-system protocol; a firewall that prevents unauthorized access and prevents any connections established from outside the firewall; a user agent module at the application server that establishes the secure connection and converts messenger-system protocol ↔ application-server protocol; and messenger system means that route queries/replies across the firewall over the user-agent-established pathway.

• Claim 17 — Secure access query system (no communication server recited). Narrows the cast of characters to just the application server (which establishes the secure pathway), the firewall, and messenger system means that receive a user's query, carry it across the firewall over the application-server-established pathway, and return the reply to the user directly.

• Claim 18 — Multi-server system with dynamic load balancing. At least two application servers, each establishing its own secure pathway outbound through the firewall, plus messenger system means that dynamically load balances incoming queries by selecting which application server receives a given query.

• Claim 19 — Communication server + multi-server + load balancing. Combines claim 18's at-least-two-application-servers and dynamic load balancing with claim 1's communication server sitting in front of the messenger system.

• Claim 20 — Middleware system with protocol transparency. Access means (querying client) + at least one application component + a user agent module per component + messenger system means that shuttle queries and replies in a common transfer protocol. Both ends convert between their native protocol and the transfer protocol, and the user agent (not the messenger system) establishes the connection. The stated result is that queries can be served without regard to the programming language, operating system or protocol used by the access means or the application components.

• Claim 21 — Access control system (broadest framing). A firewall that blocks unauthorized access from outside; a resource inside the firewall (information and/or logic — dependent claims 22/23 specify database server and application server) that establishes a secure pathway outward; and a middleware system outside the firewall coupled to the resource over that resource-established, secured pathway, with the firewall blocking any connection from outside. The resource is protected from all outside access except through the middleware system.

Dependent-claim themes (claims 2–15, 22–30): web/Internet communication server (2–3); gateway and native-protocol translation (4–5); User Agent translation and User-Agent-initiated pathway (6–7); warm socket full-duplex maintenance until terminated by the application server, and persistence when idle (8–9); firewall blocking all inbound access (10); application-server-side authorization of query types (11); multiple communication servers (12); multiple application servers each with its own pathway, port restriction, and a subscription list maintained by the messenger system (13–15); resource is a database server / application server / web server; middleware as communications server; at-least-two application servers with request balancing (27–28); "information" as database data and "logic" as executed program code (29–30).

---

2026 Federal Circuit / litigation check

No Federal Circuit or PTAB activity for 6,088,796 was located. I found no CAFC docket, docketing notice, oral-argument listing, or IPR/CBM/docket entry referencing 6,088,796. Searches of 2026 CAFC scheduled-case listings, 2026 docketing notices, and 2026 patent-litigation roundups (Q1/Q2 2026) surfaced no mention of this patent, its inventors, or Tempest Software.

Caveat on that negative finding: CAFC and district-court dockets are not fully keyword-indexable through general web search, and my most targeted follow-up query (USPTO Patent Center / reexamination status for this specific number) hit a tool limit rather than returning a result. So treat this as "nothing found," not as "confirmed nonexistent." Given that the patent expired for fee non-payment around 2018-08-06, and was subject to a 2001 bank security agreement, a 2026 Federal Circuit appeal would be unusual and would most likely relate to a lapsed-rights or ownership issue rather than to current infringement enforcement.

Uncertainty and sourcing notes

1. Claim text source. The authoritative Google Patents record supplied in the prompt includes the abstract and specification but no claims section. The claim language above was taken from secondary sources (EveryPatent's full-text reproduction at everypatent.com/comp/pat6088796.html and RPX Insight's record at insight.rpxcorp.com/patent/US6088796A). The substance is internally consistent across both and matches the abstract, but for anything filing-critical I would verify against the USPTO Patent Center full-text or the granted patent PDF rather than relying on these mirrors.
2. Title/number collision — do not conflate. "JP 6088796 B2" is an unrelated Japanese patent (No. 6088796, I-O Data, "protection device for external storage device," issued 2017-03-01). The alphanumeric string is similar but the document is entirely different; I have treated US 6,088,796 and JP 6088796 B2 as separate items throughout.
3. Dates. The prompt's headers give two different "current" dates (system: 2026-09-30; user message: April 26, 2026). This ambiguity does not affect the bibliographic facts above, but it does affect whether "2026 CAFC dockets" includes the full year — my searches returned material dated as late as September 2026, and none referenced this patent.
4. Potential § 112(f) point. All seven independent claims recite "messenger system means," and claim 20 recites "access means." The word "means" creates a presumption that these limitations are means-plus-function under 35 U.S.C. § 112(f), construed to cover only the corresponding structure disclosed in the specification (here, the Tempest/TMSP messenger daemon and User Agent library) and equivalents. Since the patent is expired, this is of historical interest only — but it materially narrows what these claims would have covered.

I'll research litigation involving US Patent 6,088,796. Let me search multiple sources.

Let me search more specifically for this patent and its owner.

Let me check patent litigation databases directly for this patent.

Litigation Search: US Patent No. 6,088,796

Bottom line

I found no evidence of any litigation involving US Patent No. 6,088,796. No district court infringement action, declaratory judgment action, Federal Circuit appeal, ITC investigation, or PTAB proceeding asserting or challenging this specific patent appeared in any of the sources I searched. I want to be explicit that this is a negative finding based on my searches, not a certified "no litigation ever occurred" statement — see the caveats below.

Patent identified (for confirmation of scope)

What I searched and what I found

• Google Patents (https://patents.google.com/patent/US6088796A) — shows only prosecution/assignment history. The Google Patents record for this patent surfaced no "Litigation" events associated with it.
• Unified Patents portal (portal.unifiedpatents.com) — the patent appears in Unified's patent database record (cited as US-6088796-A, assignee TemPest Software Inc.), but only as a patent record, not as a linked litigation entry. The portal entry I retrieved for a related record (US-5828893-A) merely cross-references US-6088796-A among similar patents; it is not a litigation record.
• RPX Insight (insight.rpxcorp.com/patent/US6088796A) — returns the patent's bibliographic and claims data, with no litigation section populated.
• Targeted web searches for "6088796" / "6,088,796" plus terms litigation, lawsuit, infringement, complaint, case number, IPR/PTAB, and for the assignee (TemPest Software) and inventors (Cianfrocca, Sohn) — returned no case names, docket numbers, courts, or filing dates tied to this patent.

One search hit deserves an explicit caution: a PTAB exhibit from IPR2022-00413, Apple Inc. v. RFCyber Corp. contains the string "6088796". I reviewed it — that occurrence is inside an examiner's EAST prior-art search history for a different patent (US 9,240,009), where 6,088,796 was merely listed as a searched reference. It is not litigation involving 6,088,796, and I am not treating it as such.

Caveats on coverage

• I was not able to query PACER or the CAFC docket directly in this session (those require authenticated access), nor did I complete a run against the Unified Patents litigation caselist, as my tool use was cut off. My negative finding rests on the patent-focused databases and general web sources listed above.
• This patent's owner (TemPest Software, Inc., later associated with the "TemPest Messenger" product) could in principle have been party to litigation involving other patents or business disputes that wouldn't name 6,088,796; I found no such records either, but I flag the limitation.
• A complete negative confirmation would require a docket-level PACER/Lex Machina docket search on the patent number and a Docket Navigator / Unified Patents Litigation caselist query.

Recommendation

If you need a litigation-grade clearance statement, I'd recommend running: (1) a Docket Navigator or Lex Machina patent-level search on "6,088,796"; (2) the Unified Patents Litigation caselist search by patent number; and (3) a PACER nationwide party/docket search for "TemPest Software." Based on everything retrievable now, the expected result is no litigation.

I'll start from the canonical structured data signal (no AIA trials indexed) and run targeted searches to see whether web sources surface anything the ODP hasn't ingested.

The first-pass results are polluted by a different "’608 Patent" (U.S. 10,268,608 — Netlist's memory-controller patent). I need to disambiguate strictly to 6,088,796 / Tempest Software.

No hits yet tying a PTAB proceeding to 6,088,796 — only citations of it as prior art in other trials. Let me check CBM/PGR, litigation history, and any Unified Patents involvement directly.

Proceedings overview

Zero AIA trial proceedings are on file against US 6,088,796 — the USPTO Open Data Portal returns no IPR, PGR, or CBM petition for this patent, and my web search surfaced no PTAB proceeding, Federal Circuit appeal, or reexamination directed at it (no active, invalidated, sustained, settled, or institution-denied proceedings — the patent has never been challenged at the PTAB at all), which leaves a defendant with a completely untested, never-narrowed claim set and no petitioner-side estoppel to free-ride on — but also no indication that anyone has ever bothered to attack the patent, consistent with the fact that it expired on 2018-08-06 and its owner (Tempest Software, Inc.) is long out of the picture.

For each proceeding: none to report. I decline to construct entries here, because every apparent "’608 Patent" PTAB hit in search results belongs to a different, unrelated patent (see the disambiguation note below). Fabricating proceeding numbers would be worse than reporting an empty list.

---

Disambiguation warning — do not be misled by "'608 Patent" hits

A search for "'608 patent" + "PTAB" returns a large volume of petition and decision text. All of it that I inspected refers to a different patent — US 10,268,608 (Netlist/Micron memory-controller litigation) — not US 6,088,796. Examples surfaced in search:

• IPR2024-01241 petition (memory controller, challenged claims 1–12) — this is the 10,268,608 patent, filed by Baker Botts on 2024-08-09. Not our patent.
• Petitions/decisions referencing Johnson, Stubbs, Moss, Hiraishi, Ellsberry, Kim — all 10,268,608 art.
• CourtListener recap PDF distinguishing the '608, '035, and '506 patents — again the Netlist family.

I flag this because a defendant's counsel searching by the colloquial short form "'608 patent" will land on Netlist v. Micron-style material and could mistakenly brief an inapposite IPR history. Confirm by full number (7 digits, 6,088,796) or by title.

---

Where US 6,088,796 does appear — and why it isn't a challenge to it

The patent shows up in the PTAB record only as prior art cited in other parties' proceedings, never as the challenged patent:

None of these is a proceeding against 6,088,796. They establish only that the patent is well-known enough in the web/middleware space to be cited as prior art — which, itself, is a quiet signal about the scope of what it discloses.

---

Patent posture (context for the defensive assessment)

From the authoritative text at https://patents.google.com/patent/[US6088796A](/patent/US6088796A)/en:

• Title: Secure middleware and server control system for querying through a network firewall
• Inventors: Francis Cianfrocca; Adam H. Sohn
• Provisional priority: 60/054,876, filed 1997-08-06
• Filed: 1998-08-06 → pre-AIA patent (IPR and CBM-eligible; not PGR-eligible, since PGR applies only to patents subject to first-inventor-to-file)
• Granted: 2000-07-11
• Assignment: Original assignee "Individual"; assigned to Tempest Software, Inc. on 2001-02-01; security agreement to Comerica Bank – Texas on 2001-04-19
• Anticipated expiration: 2018-08-06 (20 years from filing)
• Legal status: Expired – Fee Related
• Classification: H04L63/02, H04L63/0209, H04L63/029 (firewall traversal), G06F16/95, Y10S707/99939 (privileged access)

---

Strategic summary

Claim status: US 6,088,796 is entirely UNTESTED at the PTAB. No claim of this patent has been canceled, disclaimed, or amended through any AIA trial. The full claim set as granted on 2000-07-11 stands unaltered in the Office's records. That cuts both ways: there is no ready-made invalidity judgment to cite — but there is also no claim construction, no evidentiary record, and no petitioner-side estoppel, so a defendant retains a completely fresh slate. (Note: I could not verify the number of issued claims from the material provided — the fetched text truncates mid-sentence in the deployment discussion and does not reproduce the claims. Do not state a claim count without pulling the patent's claims from the USPTO Patent Center or the PDF. In particular, do not assert "claims 1–5" or any other range.)

Estoppel landscape: there is none. Because no IPR, PGR, or CBM ever reached a final written decision on this patent, 35 U.S.C. § 315(e)(2) and § 325(e)(2) estoppel does not attach to anyone with respect to 6,088,796. There is no prior petitioner whose grounds are foreclosed and, correspondingly, no prior petitioner whose work product you can borrow. Every prior-art combination remains available to a defendant or a new petitioner. The relevant timing constraint is different and much more important: since the patent expired 2018-08-06, the live exposure is limited to past damages within the § 286 six-year look-back measured from the date of any complaint, and any IPR would be fought over an expired patent.

Pattern signals: essentially none, and the enforcement chain is cold. The patent was asserted (as the FRAND/middleware art) against nobody publicly that I could confirm — search for a Tempest Software enforcement campaign produced only product-launch press releases (TMS 3.1.1 and SiteShield, 2000–2001) trumpeting the issuance of the patent, not litigation. There is no evidence of any defensive aggregator (e.g., Unified Patents) ever challenging this patent, no multiple-petitioner pattern, and no patent-owner appeal activity — for the simple reason that there is no proceeding to appeal. The absence is itself diagnostic: a patent that was, by its owner's own marketing, foundational to firewall-traversal middleware was never worth anyone's $100k+ to invalidate. That is unusual and suggests either that the patent was never credibly asserted or that its claims were viewed as narrow/easily designed around. Revived assertion by a successor-in-interest of a 1998 patent that expired in 2018 is the scenario to guard against.

---

Recommended next steps

1. Treat "no PTAB activity" as the finding, and verify it yourself in the primary source. The ODP ingest is the canonical list and it is empty; my corroborating web search hit the tool limit before exhaustion, so I cannot claim the search was exhaustive. Confirm at PTAB E2E (https://ptab.uspto.gov) and Patent Center (https://patentcenter.uspto.gov) using full application number 09/129,800 and patent number 6,088,796.

2. Do not search by "'608 patent" alone. As shown above, that string is dominated by US 10,268,608 (Netlist memory-controller) PTAB material. Search by the full seven-digit number or exact title.

3. Pull the granted claims and the full prosecution history before forming any validity opinion. This prompt's source text is truncated and omits the claims entirely. Get the claims from the USPTO Patent Center or the Google Patents PDF (https://patents.google.com/patent/US6088796A/en) — the claim set is the single most important document and it is not in the record provided.

4. If a demand letter asserts 6,088,796 today, lead with three points:

   • Expiration/§ 286. The patent expired 2018-08-06. Damages, if any, are confined to the six-year look-back from the complaint date — a short and shrinking window for a 1998-era patent.
   • No PTAB history to rely on, but no estoppel against you either. You are free to file an IPR on any § 102/§ 103 ground; § 315(b)'s one-year bar runs from service of the complaint, so the clock to consider a petition starts the day you are served. Note that IPR of an expired patent is permitted, and claim construction uses the Phillips standard for expired claims rather than BRI.
   • Prosecution history and art. The patent is cited as prior art in multiple later proceedings (IPR2020-00157, IPR2013-00369 exhibits), which means the middleware/firewall-traversal art space is well mapped — mine those exhibit lists and the patent's own cited references (its front page cites RFC 2068 and proprietary server APIs as the state of the art it improves on) as a starting point for § 102/§ 103 theories.

5. Watch for an ex parte reexamination instead. Because no AIA trial exists, a reexam (which has no § 315(b) time bar and can be filed anonymously by anyone at any time) is the more likely Office-side vehicle if a challenge ever materializes. Recheck the Patent Center "Reexam" tab alongside the PTAB tab.

Bottom line for a defendant: the patent has never been tested at the PTAB, has no invalidation history to invoke, and no estoppel to inherit — but it also expired in 2018 and shows no sign of ever having been enforced. Treat it as a stale, untested asset whose only real leverage is a short past-damages tail, and build any defense on expiration, the § 286 window, and a fresh § 102/§ 103 record rather than on someone else's PTAB victory, because there isn't one.

I'll research the assignment chain for US 6,088,796, starting with the recorded legal events and the parties involved.

Ownership Chain Reconstruction — US Patent No. 6,088,796

Scope note on sources. I was able to retrieve the events of this patent's chain from the Google Patents legal-events record (which mirrors USPTO assignment data by recording date). I was not able to retrieve the underlying USPTO Assignment Center records in this session — meaning reel/frame numbers, execution dates, and the correspondent of record are not in hand. I have left those fields marked as unavailable rather than reconstructing them, per the no-fabrication constraint. Every date, party name, and conveyance type below is quoted from the retrieved record; everything else is labeled as unknown.

---

Inventors

Unusual pattern check — negative. The premise pattern ("all inventors departing the original assignee within 12 months of filing") is not present. Cianfrocca remained with Tempest Software through the assignment period and did not surface as founder of a successor entity (Bayshore Networks) until roughly 2002 — about four years post-filing and two years post-issue. That is an ordinary founder-departure arc, not a fire-sale precursor.

One genuinely unusual pattern is present, in the assignment mechanics rather than in personnel: the patent issued on 2000-07-11 naming no assignee ("Individual"), and the assignment of both inventors' interests to their own operating company was recorded only on 2001-02-01 — after issuance. That is the signature of an inventor-to-company assignment that either was executed late or was recorded late. It did not leave the patent stranded off-chain, but it does mean the issued patent's face is misleading as to real ownership.

---

Original assignee

As issued: "Individual" (the two named inventors). The Google Patents record explicitly lists Original Assignee: Individual; the patent issued to Cianfrocca and Sohn personally.

As actually held in practice: Tempest Software, Inc. (the party named as Current Assignee). Facts about it:

• Product shipped? Yes — and it embodied the claims. Tempest Software's product line is described as including the "Tempest messenger system 3.1.1," "SiteShield 2.6," application-layer security, and secured instant messaging. "Tempest Messenger" is the very "messenger system" of the specification, and the specification's deployment sections (§ on tmscgi, NSAPI/ISAPI gateways, TMSP) read as product documentation folded into the patent — a strong indication the patent covered a real commercial implementation, not a paper asset.
• Primary line of business: internet infrastructure / application-layer security middleware; headquartered New York, NY.
• Current status: wound down / no longer operating. Cianfrocca is described in executive-profile sources as former Chairman & CTO of Tempest Software, having moved on to co-found Bayshore Networks (cited founding year 2002; another source gives 2002 and lists Bob Lam as co-founder). I found no evidence of an acquisition, no evidence of a Chapter 7/11 filing, and no successor entity holding these patents.

---

Assignment timeline

The record shows two ownership recordings and one lien — nothing more. No post-2001 transfer of title appears anywhere in the retrieved record.

c. 1998 (execution date unknown) / recorded 2001-02-01 — Reel/Frame: not retrieved

• Conveyance: Assignment (Google Patents event label: "ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS)")
• Assignor: CIANFROCCA, FRANCIS
• Assignee: TEMPEST SOFTWARE, INC.
• Correspondent: not retrieved — cannot be evaluated.
• Context: internal founder-to-company assignment, recorded post-issuance; not an acquisition.

c. 1998–2000 (execution date unknown) / recorded 2001-02-01 — Reel/Frame: not retrieved

• Conveyance: Assignment
• Assignor: SOHN, ADAM H.
• Assignee: TEMPEST SOFTWARE, INC.
• Correspondent: not retrieved.
• Context: second half of the same internal formalization — same assignee, same recording date, filed as a separate instrument per inventor.

Executed date unknown / recorded 2001-04-19 — Reel/Frame: not retrieved

• Conveyance: Security Agreement
• Assignor: TEMPEST SOFTWARE, INC.
• Assignee: COMERICA BANK — TEXAS
• Correspondent: not retrieved.
• Context: securitization — a lender's collateral lien on Tempest's IP (classic venture-debt facility), not a transfer of title. No release, foreclosure, or assignment to Comerica appears in the record.

2018-08-06 — no reel/frame (not an assignment)

• Event: Anticipated expiration / "Expired — Fee Related."
• Context: lapse. The "fee related" characterization indicates the patent fell for non-payment of maintenance fees rather than running full term to the 20-year date — i.e., at some point the owner declined to keep paying for it.

No records found for: any assignment to an LLC, any assignment to a known NPE/asserter, any merger or change-of-name filing, and any release of the Comerica security interest.

---

Timeline diagram

timeline
    title Ownership of US 6088796
    1997 : Provisional filed by inventors
    1998 : Non-provisional filed by individual inventors
    2000 : Patent issued with no assignee named
    2001 : Both inventors assign to Tempest Software
         : Comerica Bank records security agreement
    2018 : Patent lapses for fee non-payment

---

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. No assignee in the chain carries an "IP / Holdings / Licensing / Ventures" suffix, and no single-purpose LLC appears at all. The only assignees on record are an operating software company (Tempest Software, Inc.) and a bank (Comerica Bank — Texas) holding a lien, not title. Anonymity indicators (registered-agent address, Delaware/Texas shell) cannot even be tested because no shell exists in the record.

2. Known asserter in the chain — NOT PRESENT. Neither Tempest Software, Inc. nor Comerica Bank — Texas appears on the enumerated NPE lists (Acacia, Marathon, IV, IPNav, Wi-LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Document Generation Corp) or as a high-frequency plaintiff in Unified/RPX directories. This is consistent with the earlier litigation section, which found no litigation of any kind involving this patent.

3. Repeat correspondent across the chain — UNCLEAR / not evaluable. This is the signal I most wanted to test and cannot: the Assignment Center records that would expose the correspondent of record for the two 2001-02-01 filings and the 2001-04-19 lien were not retrievable in this session. I decline to infer a correspondent from anything else. Note for what it's worth that the two 2001-02-01 filings were evidently prepared as separate instruments per inventor recorded on the same day, which is ordinary house-counsel/outside-counsel formalization practice, not the fingerprint of a single repeat-player attorney running a stable of LLCs.

4. Cascading transfers — NOT PRESENT. There is exactly one ownership transfer step (inventors → Tempest Software, recorded 2001-02-01) plus one lien (2001-04-19). A chain with a single beneficial owner and no onward hop cannot exhibit the <24-month chained-LLC pattern.

5. Pre-litigation transfer — NOT PRESENT (and vacuous). The last ownership event of any kind is dated 2001-04-19, seventeen years before the 2018 lapse, and no infringement suit naming this patent was identified. There is no suit to time an assignment against.

6. Bankruptcy fire-sale — NOT ESTABLISHED; UNCLEAR. What is on record is a Comerica Bank — Texas security agreement recorded 2001-04-19, which shows Tempest pledged this patent as loan collateral — a financial-distress-adjacent fact. But a lien is not a fire-sale: there is no recorded assignment to Comerica, no release, no trustee sale, and no Chapter 7/11 proceeding tied to this patent. Tempest appears to have simply wound down, and the patent apparently stayed with it. I mark this the same way my litigation section did: unresolved for want of docket-level records.

7. Privateering — NOT PRESENT. The patent never left the operating company that developed the technology, so there is no operating-company → NPE handoff of the kind that privateering describes. No SEC filing, EFF, or Patent Progress coverage of Tempest asserting through a proxy was surfaced.

8. Defensive aggregator (anti-NPE) — NOT PRESENT. The chain terminates at neither RPX, AST, LOT Network, Unified Patents, nor OIN. The patent was not neutralized by purchase into a defensive pool; it was neutralized the cheap way — lapse for fee non-payment in 2018. The absence of a defensive buyer is itself informative: nobody, defensive or offensive, thought this asset worth acquiring.

---

Verdict

Insufficient data — qualified, and best read as "operating-company-owned, never asserted, expired."

Justification. The retrievable chain contains exactly one ownership transfer — inventors Cianfrocca and Sohn to Tempest Software, Inc., recorded 2001-02-01 — plus a lender's lien to Comerica Bank — Texas recorded 2001-04-19; there is no onward hop, no NPE assignee, and no litigation. The patent therefore sat with the original operating company (a real vendor of the "Tempest Messenger System 3.1.1") until it lapsed as "Expired — Fee Related" on 2018-08-06. Because the only recorded title event is the original assignment to the original operating company — and because I could not retrieve the Assignment Center reel/frame data needed to test the repeat-correspondent signal — "Insufficient data" is the honest selection under the taxonomy. I note explicitly that the taxonomy's other buckets do not fit: "Operating-company assertion" fails on its own definition (Tempest is not a plaintiff against competitors — there is no suit), and "Defensive / non-asserting" fails on its own definition (no defensive aggregator appears in the chain). I flag this as a taxonomy gap rather than force-fit it. On the evidence actually in hand, zero of the eight NPE signals are affirmatively present.

Verification links.

• USPTO Assignment Center (search patent 6,088,796): https://assignmentcenter.uspto.gov/
• USPTO legacy assignment search: https://assignment.uspto.gov/patent/index.html
• Google Patents legal events (source of the dates above): https://patents.google.com/patent/[US6088796A](/patent/US6088796A)

Open items for a cleaner record. (a) Pull reel/frame + correspondent for the three 2001 recordings — the single missing fact that would let signal 3 be scored. (b) Run the nationwide PACER party search for "Tempest Software" to confirm the absence of a bankruptcy docket (signal 6). (c) Confirm whether maintenance fees lapsed early or whether the 2018 date is simply the 20-year term, since "Expired — Fee Related" and "anticipated expiration 2018-08-06" sit together in the record and I did not resolve which controls.

I'll research the prior art cited against US 6,088,796. Let me search for its citation records.

Let me retrieve the citation tables directly from patent databases.

Let me try to retrieve the front-page "References Cited" list from alternative patent databases.

Prior-Art Analysis: US Patent No. 6,088,796

1. Patent identified (literal, no auto-correction)

Two housekeeping flags before anything else:

• Date discrepancy: Unified Patents renders this record with a date of 1998-08-05 ("US-6088796-A … 1998-08-05 … Tempest Software Inc"), while Google Patents, the EPO/Espacenet record, and the specification's own provisional reference give 1998-08-06. The authoritative full text in hand says Aug. 6, 1998, so I treat 1998-08-06 as controlling and flag the 08-05 reading as an apparent database artifact.
• Currently: no litigation was found for this patent (see the earlier litigation section), so there is no court record identifying an asserted claim set or an invalidity contention to anchor a §102 analysis. What follows is prosecution-era prior-art analysis only.

---

2. Critical limitation on this task (stated up front, per operating rules)

I could not retrieve the patent's own "(56) References Cited" list, and the authoritative full text supplied to me does not contain it.

• The Google Patents body text provided in the source message reproduces the Abstract, Background, Summary, Brief Description of the Drawings, and Detailed Description — but the fetched HTML skips the front-page bibliographic block, including "(56) References Cited," "Foreign Patent Documents," "Other References," and "Referenced By."
• I also could not obtain the pre-grant Notice of References Cited (PTO-892) or the examiner's search history for Art Unit control 09/129,800 in this session (PatentCenter/PAIR and Docket Navigator require authenticated access).
• The claims themselves are also absent from the supplied text (it truncates mid-sentence in the Detailed Description: "It is often useful for messenger system enabled application pr…").

Because of that gap I am not going to invent a citation list. Assigning specific patents or dates to "the references cited in US 6,088,796" without having the actual PTO-892 / front page in front of me would violate the no-fabrication rule, and §102 mapping requires both (a) the true cited reference and (b) the actual claim language — neither of which I currently hold.

What I can do reliably and completely is below.

---

3. What I did confirm about this patent's citation relationships

These are forward citations (later documents that cite '796), not prior art to '796 — listed so they are not mistaken for cited references:

I also confirmed the caution from the prior litigation pass: in IPR2022-00413, Apple Inc. v. RFCyber Corp. (Exhibit 1042, file history of US 9,240,009), the string "6088796" appears only inside an examiner's keyword search history — not a citation of, or challenge to, '796. It is not usable as a prior-art citation for '796.

Bottom line on §2: no verified backward-citation list obtained; everything in this section is a citation to '796, which is legally irrelevant to its validity.

---

4. Prior art the patent itself identifies (admitted / background art)

These are the only "references" I can attribute to US 6,088,796 with certainty, because the patent's own text names them. Under MPEP §§ 2129 / 608.01(c) these statements are usable as Applicant Admitted Prior Art, and are therefore the most defensible §102/§103 material in this record.

§102 potential: Because these are admissions about what the prior art could not do (warm sockets, async IPC, dynamic load balancing) or about standard protocols rather than complete prior systems, none of them, standing alone, appears to disclose every element of the abstracted system claim. Their §102 value is therefore low; their real value is as §103 background and as a narrowing construction of "warm socket" and "no inbound connections."

---

5. Mapping to claims (best available, clearly flagged)

I do not have the claim text, so I cannot assign reference → claim numbers. The only claim language recoverable from the authoritative source is the Abstract, which conventionally tracks independent claim 1:

"A secure access query system incorporating a messenger system … a communication server for receiving queries from a user and transmitting replies; an application server for providing replies; a network firewall for preventing unauthorized access …; and a messenger system, coupled to the communication server, for receiving queries … transmitting the query across the network firewall along a secure pathway established by the application server … receiving replies from the application server along the secure pathway and transmitting the replies to the communication server."

If that reflects claim 1, then the anticipation-critical elements are, in order of how hard they are to meet in the 1995–1998 art:

1. Firewall-crossing over a connection initiated by the inside (application-server side) host only — the strongest novelty hook.
2. A "warm socket" held open across the firewall (persistent, full-duplex, kept alive with zero traffic).
3. Load balancing that is dynamic and configuration-free (mailbox/Open-Mailbox subscription roster).
4. Protocol identification at the server across HTTP/HTTPS/SMTP/native.

My prior-art candidate list would have to be reported against those four elements — but until the true (56) list and the claims are pulled, only element 4 (standards-based) and element 1 (older circuit/proxy-gateway art) can even be provisionally mapped, and I am declining to print candidate numbers I cannot verify.

---

6. How to close the gap (the exact sources to pull)

To produce a defensible, citation-by-citation §102 table, retrieve these four documents and hand them over:

1. Front page / "(56) References Cited" — Google Patents "Patent Citations" table at https://patents.google.com/patent/US6088796A (the section omitted from the text I was given), or the USPTO patent full-text front page in PatentCenter.
2. Pre-grant Notice of References Cited (PTO-892) and examiner's search notes for application 09/129,800 — USPTO PatentCenter / Public PAIR image file wrapper.
3. Espacenet "Cited documents" for US6088796 — https://worldwide.espacenet.com/publicationDetails/citedDocuments?CC=US&NR=[6088796A](/patent/6088796A).
4. The full claim set (all claims, with numbering) — from the patent PDF at https://patentimages.storage.googleapis.com/… (US6088796) or PatentCenter.

With items 1 and 4 I can return an exact, numbered table: reference → full citation → publication/filing date → one-paragraph technical description → the specific claim(s) it potentially anticipates under §102(a)/(b)/(e), plus a §103 combination analysis for the load-balancing and warm-socket elements, which are the ones most likely to have been met only in combination rather than by a single §102 reference.

---

7. Honest confidence statement

• High confidence: patent identity and bibliographic data (§1); the fact that the supplied authoritative text omits the (56) references and the claims (§2); the specification's own admitted/background art (§4); the forward-citation relationships in §3.
• Zero verified data: the actual list of references cited in US 6,088,796, and therefore any specific §102 anticipation assignment. I will not supply one until the PTO-892/front page is in hand.
• Not asserted: any candidate patent number as "prior art to '796." The only way to state a reference anticipates a claim under 35 U.S.C. § 102 is to show it discloses every element of that claim; that test cannot be performed without the claim text, which is missing from the source I was given.

If you can paste the front-page "(56) References Cited" block and the claim set, I will immediately produce the full reference-by-reference §102 table you asked for.

I'll research the cited prior art references before building the §103 analysis, since I need accurate reference substance rather than recalled summaries.

Good — I have solid substance for Vu and Wesinger. Let me pull the remaining cited references.

Obviousness Analysis — US 6,088,796 under 35 U.S.C. § 103

Patent: US 6,088,796 A — "Secure middleware and server control system for querying through a network firewall"
Effective priority: 1997‑08‑06 (Prov. 60/054,876) / filed 1998‑08‑06
Status note: Expired (fee‑related, ~2018‑08‑06). This is a retrospective/historical validity analysis, not a live-enforcement opinion.

---

0. Verification status, scope, and two flags

Verified in this session. I pulled and read the full text of three of the fourteen face‑cited references:

Partially verified. US 5,768,503 (Olkin) — I could only confirm the topic cluster for Terry M. Olkin at IBM (middleware, event‑based‑middleware security, a "Middleware program with enhanced security" having a server program in the same machine as the application), not the literal text of 5,768,503. Treat as provisional. Source: https://patents.justia.com/inventor/terry-michael-olkin

Not verified (tool limit reached). 5,699,513 (Feigen); 5,784,463 (Chen); 5,790,809 (Holmes); 5,826,029 (Gore); 5,828,833 (Belville); 5,828,893 (Wied); 5,835,726 (Shwed); 5,903,732 (Reed); 5,915,087 (Hammond); 5,983,350 (Minear). I will not assign them specific teachings or quotes. Everything I say about them below is labeled as "role to be confirmed."

Flag 1 (contradiction with the earlier section): the prior "Patent summary" header says "13 references" but the table lists 14 (5,550,984; 5,623,601; 5,699,513; 5,768,503; 5,784,463; 5,790,809; 5,826,029; 5,828,833; 5,828,893; 5,835,726; 5,898,830; 5,903,732; 5,915,087; 5,983,350). I use the 14 count.
Flag 2 (dates): system date 2026‑09‑30 vs. task date April 26, 2026. Immaterial to §103, since the relevant window is 1997–98.

---

1. Person of ordinary skill in the art (POSITA), as of August 1997

A bachelor's degree in CS/EE (or equivalent) plus ~2–3 years in network/systems engineering, with working knowledge of: TCP/IP and the sockets API; RFC 2068 (HTTP/1.0–1.1), SMTP, DNS; packet‑filter and application‑level proxy firewalls (TIS FWTK, SOCKS, Check Point‑class products); dual‑homed/bastion‑host design; client/server and early web‑application server design; and elementary load distribution (DNS round‑robin, "least‑connections," queue‑based dispatch). The '796 specification itself admits the RFC 2068 HTTP server as prior art, which fixes the lower bound of the art.

---

2. Distilled claim elements to be met

Note on §112(f). As flagged in the earlier section, "messenger system means" and "access means" trigger a presumption of means‑plus‑function construction, limited to the disclosed structure (the Tempest/TMSP messenger daemon + User Agent library with Connect/Open Mailbox/Send/Reply/Relay functions) and equivalents. For §103, the prior art must therefore map to that structure or its equivalents — not to any generic "server." This cuts both ways: it narrows the claim, and it makes the "equivalents" question the live battleground.

---

3. Element coverage of the verified references

Reading of the table: the verified art collectively discloses E1, E3, E4‑structure, E5, E6(partial), E7, E10 — everything except the direction of initiation (E2/E4's "pathway established by the application server inside the firewall"), and the specific mailbox/roster abstraction of E8.

---

4. The combinations that would render the claims obvious

Combination A — Vu '601 + Wesinger '830 (attacks claims 1, 16, 17, 21)

Vu supplies the architecture (private network → gateway/bastion → proxies → destination hosts; kernel that cannot forward; rule‑base authorization; two interdependent sessions per transaction). Wesinger supplies the transparent, user‑invisible interception of connection requests and the "envoy" broker model in which no traffic flows until the firewall itself establishes the relay — plus a load‑sharing firewall for E7. Both are in the identical field (interconnecting a private network to a hostile public network) and both state the same objective (security plus transparency/usability). A POSITA combining them arrives at a broker sitting outside the protected network that receives user requests and relays them to internal application components over relay sessions.

Combination B — A + Gelb '984 (attacks claims 4–6, 16, 20 — the translation elements)

Gelb is the protocol‑translation teaching the '796 claims recite: it expressly converts between two different network protocol suites at the boundary and strips addressing information. Where the '796 recites a gateway converting communication‑server protocol ↔ messenger protocol and a User Agent converting messenger protocol ↔ application protocol, Gelb shows that converting at each hop of a firewall boundary was known and desirable (it is what defeats protocol piggybacking). Gelb also shows a server resident on the public side brokering to internal applications, i.e., the "messenger outside / application inside" topology.

Combination C — B + a load‑balancing teaching (attacks claims 18, 19, 27, 28)

Wesinger's FIG. 4 load‑sharing firewall plus the well‑known DNS round‑robin and queue‑based dispatch practices (and, from the unverified set, whatever 5,826,029 Gore / 5,828,833 Belville / 5,835,726 Shwed actually teach about distributing connections across plural back ends) supply plural application servers with request distribution. The '796 adds "dynamic … without reconfiguration," which is answered by the registration‑on‑connect behavior that Wesinger's configurable virtual hosts and Vu's multi‑tasking proxies already imply.

Combination D — C + Olkin‑class middleware (attacks E8, claims 13–15)

A message‑oriented middleware broker with security policy per message/subject (the Olkin cluster) provides the Mailbox roster/subscription‑list abstraction — programs register interest, brokered messages are dispatched to a registered destination, and the roster updates as endpoints connect/disconnect. Provisional until 5,768,503 is pulled.

The missing piece, and why it is still obvious

None of the verified references teaches the inside application server opening the outbound TCP connection that becomes the reverse channel. That is the true point of novelty. Under KSR, however, it is the classic "finite number of identified, predictable solutions" case:

1. The references teach away from inbound initiation (Vu: the private network is routing‑invisible and the kernel cannot forward; Wesinger: no envoy, no traffic; Gelb: addresses stripped). The '796 specification itself concedes that permitting any inbound socket opens the database to attack.
2. Having adopted "inbound is forbidden," the only remaining way for an outside broker to reach an inside application over TCP is for the inside process to initiate the connection outward. There are, in practical terms, two design choices, and the references exclude one of them.
3. Long‑lived and reversed/keep‑alive channels were routine in the art (HTTP keep‑alive, FTP control connections, Telnet sessions; Vu's two interdependent sessions held open until termination). Maintaining a socket open "even if no data is being sent" is an ordinary engineering choice, not an inventive leap.

So: A/B/C (+D) in view of the admitted HTTP server art and the ordinary skill in socket programming establish a prima facie case that claims 1, 16, 17, 18, 19, 20, 21 (and the dependents that merely add web servers, gateways, authorization tables, multiple servers, and rosters) are obvious. The strongest individual target is claim 17, which drops the communication server entirely and needs only: firewall + application server that establishes the pathway + middleware that relays the query across the firewall and returns the reply — i.e., Combination A/B.

---

5. Motivation to combine (KSR factors / MPEP 2143)

1. Same field of endeavor. All three verified references are directed to interconnecting a private network with a hostile public network through an interposed gateway, with application‑level brokers. No field‑crossing rationale is needed.
2. Same problem, same stated goals. Each identifies the identical tension: security cannot be traded for usability/transparency. Vu: "transparent firewall with application level security." Wesinger: "maximum network security and maximum user convenience." Gelb: "full availability of services … while maintaining the private computer network secure."
3. Predictable result / mere arrangement of old elements. Substituting an application‑level proxy (Vu) for a packet filter, adding a translation layer (Gelb), adding a web front end (admitted RFC 2068 art), and distributing connections across plural back ends (Wesinger FIG. 4) is combining known elements according to known methods to yield a predictable result.
4. Known alternatives + design incentive. Firewalls that allow outbound and deny inbound were a recognized, safer configuration; the '796 background concedes that any inbound allowance creates hacker exposure. A POSITA protecting a database‑connected application server would be motivated to move the server behind the firewall and permit only outbound connections.
5. "Obvious to try." Once inbound initiation is excluded, outbound initiation by the inside component is the remaining, predictable option for establishing the channel — with a reasonable expectation of success, since keep‑alive/reverse sockets were well understood.
6. Strength of the art. Vu was confirmed on reexamination (claims 1–41 confirmed, new claims 42–59 added), which reduces the risk of a "this reference is unreliable" attack.

---

6. Summary chart — independent claims

---

7. Dependent claims (brief)

• 2–3, 12, 22–24, 29–30 (web/Internet communication server; multiple web servers; DB‑server/app‑server resource): supported by the admitted RFC 2068 art, Gelb's public‑side server, and Wesinger's multi‑layered interfaces — routine.
• 4–7, 20 (gateway/User Agent translation): Gelb (protocol translation at the boundary) + Vu (per‑service and generic proxies) + standard client libraries (SOCKS‑type client library = User Agent analogue). Check 5,784,463 (Chen) and 5,790,809 (Holmes) for a dedicated "client agent library" teaching — unverified.
• 8–9 (warm socket, idle persistence, teardown by app server): Vu's interdependent sessions held open and terminated together; HTTP keep‑alive; Telnet/FTP control sessions. Obvious design choice.
• 10 (firewall blocks all inbound): literally taught by Vu's non‑forwarding kernel and Wesinger's no‑envoy‑no‑traffic rule.
• 11 (application‑side authorization of query types): Vu's rule base shows per‑request authorization; relocating the check to the application (a table of authorized parameters) is a predictable design choice. Also candidate 5,983,350 (Minear) / 5,826,029 (Gore) — unverified.
• 13–15 (plural app servers, per‑pathway ports, subscription list): Wesinger FIG. 4 + known round‑robin/DNS distribution + middleware roster (Olkin cluster, provisional).
• 25–28 (middleware as communications server; ≥2 app servers with request balancing) : as claims 18–19.

---

8. Where the obviousness case is weak (and what to pull next)

1. The initiation inversion is the whole invention. "Established by the application server" (claims 1, 16, 17, 21) and "the User Agent, not the messenger system, establishes the connection" (claim 20) are not literally taught by Vu, Wesinger, or Gelb — each has the broker/firewall initiating. The case rests on the KSR "finite options / only remaining predictable solution" rationale rather than anticipation‑grade disclosure. A challenger should locate a 1997‑era reference teaching a persistent outbound ("reverse"/callback) channel opened from inside a firewall to an external broker. Candidates requiring verification from the face‑cited set: 5,903,732 (Reed), 5,828,833 (Belville), 5,826,029 (Gore), 5,828,893 (Wied) — I could not confirm any of these in this session, so I make no assertion about their content.
2. The mailbox/subscription‑list abstraction (claims 13–15) is claimed as a structural feature (roster maintained by the messenger system, servers added/removed with no reconfiguration). Wesinger's virtual hosts and Vu's multi‑tasking proxies get close functionally, but the named roster with automatic update on disconnect needs 5,768,503 (Olkin) or similar middleware art.
3. Secondary considerations. None located: no litigation or PTAB record for this patent (consistent with the earlier "no litigation found" section), so there is no evidence of nexus, commercial success, or unexpected results to rebut the prima facie case. Note the patent is not merely expired but subject to a recorded 2001 security agreement with Comerica Bank – Texas, further reducing the likelihood of any preservation of secondary‑consideration evidence.
4. §112(f) interaction. If "messenger system means" is construed narrowly to the disclosed Tempest daemon + User Agent function set and equivalents, the required prior‑art structure is correspondingly specific, and the mapping to Vu/Wesinger "proxies/envoys" becomes an equivalents argument — a vulnerability on both sides of the §103 dispute.

---

9. Bottom line

A prima facie §103 case exists for all seven independent claims, strongest against claim 17, using Vu '601 (security architecture, non‑forwarding kernel, application‑level proxies, multi‑user socket service) as the primary reference, in view of Wesinger '830 (transparent envoy brokering, no‑envoy‑no‑traffic firewall, load‑sharing firewall per FIG. 4) and Gelb '984 (dual‑homed boundary with protocol translation and address‑stripping, public‑side server brokering to internal applications), with the admitted RFC 2068 HTTP server art and ordinary socket/load‑distribution skill supplying the remaining elements. The motivation is supplied by the shared field, the shared security‑vs‑transparency problem, the recognized superiority of outbound‑only firewall policies, and the KSR "only remaining predictable option" rationale for having the inside application server initiate the otherwise‑prohibited inbound path.

The single contested limitation across claims 1, 16, 17, 20 and 21 is the direction of initiation — the pathway established by the application server inside the firewall — and the case is materially stronger if one of 5,903,732 (Reed), 5,828,833 (Belville), 5,826,029 (Gore), 5,828,893 (Wied), or 5,835,726 (Shwed) is verified to disclose a persistent outbound/reverse channel from behind a firewall to an external broker. I have not verified those five and do not assert their teachings.