US 5944823

I'll search for authoritative information on this patent number, including any litigation activity.

Let me do a couple more targeted checks on litigation/docket activity and the current assignee.

Summary of US Patent 5,944,823

Verification note up front: I searched for this exact number. I found the patent itself on Google Patents, the USPTO-hosted full-text/PDF, uspto.report, Unified Patents' portal, and third-party citations. I found no CAFC docket or appellate activity in 2026 (or any year) matching patent 5,944,823, and no district court case matching this patent number. I am reporting that absence rather than inferring litigation. I also did not return or rely on any similarly numbered patent except where a true family member is relevant (see below).

Bibliographic data (as stated in the authoritative patent text/record)

Minor discrepancies I will not auto-correct (sources differ):

• A third-party portal (Unified Patents) lists priority date 1996‑10‑20 and grant date 1999‑08‑30, whereas Google Patents shows 1996‑10‑21 and 1999‑08‑31. These are likely timezone/one-day indexing variants; I flag rather than resolve them.
• The Google Patents family table shows a 1996‑10‑16 date associated with the application in some rows, while the header lists priority 1996‑10‑21. Treat 1996‑10‑21 (filing/priority) as the operative date per the record, with the caveat above.

Abstract (as given)

A firewall isolates computer/network resources inside it from outside networks, computers and applications. Inside resources may be private databases and LANs; outside objects may be individuals and applications on public networks such as the Internet. Normally a firewall lets inside users originate connections outward but not reverse, outside‑in connections. The invention provides a special "tunneling" mechanism operating on both sides of the firewall to establish such outside‑in connections when requested by certain "trusted" individuals, objects or applications outside the firewall. Its purpose is to minimize the resources needed for tunneled connections while minimizing the security risk of allowing them at all. The mechanism comprises special tunneling applications on interface servers inside and outside the firewall, plus a table of "trusted sockets" created and maintained by the inside tunneling application. Entries define inside objects by inside port, telecommunication protocol, and associated host object. Each entry is "trusted" in that it is supposedly known only to authorized individuals. The applications use the table to effect firewall‑crossing connections in response to outside requests identifying valid entries.

Plain-language overview of each independent claim

Claim 1 — Tunneling apparatus (two interface computers + trusted table + control connection).
The firewall blocks outside objects from directly initiating access to inside objects, while allowing inside‑out initiation. The apparatus has: (a) an outside interface computer between the firewall and outside objects; (b) an inside interface computer between the firewall and inside objects; (c) a special control connection from the inside computer through the firewall to the outside computer, used to carry control information; (d) the inside computer maintains a table of trusted objects and intermittently sends copies to the outside computer over that control connection; (e) entries in the table are the basis for granting/denying access to trusted inside objects; (f) the outside computer selectively forwards outside requests to the inside computer via the control connection when they are directed to trusted objects in the table; and (g) the inside computer, in response, establishes a data connection unique to each request, separate from the control connection, to move data for the trusted object between inside and outside regions.

Claim 6 — Tunneling apparatus (functional/means formulation, with specific table contents).
Same firewall environment and two interface computers. Adds: means in both computers to ascertain identities of trusted objects; means in the outside computer, responsive to an outside request, to cooperate with that ascertaining means to determine whether the request targets a trusted object and, if so, route the request to the inside computer; and means in both computers to form a data connection between the trusted object and the requesting outside object. Critically, the inside portions of the connection, including the segment through the firewall, are formed under the exclusive control of the inside interface computer, while the segment from the outside computer to the requester is formed under the outside computer's control. The ascertaining means specifically includes: creating/maintaining a table of trusted objects at the inside computer; transferring a copy of the table through the firewall to the outside computer; and storing/referring to that copy outside. Each table entry consists of three items: (1) inside object identity, (2) a data communication port assigned to it, and (3) the data communication protocol for that port.

Claim 7 — Computer-readable tunneling software (two program segments + 3-field table).
Software for letting outside data‑handling objects connect to inside ones, comprising inside and outside program segments running on computers respectively inside and outside the firewall (each interfacing between the firewall and the objects on its side). The inside segment: (a) operates the inside computer to create and maintain a table of trusted inside objects, and (b) operates the inside computer, together with the firewall, to provide a copy of that table to the outside segment. Each table entry again has the three items: specific inside object identity, a port of the inside computer allocated to that object, and the required data communication protocol for that object and port.

Claim 9 — Method for enabling outside objects to obtain data connections to selected inside objects.
Steps: (a) create and maintain a table of selected inside objects, each entry having the object, its assigned port, and the protocol assigned to that port; (b) provide a copy of the table outside the firewall; (c) give outside objects a specific security‑clearance access to the entry information; (d) have those outside objects issue requests for the object/port/protocol entity defined by that information; and (e) have computer systems outside and inside the firewall establish a data transmission connection between the specific inside object in each request and the requesting outside object — where the segments lying inside the firewall and passing through it are constructed under the exclusive control of the computer system inside the firewall.

Dependent claims briefly: 2–5 (depend on 1) — table entries with object ID + port; inclusion of a selected protocol; tunneling application programs on both computers; and inside/outside networks whose nodes are served by the interface computers acting as servers. Claim 8 (depends on 7) — the two program segments establish data‑connection segments and tasks in each computer, with segments from the inside object through the firewall built under exclusive control of the inside task. Claim 10 (depends on 9) — a private control connection between inside and outside computers, used exclusively for transmitting requests matching table entries outward‑to‑inward and to sustain setup of the data connections.

Key prior art cited on the face of the patent (for context)

Bellovin & Bellovin "Network Firewalls" (IEEE Comm. Mag., 1994); Cheswick & Bellovin, Firewalls and Internet Security (1994), pp. 86–106; Bryan, "Firewalls for Sale," BYTE (1995); Newman, "Can Firewalls Take the Heat?" (1995); Demizu et al., "DDT—A Versatile Tunneling Technology" (1994); Doty, "A Firewall Overview" (1995); and US patents including 5,283,828; 5,455,953; 5,481,715; 5,416,842; 5,606,617; 5,623,601; 5,632,011; 5,696,898; 5,761,669; 5,623,600; 5,680,461; WO1997016911A1; 5,692,047; and 5,602,918. (Cited‑by references include US 6,061,797, US 6,751,831, US 7,356,978, and many others.)

Uncertainty / caveats

• No 2026 CAFC docket entry specific to 5,944,823 was found. Given the patent expired on 2016‑10‑21, appellate activity in 2026 would be unusual, but I cannot affirmatively rule out an appeal involving it; absence of search results is not proof of absence. I did find unrelated 2026 CAFC/PTAB items (e.g., Flypsi v. Google, Wipqtus v. Samsung, Dolby v. Unified Patents) that do not involve this patent number.
• Current assignee depends on recorded assignment data; Google Patents lists Trend Micro Inc (2010 assignment from IBM). I did not independently verify the chain of title at USPTO Assignment Center.
• The priority/grant‑date one‑day discrepancies noted above remain unresolved by me.
• The claim overlays above are close paraphrases; for any legal purpose, consult the verbatim claim language in the patent (claims 1–10).

I'll research litigation involving US patent 5944823. Let me search multiple sources.

Let me search more specifically on litigation databases.

Let me check the Unified Patents litigation portal and other specific litigation databases directly.

Litigation Search Results: US Patent No. 5,944,823

Bottom line

I was unable to identify any known litigation (district court, CAFC, ITC, or PTAB) specifically asserting or challenging US Patent No. 5,944,823. Within the scope of the searches I was able to run, no case names, docket numbers, or complaints naming this patent as a patent-in-suit were found. I am reporting this as a negative finding rather than asserting with certainty that no such litigation has ever existed.

What I searched

I targeted litigation-oriented sources and exact-identifier queries:

• Unified Patents portal – https://portal.unifiedpatents.com/patents/patent/US-5944823-A (direct patent record page)
• Exact-string queries for "5944823" / "5,944,823" combined with "litigation," "lawsuit," "infringement," "complaint," "asserted," "defendant"
• General web searches across patent-litigation content (CourtListener, Docket Alarm, RPX/insight, Justia, SEC litigation disclosures)

What the sources do show about this patent

The Unified Patents record page for US-5944823-A confirms the bibliographic data and lists no litigation on the patent's face:

Sources:

• https://portal.unifiedpatents.com/patents/patent/US-5944823-A
• https://patents.google.com/patent/[US5944823A](/patent/US5944823A)/en

Caveats you should weigh as counsel

1. Term of enforcement. The patent expired around October 2016 (20 years from the 1996-10-21 filing date). Any infringement suit would therefore predate roughly late 2016. The absence of a Live/notable litigation entry is consistent with a patent that was never commercially enforced after its assignment to Trend Micro.
2. Distinguish from same-numbered patents. Note that "5944823" is not unique as a string: JP 5944823 B2 (a heterocyclic-compound patent) and unrelated documents (e.g., U.S. Pat. No. 8,909,482, "…'482 patent") surfaced in results and must not be conflated with US 5,944,823. I applied the strict rule and did not merge these.
3. The family/continuation. The related continuation child is US 6,061,797 (app. 09/132,915). If you are looking for enforcement activity in this patent family, that continuation is a separate asset worth checking.
4. Empty result ≠ proof of absence. Unified Patents' portal and Google Patents "Litigation" tabs are not exhaustive for pre-2000s cases and settlement-dismissed suits. For a definitive clearance answer, you (or I, with more search access) should run the exact number through Lex Machina, Docket Navigator, or PACER's nationwide party/patent search, and check Westlaw/Lexis for any CAFC appeals.

Recommendation

If you need a litigation-clear opinion, I'd suggest:

• A Lex Machina or Docket Navigator search on the literal string 5,944,823 and 5944823;
• A PACER Case Locator / nationwide search filtered to "patent" and the patent number;
• Checking the USITC (EDIS) for any Section 337 investigation naming the '823 patent; and
• Confirming no PTAB proceedings (IPR/PGR/CBM) exist via the PTAB E2E / PTAB Trials docket using the exact number.

Please note I could not run those proprietary databases here, so I am flagging this as "not found" rather than "does not exist."

Proceedings overview

Total AIA trial proceedings on US 5,944,823: zero (0). The USPTO Open Data Portal returns no AIA trial proceedings for this patent, and my independent web searches surfaced none — no IPR, PGR, or CBM petition naming the '823 patent, no PTAB docket entry, and no Federal Circuit appeal arising from a PTAB proceeding on it. The defensive posture this gives a defendant is therefore unusual and worth stating precisely: all ten claims (1–10) are UNTESTED at the Board and NONE has been canceled or narrowed by any AIA trial. The patent has not been "hardened" by surviving IPRs — it simply has never been through one — so there is no PTAB FWD to attack with and no PTAB estoppel record to hide behind.

---

(No proceedings to report)

There is no proceeding to list. I did not omit anything and I am not declining to report a result — the canonical structured data block states the ODP returns no AIA trial proceedings, and my searches confirmed it.

What I searched (all negative):

• Exact-string queries on 5944823 / 5,944,823 combined with IPR, PGR, CBM, PTAB, petition, institution, final written decision.
• The Unified Patents patent page, which shows the bibliographic record and no litigation or PTAB entries: https://portal.unifiedpatents.com/patents/patent/US-[5944823](/patent/5944823)-A
• Google Patents record for the patent (Litigation/PTAB tabs): https://patents.google.com/patent/[US5944823A](/patent/US5944823A)/en
• USPTO PTAB E2E / PTAB Decisions public search: https://ptacts.uspto.gov/ and https://developer.uspto.gov/ptab-api/ (public-facing trial document portal)

Why the absence is expected here (context, not a fabricated rationale):

• The patent expired 2016‑10‑21 (Google Patents: "Anticipated expiration"; status Expired – Lifetime). Unified Patents lists the same term expiring 2016‑10‑20. I flag the one‑day discrepancy rather than resolve it (see summary section; likely a timezone/indexing variant).
• A CBM petition was never a realistic vehicle: CBMs were limited to patents claiming a "financial product or service," and the '823 claims (firewall tunneling apparatus, software, and method) do not recite financial subject matter. I did not find any CBM on this patent.
• Practical enforcement window: any IPR would realistically have been filed during the pre‑expiration enforcement period. No such filing appears in the record.

⚠️ Do not conflate same‑numbered records. My searches repeatedly returned different patents ending in "823" that are unrelated to this one and must not be merged with it:

• A 2021‑filed cryptographic/cloud patent whose file history appears in IPR papers (that "Inter Partes Review … Case No. … '823 Patent" reference in my results is not US 5,944,823);
• FreeWheel/telecom '823 and a concrete‑admixture '823 referenced in district‑court documents;
• JP 5944823 B2 (a heterocyclic‑compound patent) and U.S. Pat. No. 8,909,482 ("'482 patent").
  None of these is the patent-in-suit here. Per the literal-number rule, I did not auto‑correct or merge any of them.

---

Strategic summary

Claim status across the whole patent. There is no PTAB claim‑level disposition to report, so the operative fact is simpler and cuts against a defendant's PTAB playbook: claims 1–10 all stand exactly as granted, with no certificate of cancellation, no disclaimer, and no adverse judgment on any claim. Independent claim 1 (two interface computers + control connection + trusted‑objects table intermittently copied outward + request forwarding via the control connection + a per‑request data connection separate from the control connection), claim 6 (means‑plus‑function formulation requiring the inside‑region segments, including the through‑firewall segment, to be formed under the exclusive control of the inside interface computer), claim 7 (computer‑readable software with the three‑field table entry), and claim 9 (method with the same three‑field entry and inside‑controlled construction of the through‑firewall segments) are all untested. Dependent claims 2–5, 8, and 10 are likewise untested. There is no "claims 1–5 are dead" argument available — because they are not dead.

Estoppel landscape. Because there is no Final Written Decision in any IPR/PGR/CBM on this patent, § 315(e)(2) estoppel has not attached to anyone. No petitioner (and no privy or real party in interest) is barred from raising invalidity grounds in district court or the ITC. Practically, that is a pro‑defendant point on a single dimension — a defendant is free to run any and all prior‑art grounds in litigation without an estoppel tail — but it is offset by the fact that the same absence of a Board record means there is no PTAB win to point to, no institution‑stage claim-construction ruling to reuse, and no agency finding that any claim is unpatentable.

Pattern signals. There is no petitioner pattern to infer, no repeat filer, no defensive aggregator (e.g., Unified Patents) filing on this patent — the aggregator's own patent page carries no trial entry. The patent‑owner side shows no PTAB appeal activity, consistent with the patent never having been before the Board at all. The ownership history in the record is IBM → Trend Micro (assignment recorded 2010‑05‑17); the family continuation is US 6,061,797 (app. 09/132,915, filed 1998‑08‑12) and PCT/EP family members (EP 0932965 B1, JP 3285882 B2, and others) exist, but I found no AIA trial activity against those either. [Note: my results did surface Trend Micro as petitioner against other parties' firewall patents — e.g., Trend Micro, Inc. v. Cupp Computing AS (Fed. Cir., 2022‑10‑25) on U.S. Pat. Nos. 8,365,272 and 9,756,079 — which is Trend Micro on the offense side of PTAB, unrelated to US 5,944,823 and not evidence of any proceeding involving this patent.]

---

Recommended next steps

If you are a defendant being asserted against (or threatened with) US 5,944,823:

1. There is no PTAB FWD to cite. Do not represent to a court or adversary that any claim has been canceled or that any PTAB estoppel shields (or binds) anyone — it has not and it does not. Any demand letter citing "invalidated claims" would be factually wrong.
2. Check the expiration/enforceability timeline first. The patent's anticipated expiration is 2016‑10‑21 (Google) / 2016‑10‑20 (Unified). Any claim of infringement must therefore rest on conduct before expiration, and any recovery is limited to damages for pre‑expiration activity (subject to the 6‑year § 286 bar). Confirm the exact expiration date from the USPTO Patent Center maintenance‑fee and term records — the one‑day variance in third‑party data is not a substitute.
3. If an IPR is contemplated, note the mechanics and the limits. Institution is decided within ~6 months of the petition's filing/receipt (35 U.S.C. § 314(b)) and the FWD is due within 12 months of institution (§ 316(a)(11)). For an expired patent, the Board applies the Phillips framework rather than the SAS/BRI‑style approach available for unexpired claims — worth raising in the petition's claim‑construction section. Confirm no live § 315(b) one‑year bar issues if you were previously served.
4. Confirm the negative with primary dockets before relying on it. The absence of results here is a finding of "not found," not proof of nonexistence — Unified Patents and Google's tabs are not exhaustive for older or settled matters. Run the exact strings 5,944,823 and 5944823 through Lex Machina, Docket Navigator, and PTAB E2E (https://ptacts.uspto.gov/), and check CourtListener (https://www.courtlistener.com/) and PACER's nationwide search for any appeal or district case. Also check USITC EDIS for a Section 337 investigation, and the PTAB Trials docket for any IPR/PGR/CBM that ODP may not yet have ingested.
5. Treat the family separately. The continuation US 6,061,797 and the foreign members (EP 0932965 B1, JP 3285882 B2, KR 100330619 B1, CA 2269544 C, CN 1107400 C) are distinct assets with their own terms and their own (also apparently absent) PTAB history — screen them independently.

Bottom line for the defendant: the absence of PTAB activity on US 5,944,823 is a weak, not a strong, defensive signal — it means no claim has been canceled, no estoppel exists, and no Board reasoning is on the books. Your invalidity case, if any, will be built from scratch in the district court or the Board, and the most concrete near‑term defense is temporal: the patent appears to have expired in 2016, which forecloses prospective injunctive relief and limits any damages to pre‑expiration conduct.

Sourcing note: the bibliographic facts above (expiration 2016‑10‑21, status Expired – Lifetime, assignment to Trend Micro) are as stated in the authoritative patent record provided, cross‑checked against https://patents.google.com/patent/US5944823A/en and https://portal.unifiedpatents.com/patents/patent/US-5944823-A. The absence of PTAB proceedings is per the structured ODP-derived block and corroborated by the above searches; I could not run the proprietary litigation/trial databases, so this is reported as "not found," not "does not exist."

I'll research the assignment chain for US 5,944,823, starting with the USPTO Patent Assignment Search and cross-referencing sources.

Let me dig into the assignment record specifics and the uspto.report page.

Let me check the specific assignment recording details and the correspondence/attorney of record.

Important limitation up front

I was unable to retrieve the reel/frame numbers or the correspondent of record (attorney/firm) for the assignments on US 5,944,823 from the sources I could reach. What I can verify — from the Google Patents legal‑events feed embedded in the authoritative patent record — is that two post‑filing assignment events exist, with dates, assignors, assignees, and conveyance type. I will not fabricate reel/frame or correspondent data; wherever those fields are unavailable I say so explicitly. Verification entry points:

• https://assignmentcenter.uspto.gov/ (search by patent number 5944823)
• https://assignment.uspto.gov/patent/index.html
• https://patents.google.com/patent/[US5944823A](/patent/US5944823A)/en (legal events)
• https://portal.unifiedpatents.com/patents/patent/US-5944823-A

---

Inventors

• All four assigned their rights to IBM by the filing‑date assignment (Google Patents legal event, 1996‑10‑21, "ASSIGNMENT OF ASSIGNORS INTEREST," assignors JADE, PRASHANTH; MOORE, VICTOR STUART; RAO, ARUN MOHAN; WALTER, GLEN ROBERT). This is the standard employee‑invention assignment and is strong (not conclusive) evidence all four were IBM employees at filing.
• The three Florida residences cluster near IBM's mid‑1990s Boca Raton, FL networking/software operation, consistent with IBM employment. Dallas is also an IBM software location of that era.
• Unusual‑pattern check: I found no evidence that any inventor departed IBM within 12 months of filing, and no evidence of a coordinated inventor exodus. I also found no independent inventor‑side assignments (i.e., no re‑assignment by an individual inventor to a startup/third party), which is what a pre‑fire‑sale pattern would typically show. Not present — but I could not verify departure dates, so this is "no evidence of," not "confirmed no."

---

Original assignee

International Business Machines Corporation (IBM) — named on the issued patent and recorded as assignee on the filing‑date assignment (1996‑10‑21).

• Primary business: mainframe/PC hardware, enterprise software, and IT services; in the relevant period IBM also sold a firewall/network‑security product line (IBM Firewall, later IBM SecureWay/Firewall).
• Product practice: Plausible that IBM commercialized related firewall/tunneling technology, but I cannot confirm that a shipping IBM product embodied the specific "trusted sockets" tunneling claims. Treat practice as unverified.
• Status: still operating (no bankruptcy, no dissolution). Note the patent is no longer IBM's — assigned away in 2010.

---

Assignment timeline

Chronological list of every recorded assignment I could verify. Reel/frame and correspondent could not be retrieved from the accessible sources and are shown as not retrieved — I have not invented values.

• 1996‑10‑21 (executed) / recorded 1996‑10‑21 — Reel not retrieved/NNNN

  • Conveyance: Assignment of assignors' interest (patent assignment)
  • Assignor: Prashanth Jade; Victor Stuart Moore; Arun Mohan Rao; Glen Robert Walters (individually)
  • Assignee: International Business Machines Corporation
  • Correspondent: not retrieved
  • Context: Original employee‑invention assignment executed at filing — the inventors conveyed their rights to their employer; this is the founding link in the chain, not a sale.

• 2010‑05‑17 (executed) / recorded 2010‑05‑17 — Reel not retrieved/NNNN

  • Conveyance: Assignment of assignor's interest
  • Assignor: International Business Machines Corporation
  • Assignee: Trend Micro Incorporated
  • Correspondent: not retrieved
  • Context: Operating‑company‑to‑operating‑company portfolio transfer — IBM divested the patent to security‑software vendor Trend Micro. This is the only post‑issuance transfer; there is no evidence of an intermediate holding LLC or an NPE in the chain.

Child/related asset (same family, separate application): continuation US 6,061,797 (application 09/132,915, filed 1998‑08‑12, same inventors/assignee). If you are tracing enforcement/ownership in this family, the '797 continuation is a separate asset with its own assignment record and should be searched independently.

Status: the '823 patent is Expired – Lifetime, anticipated expiration 2016‑10‑21. No reissue, security agreement, merger, change‑of‑name, license, or release conveyance appeared in the accessible record for this patent. (Absence here reflects the sources I could reach, not a certified negative.)

---

Timeline diagram

timeline
    title Ownership of US 5944823
    1996 : Inventors assign to IBM
    1999 : Patent granted
    2010 : IBM assigns to Trend Micro
    2016 : Patent expires

---

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. The sole post‑issuance assignee is Trend Micro Incorporated, a publicly traded operating security‑software company (2010‑05‑17 event), not an "IP / Licensing / Holdings / Ventures" entity. No registered‑agent address or single‑purpose LLC appears in the retrievable record. (Reel/frame not retrieved, so no address evidence either way.)

2. Known asserter in the chain — NOT PRESENT. Neither assignor (IBM) nor assignee (Trend Micro) matches the enumerated NPE list (Acacia, Marathon, Intellectual Ventures, IPNav, Wi‑LAN, Mosaid/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Lumen View, Round Rock, Erich Spangenberg entities, etc.). Both are/were large operating companies.

3. Repeat correspondent across the chain — UNCLEAR. The correspondent of record was not retrievable from the sources I could reach, so I cannot test for recurrence across the two recorded events, let alone against an NPE‑assertion list. This signal is genuinely undetermined; I decline to infer it from the entity names.

4. Cascading transfers — NOT PRESENT. There is exactly one post‑issuance transfer (2010‑05‑17), from IBM to Trend Micro. That is not a chain of successive LLC assignments within 24 months. No shared‑correspondent or common‑principal pattern is even testable here.

5. Pre-litigation transfer — NOT PRESENT (no litigation to anchor it). My separate litigation search found no district court, CAFC, ITC, or PTAB proceeding naming 5,944,823. With no suit to measure against, the 2010 transfer (six years before expiration) cannot be shown to be "within 6 months before the first infringement suit." Absence of results is not proof of absence, but there is no evidence supporting this signal.

6. Bankruptcy fire-sale — NOT PRESENT. IBM has never filed Chapter 7/11; the 2010 transfer was an ordinary portfolio divestiture, not a bankruptcy sale. No Kodak/Nortel/Polaroid‑style proceeding is implicated.

7. Privateering — UNCLEAR. The transfer is operating‑company‑to‑operating‑company (IBM → Trend Micro), which is the structural prerequisite for privateering, but privateering requires evidence the NPE asserts on the operating company's behalf. I found no assertion by Trend Micro (or anyone) on this patent, no SEC 8‑K/10‑K disclosure tying the transfer to assertion, and no Patent Progress/EFF/RPX coverage. Insufficient evidence to call it either way.

8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. Trend Micro is a product company, so no anti‑NPE neutralization occurred.

---

Verdict

Operating‑company assertion — not supported; and no NPE bucket fits. The chain runs IBM (1996‑10‑21) → Trend Micro (2010‑05‑17) with no intermediate holding LLC, no NPE assignee, no bankruptcy, and no defensive aggregator, so this does not read as an NPE/troll asset. Because my searches found no litigation naming 5,944,823, I cannot label it "Operating‑company assertion" (that requires an operating owner actually suing competitors), and because Trend Micro is not a defensive aggregator I cannot strictly label it "Defensive / non-asserting" either. The most accurate single characterization on the evidence is not an NPE; non‑asserting as far as I could determine, with the important caveat that reel/frame and correspondent were not retrievable, which is exactly the evidence that would confirm or refute shell‑entity and repeat‑correspondent signals.

What would change this call: a reel/frame‑level pull from the USPTO Assignment Center showing (a) any intermediate post‑2000 assignment I did not surface, or (b) a correspondent of record shared with known asserters. Absent that, the two documented links (1996‑10‑21 inventors→IBM; 2010‑05‑17 IBM→Trend Micro) show a conventional operating‑company ownership history.

Verify at: https://assignment.uspto.gov/patent/index.html (search "5944823") and https://portal.unifiedpatents.com/patents/patent/US-5944823-A.

---

Caveats / contradictions to flag

• Contradiction already noted in the summary section and unresolved here: Unified Patents lists priority 1996‑10‑20 / grant 1999‑08‑30, while Google Patents lists 1996‑10‑21 / 1999‑08‑31. This does not affect the assignment analysis.
• Google Patents family table shows a 1996‑10‑16 date in some rows alongside the header's 1996‑10‑21 priority. Per your standing rule, I treat 1996‑10‑21 as the operative filing/priority/assignment date and do not auto‑correct.
• Reel/frame and correspondent of record for both events were not obtained. These are the two fields you specifically asked me to capture; I am flagging their absence rather than guessing, because fabricating reel/frame numbers would corrupt the ownership chain you are reconstructing.

I'll verify the patent record and research the cited references. Let me start with parallel searches.

Let me verify the remaining cited references.

Prior-Art Analysis — US Patent No. 5,944,823

0. Scope, verification, and legal framework

Search executed. I searched the USPTO-derived and mirrored records for the literal number 5944823 (not 5,944,822, not 5,944,824, not JP 5944823 B2, not U.S. 8,909,482). The record I relied on is US 5,944,823 A, "Outside access to computer resources through a firewall," App. No. 08/731,800, filed 1996-10-21, granted 1999-08-31, inventors Jade, Moore, Rao, Walters; original assignee IBM; current assignee Trend Micro Inc. The citation lists below come from the authoritative patent record ("Patent Citations (14)," "Family Cites Families (5)," "Non-Patent Citations (15)") plus the USPTO-report rendering at https://uspto.report/patent/grant/5944823.

Critical date: 1996-10-21 (pre-AIA filing). Because this application was filed before 2013-03-16, pre-AIA 35 U.S.C. § 102 governs. Working dates:

• § 102(b) statutory bar: references printed/published or patented on or before 1995-10-21.
• § 102(a): references published/patented between 1995-10-22 and 1996-10-21.
• § 102(e): U.S. patents (and qualifying published applications) filed before 1996-10-21 by another, even if they issued later.

Two analytical caveats I want stated up front, because they materially change the answer:

1. "Cited reference" ≠ "anticipating reference." The examiner cited these 14 patent documents mostly as general firewall/security state-of-the-art (the field of the invention), not as anticipators. Strict § 102 anticipation requires a single reference disclosing every element of the claim, arranged as in the claim. On the record I can see, no cited reference discloses the full combination of (a) a trusted-socket table created and maintained inside the firewall, (b) copies of that table propagated to an outside interface computer, (c) outside-side validation of requests against that table, (d) forwarding of validated requests over a special control connection, and (e) formation of a request-unique data connection "inside-out" under exclusive control of inside processes. Several references anticipate individual elements, and the combination is a § 103 question — I mark this distinction per reference.
2. One citation is a date trap. WO 97/16911 was published 1997-05-09 — after the 1996-10-21 filing date, so as a publication it is not § 102(a)/(b) art (its pre-AIPA § 102(e) date would run from U.S. national-stage entry, not the 1996 international filing). The operative reference is its U.S. counterpart, US 5,826,029, filed 1995-10-31 — that filing date makes it clean § 102(e) art. I analyze it under that framing.

---

1. The 14 patent citations on the face of US 5,944,823

Reference-by-reference

(1) US 5,283,828 A — "Architecture for utilizing coprocessing systems to increase performance in security adapted computer systems," Hughes Training, Inc.
Full citation: US 5,283,828 A; filed 1991-03-01; granted 1994-02-01. Note the inventor name is rendered "Saunders" on the Google Patents citation table and "Sauders et al." on the US 6,061,797 face — I flag the variant and do not correct it.
Description: hardware/software security architecture for security-adapted computer systems using coprocessing to improve performance. It is a host-security / secure-processor reference, not a firewall-tunneling reference.
§ 102 potential: Background only. It cannot anticipate any of claims 1–10 — it discloses no firewall, no inside/outside regions, no interface servers, no trusted-socket table, no control connection. Cite only as evidence of the security-architecture state of the art (relevant at most to a § 103 "level of ordinary skill" argument).

(2) US 5,416,842 A — "Method and apparatus for key-management scheme for use with internet protocols at site firewalls," Aziz, Sun Microsystems.
Full citation: US 5,416,842 A; filed 1994-06-10; granted 1995-05-16; § 102(b).
Description: public-key/key-management scheme for encrypting traffic at site firewalls, i.e., protecting inside↔Internet protocols at the firewall boundary.
§ 102 potential: No anticipation. It addresses key management for traffic through a firewall; it does not disclose the two-sided tunneling architecture at all. Its only claim-mapping relevance is atmospheric (claims 1/6 recite a firewall separating inside/outside regions). Better cast as § 103 background.

(3) US 5,455,953 A — "Authorization system for obtaining in single step both identification and access rights of client to server directly from encrypted authorization ticket," Russell, Wang Laboratories.
Full citation: US 5,455,953 A; filed 1993-11-03; granted 1995-10-03; § 102(b).
Description: single-step authorization using an encrypted authorization ticket conveying a client's identity and access rights to a server.
§ 102 potential: Element-level only, at best, and weak. If one maps the '823 "trusted socket" entry (information that must be known to be used) onto an authorization ticket, this reference touches the access-rights concept behind claims 1, 6, 9 ("permitting and denying access… when requests… are initiated"). It does not disclose table distribution, control connections, or inside-controlled connection formation. I would not plead this as an anticipator.

(4) US 5,481,715 A — "Method and apparatus for delegated communications in a computer system using trusted deputies," Hamilton et al., Sun Microsystems.
Full citation: US 5,481,715 A; filed 1993-12-15; granted 1996-01-02; § 102(a) (printed publication within one year of filing). (Also available as § 102(e) art by virtue of its 1993 filing date.)
Description: a client delegates work to a "trusted deputy" that acts on the client's behalf in a distributed computer system.
§ 102 potential: The most useful of the "low tier" references for claim-mapping. The '823 claims 4/7/8 require "tunneling application programs"/"program segments" that operate the interface computers to establish and utilize the connection — i.e., a delegate process acting on behalf of a requester. Under a broad construction of "trusted deputies," this reference is relevant to the task/process-creation elements of claims 1, 6 and 8. It is not a full anticipator: no firewall, no table-copy propagation, no through-firewall control connection. Best used in a § 103 combination.

(5) US 5,602,918 A — "Application level security system and method," Chen et al., Virtual Open Network Environment Corp.
Full citation: US 5,602,918 A; filed 1995-12-22; granted 1997-02-11; § 102(e).
Description (verified): establishes secured communications pathways across an open unsecured network by placing a gateway processor / firewall between the Internet and a protected private network; uses a smartcard-distributed shared secret key for mutual authentication between the gateway and the outside client, then generates a session key for further communications. The reference states that "no data is allowed to pass this 'firewall' unless communications are authenticated through the use of a secret key."
§ 102 potential: Med–High as an element reference; not a full anticipator. It is squarely relevant to (i) the firewall defining inside/outside regions with outside-initiated access controlled by an inner gateway (claims 1, 6), and (ii) the "security clearance"/authorization notion in claims 9–10. It does not disclose an inside-maintained table copied outward, a dedicated control connection, or per-request data connections controlled from inside. Note: in an unrelated EPO search report I encountered during research, US 5,602,918 was marked "X" (novelty-destroying) against certain claims of a different application — I do not import that finding here; the EPO document was from another prosecution.

(6) US 5,606,617 A — "Secret-key certificates," Brands.
Full citation: US 5,606,617 A; filed 1994-10-14; granted 1997-02-25; § 102(e).
Description: cryptographic secret-key certificate scheme (blind/undeniable-style credentials).
§ 102 potential: None directly. It is cryptographic-credential art. It could only be reached for the "security clearance" language of claim 9 under a strained reading. Do not plead.

(7) US 5,623,600 A — "Virus detection and removal apparatus for computer networks," Ji et al., Trend Micro Incorporated.
Full citation: US 5,623,600 A; filed 1995-09-26; granted 1997-04-22; § 102(e).
Description: network-level virus detection/removal. Cited presumably for network-gateway content inspection.
§ 102 potential: None. No claim of the '823 patent recites malware screening. Pure field-of-invention background. (Interesting only for assigning-history color: the '823 patent was later assigned to Trend Micro, and this reference shares that assignee.)

(8) US 5,623,601 A — "Apparatus and method for providing a secure gateway for communication and data exchanges between networks," Vu, Milkway Networks Corporation. ⭐
Full citation: US 5,623,601 A; filed 1994-11-18; granted 1997-04-22; § 102(e) (and its grant date is after filing, so it is not § 102(a)/(b)).
Description (verified): a gateway station between a private network and a potentially hostile network, running a kernel modified so the OS cannot forward packets between the two networks and will accept only packets addressed to the gateway itself, plus application-level proxy processes that transparently initiate a first session with the source of an initial packet and a second, independent session with the destination, then pass the data portion between the two sessions. The problem it solves is expressly the '823-type problem: allowing use of services outbound and providing a controlled, non-bypassable interface, while eliminating "back doors."
§ 102 potential: The strongest § 102 anticipation candidate among the 14. Its split-session proxy architecture (two distinct connection segments joined at the gateway, initiated by the gateway rather than passed through) maps onto the core of claims 1 and 6: a segmentation of the data path at the firewall with the inside-side segment controlled by the gateway.
Why it still probably does not fully anticipate claims 1/6: it teaches a single gateway on the firewall and does not disclose (a) the separate inside interface computer and outside interface computer, (b) the trusted-socket table created inside and copied to the outside, or (c) a table-validated request forwarded over a dedicated control connection. So: strong element-level § 102/§ 103 reference for claims 1, 2, 3 (port-based proxy selection) and 6; not a clean single-reference anticipator. Claims 4 (proxy "applications") and 8 (per-computer tasks) are also touched.

(9) US 5,632,011 A — "Electronic mail management system for operation on a host computer system," Landfield et al., Sterling Commerce.
Full citation: US 5,632,011 A; filed 1995-05-22; granted 1997-05-20; § 102(e).
Description: store-and-forward/relay of electronic messages on a host system.
§ 102 potential: Low. A message relay is structurally akin to a store-and-forward intermediary, but nothing in claims 1–10 is anticipated. Use only for the general "intermediary node receiving requests on behalf of endpoints" flavor, if at all.

(10) US 5,680,461 A — "Secure network protocol system and method," McManis, Sun Microsystems.
Full citation: US 5,680,461 A; filed 1995-10-26; granted 1997-10-21; § 102(e).
Description: a secure network protocol providing a protected channel between machines.
§ 102 potential: Med as an element reference. It is relevant to the special control connection element of claim 1 (a dedicated, protected channel between the two sides) and to claim 10 (a "private control connection"). It does not disclose the trusted-socket table or table propagation, and it is not a tunneling/firewall-traversal reference. § 103 combination material.

(11) US 5,692,047 A — "System and method for executing verifiable programs with facility for using non-verifiable programs from trusted sources," McManis, Sun Microsystems.
Full citation: US 5,692,047 A; filed 1995-12-08; granted 1997-11-25; § 102(e).
Description: executing verifiable programs while permitting use of programs from trusted sources.
§ 102 potential: Low–Med. Relevant only to the software claims (7, 8) and to the "trusted" nomenclature. No table, no tunneling, no firewall traversal. Do not plead as an anticipator; possible § 103 garnish.

(12) US 5,696,898 A — "System and method for database access control," Baker et al., Lucent Technologies.
Full citation: US 5,696,898 A; filed 1995-06-06; granted 1997-12-09; § 102(e).
Description: controlling access to objects/data across multiple operating systems (cross-referenced with US 5,761,669, below, same filing date).
§ 102 potential: Low–Med. Loosely relevant to "access to trusted objects in the inside region" (claims 1, 6, 9) and to the inside "host object" concept. No network tunneling, no table-copy, no control connection. Combination material at best.

(13) US 5,761,669 A — "Controlling access to objects on multiple operating systems," Montague et al., Microsoft Corporation.
Full citation: US 5,761,669 A; filed 1995-06-06; granted 1998-06-02; § 102(e).
Description: object access control spanning multiple operating systems (companion to US 5,696,898).
§ 102 potential: Low. Same disposition as #12 — "object access control" vocabulary overlaps the claim language ("objects… permitting and denying access"), but no firewall, no tunneling, no trusted-socket table. Not an anticipator.

(14) WO 97/16911 A1 — "Secured gateway interface," IBM. ⭐ (analyze via US 5,826,029)
Full citation: WO 97/16911 A1; PCT/GB96/00664, international filing 1996-03-20; priority 1995-10-31; published 1997-05-09.
The operative U.S. counterpart: US 5,826,029 A, "Secured gateway interface," filed 1995-10-31 (Ser. No. 08/551,260), granted 1998-10-20 — § 102(e) prior art because it was filed before 1996-10-21.
Description (verified): an SGI residing on a pair of servers — external server 310 outside firewall 300 and internal server 320 inside firewall 300 — running an outside daemon 312 and an inside daemon 322 "thereby enabling communication across firewall 300." The connection between them is authenticated and initiated by the internal computer. External users' transaction requests are received on the external server, passed to the internal server over the authenticated connection, recreated in the internal process environment, and executed by the internal server against the internal database, with the whole process "transparent to the user."
§ 102 potential: Highest of all cited references — and the closest thing to an anticipator for claims 1, 6, 9, and 10. Mapping:

• Two interface machines straddling the firewall (claims 1, 6, 7) — disclosed (external server/internal server).
• Outside-initiated request reaching inside resources through the firewall, with inside resources otherwise protected (claims 1, 6, 9) — disclosed.
• Authenticated connection initiated from inside between the two servers, used to carry the outside request inward (claim 1's special control connection; claim 10's private control connection) — substantially disclosed.
• Execution of the transaction inside the firewall, under inside control (claim 9's "constructed under exclusive control of said computer system inside said firewall") — substantially disclosed.
• What it does not disclose: the table of trusted objects and, critically, "intermittently providing copies of said table to said outside interface computer through said control connection," with outside-side validation against that copied table. That limitation is the principal distinguishing feature.

Conclusion on the 14: the only references I would put in a § 102 invalidity contention as lead references are (14) US 5,826,029 / WO 97/16911 and (8) US 5,623,601. The remainder belong in a § 103 combination or as background.

---

2. "Family Cites Families (5)" — references cited in the family (incl. the continuation)

These are cited in the family/continuation chain rather than on the '823 face; the U.S. continuation US 6,061,797 expressly lists US 5,548,646 and US 5,826,014 among its references.

US 5,826,014 A (Coley/Wesinger) — High relevance. Verified description: a stand-alone firewall box between the public network and protected elements; a plurality of proxy agents "specifically assigned to an incoming request in accordance with the service protocol (i.e., port number)"; the assigned proxy agent verifies the authority of the incoming request and, only if verified, initiates the connection to the protected network element on behalf of the request source, maintaining "anonymity on each side of the firewall."
§ 102 potential: it directly maps the port-indexed admission control of claims 1, 2, 3 and the proxy-mediated inside connection of claims 1, 6. Its weakness against the '823 claims is the same as US 5,623,601's: no propagated trusted-object table and no two-machine control connection. Strong § 102/§ 103 reference; not a complete anticipator.

US 5,548,646 A (Aziz) — High relevance (tunneling). Verified description: a tunnelling bridge at each private network that intercepts outgoing packets, determines from tables whether each packet should be encrypted, encrypts and encapsulates it with source/destination addressing, and sends it over the internetwork — i.e., firewall-crossing tunneling using tables and encryption, with keys obtainable from a directory server.
§ 102 potential: the closest cited art on the "tunneling through/around a firewall" concept itself, and its table-driven decision to encrypt/encapsulate per packet is conceptually adjacent to the trusted-socket table. It is directional (inside→out), not outside→in, so it does not anticipate claims 1/6/9's outside-initiated path. Relevant to claims 1, 6 element-level and to a § 103 combination with US 5,826,029.

---

3. Non-patent literature (15 entries; 8 distinct works)

Key observations:

• Demizu et al. ("DDT") is the NPL most relevant to the claimed subject matter: it is a tunneling technology reference and is the natural § 103 partner for the tunneling-concentration/encapsulation aspects of claims 1 and 6. It is a 1994 publication, so § 102(b).
• The "Symposium on Network and Distributed System Security" proceedings (pp. 31–41) is almost certainly the Stempel, "IpAccess—An Internet Service Access System for Firewall Installations" paper (same conference/year/page range appears as "Stempel" in US 5,826,014's reference list). I flag this as my inference, not a verified identity, since the '823 citation table omits the author name.
• The PCT IPER dated 1997-10-02 is not prior art — it post-dates the 1996-10-21 filing. It is a prosecution document and should never be cited as § 102 art. (It is also "self-referential," being the IPER for this very family's PCT application.)
• Note the citation table lists "Bellovin S M et al" twice for the same article; I treat it as a single reference.

---

4. Consolidated § 102 ranking and recommendation

Lead § 102 references (worth charting):

1. US 5,826,029 A (U.S. counterpart of WO 97/16911), filed 1995-10-31, granted 1998-10-20 — § 102(e). Best candidate for claims 1, 6, 9, 10; defeated on the "trusted-object table copied outward" limitation.
2. US 5,623,601 A (Vu/Milkway), filed 1994-11-18 — § 102(e). Best candidate for claims 1, 2, 3, 6; defeated on the two-interface-computer + table-copy limitations.
3. US 5,826,014 A (Coley/Wesinger), filed 1996-02-06 — § 102(e). Strong for claims 1, 2, 3, 6; defeated on table propagation and control connection.
4. US 5,548,646 A (Aziz), filed 1994-09-15 — § 102(a)/(e). Tunneling-bridge art for claims 1, 6; directionality (inside-out) defeats the outside-in claims.
5. US 5,602,918 A (Chen), filed 1995-12-22 — § 102(e). Gateway/firewall + mutual authentication for claims 1, 6, 9; no table copy/control connection.

Best § 103 combination: US 5,826,029 (two servers straddling a firewall + authenticated inside-initiated connection + outside-initiated transaction reaching inside resources) in view of US 5,623,601 or US 5,826,014 (port-indexed proxy admission control) and Demizu et al. (tunneling), with US 5,548,646 or US 5,680,461 for the dedicated control channel — targeting the "table created inside, copies provided to the outside computer through the control connection, outside-side validation" bridge that seems to be the actual point of novelty.

References that should not be advanced as § 102 art: US 5,283,828; US 5,606,617; US 5,623,600; US 5,632,011; US 5,761,669; US 5,444,850; US 5,113,499; RU 2022346 C1; and the PCT IPER.

---

5. Caveats (stated plainly)

• Verification depth: I verified the full text of US 5,623,601, US 5,826,014, US 5,602,918, WO 97/16911, and the '823 patent itself. For US 5,283,828, US 5,455,953, US 5,481,715, US 5,606,617, US 5,623,600, US 5,632,011, US 5,680,461, US 5,692,047, US 5,696,898, US 5,761,669, US 5,113,499, US 5,444,850 and RU 2022346 C1, I relied on the patent record's citation tables plus the titles/assignees/dates as listed; descriptions for those are at a higher level of generality and should be confirmed against each reference's full text before any charting is filed.
• Dates: All filing/grant dates above are as given in the '823 record. As previously noted, third-party portals (e.g., Unified Patents) show a one-day offset for the '823 priority/grant dates (1996-10-20 / 1999-08-30) relative to Google Patents (1996-10-21 / 1999-08-31); this does not change any § 102 conclusion here.
• Anticipation vs. obviousness: My per-reference "potential § 102" callouts identify the claims a reference could be charted against. Most fail as single-reference anticipators, and I have said so explicitly rather than papering over it. For a definitive invalidity position, each lead reference needs to be read element-by-element against the verbatim claim text (claims 1–10 as issued), not against my paraphrase.

I'll ground this analysis in the actual prior-art references from the patent record. Let me pull key content on the most relevant ones.

Obviousness Analysis — U.S. Patent No. 5,944,823 under 35 U.S.C. § 103

Date note: The task header states April 26, 2026, while the system date is October 1, 2026. I've used a current date of April 26, 2026, but the analysis is essentially date-insensitive because the §103 inquiry is anchored to the 1996‑10‑21 priority/filing date and to art that predates it.

Scope note (building on the prior sections): This analysis builds on the claim overlays and bibliographic findings already generated. As those sections established, the '823 patent expired 2016‑10‑21 and I found no litigation. The §103 analysis below is therefore prospective/defensive — it is the kind of record a challenger, licensee, or IPR petitioner would build — not a dispute over live enforcement.

Governing standard. I apply the Graham v. John Deere framework (scope/content of claims; scope/content of prior art; differences; secondary considerations), as refined by KSR Int'l v. Teleflex (2007) — i.e., a "person having ordinary skill in the art" (PHOSITA) may combine known elements where the combination yields predictable results and there was an articulated reason or design incentive to do so. I do not apply the stricter pre-KSR "teaching, suggestion, or motivation" test as a rigid requirement, but I do identify concrete motivations because the user asked for them.

Assumed PHOSITA. As of October 1996: a network-security engineer with a bachelor's degree (or equivalent) in CS/EE and ~2–3 years of experience building TCP/IP internetwork security systems (packet filters, application gateways, proxy firewalls), familiar with the then-current firewall literature (Cheswick & Bellovin, Bellovin, Bryan, Doty) and with TCP/IP ports/protocols.

---

1. The claims, distilled to their inventive core

The independent claims (1, 6, 7, 9) share the same essential architecture. Reducing to elements:

The genuine novelty is the intersection of D + E + F + G: a trusted‑entry table that is authoritative inside, replicated outward over a private control channel, used by the outside box merely to filter/route, with the actual data path spliced through the firewall by the inside process.

---

2. The cited references and what each actually teaches

These are the references on the face of the '823 patent (Patent Citations, Non‑Patent Citations, and Family Cites Families). I verified the teachings of the four most load‑bearing ones by retrieval; for the remainder I rely on their titles/assignees and note the confidence level.

R1 — WO 1997/016911 A1, IBM, "Secured gateway interface" (priority 1995‑10‑31; U.S. sibling US 5,826,029). Verified. This is the single most material reference, and it is on the face of the '823 patent. It discloses:

• Two servers straddling a firewall: "External server 310 resides outside firewall 300, while internal server 320 resides inside firewall 300." Firewall "prevents external transactions from passing through it to internal server."
• An outside daemon 312 and inside daemon 322 that communicate across the firewall ("thereby enabling communication across firewall 300").
• The connection is authenticated and initiated from the inside out: claim language recites "authenticating a connection initiated by the internal computer system between the internal computer system and the external computer system, thereby establishing an authenticated connection," and an object is "to securely authorize a connection between an internal computer system and an external computer system before the external computer system receives transaction requests from users."
• Outside‑initiated requests are transmitted inward over that authenticated connection: the internal system "receiv[es]… the string [transaction request + process environment] through the authenticated connection," verifies it, recreates the environment, executes, and returns output.
• The outside server holds only “special” scripts that name the actual inside transaction programs; "the requests available to the customer are limited to the perl scripts and corresponding transactional programs residing in cgi‑bin 415 and cgi‑bin 426."

R1 maps nearly 1:1 onto elements A, B, C, D, F, and the inside‑controlled execution of G.

R2 — U.S. 5,623,601, Milkway Networks (inventor Vu), "Apparatus and method for providing a secure gateway…" (priority 1994‑11‑18). Verified. Teaches a gateway/firewall between a private and a public network with application‑level proxies; the gateway "transparently initiate[s] a first communications session with a source… and a second independent communications session with a destination… without intervention by the source," then relays data between them. It expressly ties services to port numbers and recognizes that "certain internetwork services have been assigned specific ports," and it maintains/consults rule bases to determine "access rights."

R3 — U.S. 5,626,014? / U.S. 5,826,014, Coley & Wesinger, Network Engineering Software, "Firewall system for protecting network elements connected to a public network" (priority 1996‑02‑06). Verified (this reference appears in the '823 patent's "Family Cites Families" list as US5826014A). Teaches a firewall whose "application includes a variety of proxy agents that are specifically assigned to an incoming request in accordance with the service protocol (i.e., port number) indicated in the incoming access request," where "an assigned proxy agent verifies the authority of an incoming request… Once verified, the proxy agent completes the connection to the protected network element on behalf of the source" — i.e., an inbound, externally‑originated request is validated and then a fresh inside connection is opened on the requester's behalf. It also teaches protocol‑sensitivity per port and "time of day" validation.

R4 — Demizu & Yamaguchi, "DDT — A Versatile Tunneling Technology," Computer Networks and ISDN Systems 27(3):493–502 (Dec. 1994). Verified. Cited on the face of the '823 patent. Teaches (i) tunneling/encapsulation as a general mechanism; (ii) a virtual network created "between the department and the firewall gateway" to cross a firewall boundary; (iii) that tunneling may be connectionless or connection‑oriented, with policy‑based tunnel selection; and (iv) that tunneling requires encapsulation/decapsulation at tunnel endpoints. In other words, R4 supplies the "tunneling application"/encapsulation concept and the notion of using a firewall gateway as a tunnel endpoint.

R5 — Bellovin & Bellovin, "Network Firewalls," IEEE Communications Magazine (Sept. 1994), and Cheswick & Bellovin, Firewalls and Internet Security (1994), pp. 86–106. Title/context verified; teachings are standard. Establish the bastion host / dual‑homed gateway / application‑gateway taxonomy, the "deny‑by‑default" rule, and the practice of running separate hosts on each side of a firewall for security ("defense in depth"). Background art, not the point of novelty.

R6 — Stempel, "IpAccess — An Internet Service Access System for Firewall Installations," Proc. Symposium on Network and Distributed System Security, San Diego, Feb. 16–17, 1995, pp. 31–41 (the NPL item appearing simply as "Symposium on Network and Distributed System Security… Proceedings, pp. 31–41"). Teaching inferred from title/secondary corroboration. Describes an internet service access system interposed at a firewall to accept external service requests and mediate access to internal services.

R7 — U.S. 5,416,842, Aziz (Sun), "key‑management scheme for internet protocols at site firewalls" (1994‑06‑10); U.S. 5,548,646, Aziz et al. (Sun), "signatureless transmission… between computer networks" (1994‑09‑15); U.S. 5,481,715, Sun, "delegated communications… using trusted deputies" (1993‑12‑15). Titles verified; content from titles/secondary sources. These supply cryptographic authentication/key management at a firewall and the trusted‑intermediary/delegation concept (a "deputy" acting on behalf of a principal across a trust boundary) — directly relevant to element D (a private authenticated control channel) and to the "trusted" aspect of the table.

R8 — U.S. 5,455,953, Wang, "Authorization system for obtaining in single step both identification and access rights…" (1993‑11‑03); U.S. 5,606,617, Brands, "Secret‑key certificates" (1994‑10‑14); U.S. 5,602,918, Virtual Open Network Environment, "Application level security system and method" (1995‑12‑22); U.S. 5,692,047, Sun, "executing verifiable programs… from trusted sources" (1995‑12‑08); U.S. 5,689,898, Lucent, "System and method for database access control" (1995‑06‑06). These provide ticket/certificate‑based authorization and application‑level access control — i.e., the "security clearance" concept in claim 9(c) and the "trusted" characterization of entries.

R9 — Remaining cited art (U.S. 5,283,828 Hughes Training; U.S. 5,632,011 Sterling Commerce; U.S. 5,623,600 Trend Micro; U.S. 5,680,461 Sun; U.S. 5,761,669 Microsoft; Bryan BYTE 1995; Newman 1995; Doty 1995) is peripheral and does not carry the analysis.

---

3. Claim 1 — the primary combination is obvious

3.1 Proposed combination for claim 1

R1 (IBM Secured Gateway Interface) in view of R4 (Demizu DDT), further in view of R2 (Milkway) and/or R3 (Coley), on the foundation of R5.

Element‑by‑element:

3.2 Why the PHOSITA would have combined them

• Same field, same problem, same architecture. R1, R2, R3, R4, and R5 all address the problem of letting an authorized external party reach resources behind a firewall without opening an inbound hole. R1 already teaches the two‑server, inside‑initiated‑authenticated‑connection design the '823 patent's preamble assumes; the '823 patent effectively re‑labels R1's "authenticated connection" as a "control connection" and R1's executed transaction as the "data connection."
• Predictable result. Combining a two‑server gateway (R1) with a port/protocol‑indexed proxy table (R2/R3) and a tunneling/virtual‑network mechanism (R4) yields nothing more than the expected aggregation of (i) a secure setup channel, (ii) an access‑control list keyed to ports/protocols, and (iii) a data path through the firewall. KSR teaches that such an arrangement of known elements, each performing its known function, is obvious absent an unexpected result — and the '823 patent identifies none.
• Design incentive / market pressure. R5's own literature documents that pre‑1996 firewall designers were actively seeking to extend application gateway access to "dynamic port allocations" and arbitrary services (articulated in R2's background as a drawback to be solved). The motivation to reuse the inside‑initiated channel to distribute the access list outward, rather than open a new inbound port, is exactly the incentive driving R1's stated object ("before the external computer system receives transaction requests") and R4's "connecting isolated networks."

3.3 The distinctive limitations, addressed

• "Intermittently providing copies of said table… through said control connection" (E). R1's outside server is deliberately not given the inside programs; it is given mirrors/indexes and can serve only transactions matching them — a distributed, out‑of‑date‑able set pushed from the secure side. That is a copy of the permissible‑transaction set. Even if one resists that reading, the duplication of a modest configuration/rule list from a trusted inside server to a less‑trusted outside server is an utterly routine engineering choice with a well‑understood security rationale (keep authority inside; give the outside box only what it needs to filter). A PHOSITA would do it to avoid round‑tripping every request to the inside server.
• "Data connection… separate from said control connection" and "formed under exclusive control of processes operating in said inside region" (G). R2/R3 teach exactly the "two independent sessions, spliced by a proxy" structure, and R1 teaches that the inside system executes the transaction after authenticating. Combining these yields an inside‑controlled data path distinct from the setup channel.

Conclusion on claim 1: obvious over R1 + R4 + (R2 or R3), with R5/R7 as supporting art.

---

4. Dependent claims 2–5

• Claim 2 (entry = object identity + the port used for the data connection). R2 assigns proxies/services by port number; R3 assigns "a proxy agent… in accordance with the service protocol (i.e., port number)" to the specific network element. A table pairing an object with its port for the data connection is the express teaching of R2/R3. Obvious.
• Claim 3 (entry includes a selected protocol). R2 and R3 both teach that a port is associated with a protocol/service and that the gateway is protocol‑sensitive per port. Adding the protocol field to the entry is a nominal, anticipated refinement. Obvious.
• Claim 4 (tunneling application programs on both computers). R1 is expressly "a uniquely programmed computer system, and a memory embodying detailed logic"; R4 is an implemented tunneling system (BSD). Obvious.
• Claim 5 (inside/outside networks with plural nodes; interface computers act as servers). R1: external network ("the INTERNET") and an "internal corporate information network," with servers 310/320 fronting them. R2: private network + public network with a gateway station. Obvious.

---

5. Claim 6 (means‑plus‑function; the three‑field entry is the target)

Claim 6 recites the same apparatus in §112(6) form and adds the specific entry format {inside object, port, protocol} plus "means for transferring a copy of said table through the firewall."

• The "ascertaining means… table… transfer a copy… store and refer to the copied table" is the R1 architecture (authoritative information inside; a limiting, mirrored set outside reached over the authenticated connection) combined with R2/R3's port/object tables.
• The triplet format is taught by R2 (port‑keyed services/rules) and R3 (port‑keyed, protocol‑sensitive proxy assignment to a specific protected element), with R8 supplying the "trusted/authorized" characterization.
• Obvious, for the same reasons and on the same combination as claim 1.

Note on §112(6): the corresponding structure in the '823 spec is the tunneling applications on servers A/B; the analogous structure in R1 (outside daemon 312 / inside daemon 322 with service program 324) is a straightforward counterpart. No structural gap.

---

6. Claims 7 and 8 (software claims)

• Claim 7: inside/outside program segments; inside segment creates/maintains the trusted table and provides a copy outside; entries are the same triplet. R1 discloses the two‑segment, two‑machine program product (external server code + internal server code, with the internal side holding the real transaction programs and a limited mirror placed on the external side). R2/R3 supply the port/protocol/object table. Obvious under R1 + R2/R3.
• Claim 8: each segment establishes data‑connection segments and tasks, with the through‑firewall portion built under exclusive control of the inside task. R1's forking daemons (inside/outside daemons that fork child processes per request — "a UNIX process fork") provide the "tasks"; R2/R3's dual‑session proxy provides the segmented data connection; R1's inside‑initiated execution provides "exclusive control of the inside task." Obvious under R1 + R2/R3 (+ R4 for the tunnel/encapsulation step).

---

7. Claims 9 and 10 (method claims)

• Claim 9 step (c) — "providing outside objects with a specific security clearance access to items of information constituting an entry in said table" — is the authentication/authorization beat. R8 (Wang's authorization tickets; Brands' certificates; VONE's application‑level security) and R1's authentication of the outside client routine and per‑client passwords teach distributing an authorization credential that corresponds to a permitted entry. Steps (a), (b), (d), (e) track R1 + R2/R3 as above. Obvious.
• Claim 10 — a private control connection used exclusively for transmitting table‑matching requests and for setting up the data connections. R1 teaches that the authenticated connection between the servers is used to carry the transaction request and to authorize the connection, and R7 supplies the key‑management that renders it private/exclusive. R2/R3's separation of a session‑setup/validation phase from the data‑splice phase reinforces "exclusively." Obvious.

---

8. Motivation to combine — consolidated (KSR factors)

1. Same field of endeavor. All principal references (R1–R5) are firewall/tunneling/network‑security art from 1994–1996.
2. Same problem, expressly stated. R1's object is to let an external user "initiate an authorized business transaction utilizing internal business resources without violating security firewalls." That is verbatim the '823 patent's stated problem (the "telecommuting" paragraph in its Background).
3. Known, mutually complementary techniques. (i) a two‑server gateway with an inside‑initiated authenticated channel (R1, R7); (ii) port/protocol‑indexed proxy validation (R2, R3); (iii) tunneling/encapsulation to cross a firewall (R4). A PHOSITA assembling a secure "outside‑in" access facility would predictably reach for all three.
4. Reasonable expectation of success. Each element was independently implemented and deployed in 1994–1995 systems; nothing in the '823 patent reports an unexpected result or a technical leap.
5. Design need. R2's own background criticizes prior application gateways for not supporting dynamic ports and for requiring "back doors"; R1 criticizes opening a firewall port as leaving the network "subject to external attack." These are express motivations to do precisely what the '823 claims.

---

9. Where the obviousness case is weakest (candor check)

I flag these honestly rather than overstate the attack:

1. The "push a copy of the table outward" step (E) is the least explicitly met by any single reference. R1 stores the real programs inside and mirrors "special" scripts outside; whether that is legally a "copy of the table" is a factual dispute. It is strongest as a combination argument (R2/R3 table + routine configuration replication) and weakest as a single‑reference argument.
2. The "control connection separate from the data connection" formulation (G/D) is well supported by R1+R2 (setup channel vs. spliced data sessions), but the '823 claim's insistence that the through‑firewall segment be inside‑controlled overlaps heavily with R1 alone — which cuts against patentability but also means the claim may be anticipated (rather than merely obvious) by R1 in an IPR, a distinction that matters procedurally (see below).
3. Claim 9(c)'s "specific security clearance" is soft language that reads on ordinary authentication; a patentee could argue it implies a pre‑shared secret entry known only to cleared users. R8 is responsive but not a bullseye.
4. Reference dates. R6 (Stempel, Feb. 1995) and R3 (US 5,826,014, priority 1996‑02‑06) both predate the '823 filing (1996‑10‑21) and are available as §102(b)/§102(a) art; R1 (published 1997‑05‑09) is §102(e) art via its 1995‑10‑31 priority. I have not independently confirmed that R6's actual disclosure reaches the claimed subject matter — I am relying on its title and secondary corroboration, and I flag that as a gap a real petition would need to close by obtaining the paper.

---

10. Bottom line

• The '823 claims are, in my assessment, likely obvious under §103 over a small set of references that the patent itself already cites — principally WO 1997/016911 A1 (IBM, "Secured gateway interface") as the primary reference, combined with Demizu & Yamaguchi, "DDT — A Versatile Tunneling Technology" and with U.S. 5,623,601 (Milkway) and/or U.S. 5,826,014 (Coley) for the port/protocol/object table and the dual‑session proxy structure, on the background of Bellovin/Cheswick.
• The single most damaging reference is IBM's own WO 1997/016911 A1, which teaches the two‑server straddling architecture, an inside‑initiated authenticated control connection through the firewall, and outside‑requested transactions executed inside — the very heart of claim 1.
• Claims depending on the three‑field entry (2, 3, 6, 7, 9) add nothing beyond R2/R3's port‑and‑protocol‑indexed proxy tables.
• The software claims 7–8 and method claims 9–10 fall with the apparatus claims; claim 10's "exclusive private control connection" is met by R1 + R7's key management.
• Procedural caveat: because R1 appears to disclose much of element G outright, a challenger could plead §102 anticipation by R1 in the alternative to §103. Whether that succeeds depends on the exact claim language and the treatment of the "table copy" step — which is why the combination theory above (rather than a single‑reference theory) is the more robust posture.
• Timing caveat: the patent expired 2016‑10‑21, and no litigation was identified, so this analysis has no current injunction/damages application; it would matter only for a validity‑contested matter (e.g., an IPR on a related continuation such as US 6,061,797, or a historical damages period). I flag that I could not verify the content of R6 (Stempel) directly; that single gap is the one I would close before filing a petition.