US 6098172

I'll search for authoritative information on this patent number.

Let me search for litigation and any CAFC 2026 activity specifically.

Search Results: US Patent 6,098,172

Scope note: I searched for the literal identifier 6098172 (US Patent No. 6,098,172) and excluded similar-looking numbers. The number resolves uniquely to one granted US patent; I did not find any CAFC 2026 docket activity for this patent (see "Litigation / CAFC" below).

Bibliographic Data

Sources: https://patents.google.com/patent/US6098172/en · https://uspto.report/patent/grant/6,098,172 · https://www.everypatent.com/comp/pat6098172.html · https://insight.rpxcorp.com/patent/[US6098172A](/patent/US6098172A)

Abstract (verbatim)

"Computer network firewalls which include one or more features for increased processing efficiency are provided. A firewall in accordance with the invention can support multiple security policies, multiple users or both, by applying any one of several distinct sets of access rules. The firewall can also be configured to utilize 'stateful' packet filtering which involves caching rule processing results for one or more packets, and then utilizing the cached results to bypass rule processing for subsequent similar packets. To facilitate passage to a user, by a firewall, of a separate later transmission which is properly in response to an original transmission, a dependency mask can be set based on session data items such as source host address, destination host address, and type of service. The mask can be used to query a cache of active sessions being processed by the firewall, such that a rule can be selected based on the number of sessions that satisfy the query. Dynamic rules may be used in addition to pre-loaded access rules in order to simplify rule processing. To unburden the firewall of application proxies, the firewall can be enabled to redirect a network session to a separate server for processing."

Overview of the Invention (plain language)

The patent describes a firewall that, instead of running all application proxies locally, can redirect ("reflect") a session to a separate remote server or remote proxy for processing, and then pass the session back through the firewall to the intended original destination. Two modes are described in the specification:

• Single reflection (one-way): the remote proxy connects to the destination under its own IP address.
• Dual reflection (two-way): the firewall rewrites header values so the connection appears at the destination to originate from the original source, and the firewall hands the proxy a unique destination port number to demultiplex the return connection. Dynamic rules are loaded by the firewall to authorize these proxy-originated connections.

Note: the asserted claims are narrower than the specification. The specification also covers multiple-domain support, stateful caching, dependency masks, and dynamic rules, but those aspects are the subject of a separate Lucent patent (US 7,143,438, "…firewall with multiple domain support"), not the independent claims here.

Independent Claims in Plain Language

The independent claims are 1, 5, 9, 13, 17, 21, 27, 33, 35, 36, and 38. They cluster into four groups.

Group A — "redirect to a remote server" (claims 1, 5)

• Claim 1: A firewall method: receive a request for a session from a source to a destination; determine whether granting the request requires a service that can be fulfilled by a remote server; if so, redirect the request's packets to that remote server. (No stated purpose clause — the broadest claim.)
• Claim 5: Same steps, but the redirect is expressed as being "so that the service can be provided by said remote server" — i.e., it adds an intended-result clause.

Group B — "redirect to a remote proxy" (claims 9, 13, 17)

• Claim 9: Same as claim 1 but the remote entity is a remote proxy.
• Claim 13: Same as claim 5 (with the "so that the service can be provided" clause), but remote proxy.
• Claim 17: Receive request at firewall; determine whether granting it requires a service performable by a remote proxy; if so, set up a dynamic rule to enable an appearance of a direct connection from the source to the destination. (This is the "dual reflection" concept tied to dynamic rule creation.)

Group C — computer systems / apparatus for "redirect" (claims 21, 27)

• Claim 21: A means-plus-function system: means for obtaining the session request; means for ascertaining whether the request requires a service performable by a remote server; means for redirecting packets to the remote server so the service can be performed.
• Claim 27: A processor-based system operable to do the same three things (obtain / ascertain re: remote server / redirect).

Group D — "reflecting" claims (claims 33, 35, 36, 38)

• Claim 33: Firewall method: receive request; ascertain whether granting it requires a service providable by a remote proxy; if so, reflect the packets to the remote proxy so the service can be performed by it. (Claim 34 depends on it, adding: inform the remote proxy of the destination, and have packets associated with the performed service go from the remote proxy to the destination.)
• Claim 35: Method without a "firewall" limitation and with different wording: obtain a request; ascertain whether it "requires a service which can be met by a remote server"; reflect packets to the remote server so the service can be performed.
• Claim 36: Apparatus with at least one processor operable to receive the request at a firewall, ascertain whether a remote-proxy-performable service is required, and reflect packets to the remote proxy. (Claim 37 depends on it, adding the "inform the remote proxy of the destination" function.)
• Claim 38: Apparatus with at least one processor operable to obtain the request, ascertain whether it requires a service "which can be met by a remote server," and reflect packets to the remote server.

Common dependent-claim themes: using session key data (and specifically session key data in a table look-up) for the ascertaining step; having the performed service appear to the destination as coming from the source; and referring to a dynamic rule for routing the service packets back to the destination.

Litigation and CAFC Status

Identified district-court litigation (single matter):

• Alcatel Lucent USA Inc. v. Fortinet Inc., D. Del. 1:14-cv-00574 — Patent Infringement, filed 05/01/2014, status Closed. (This is the case flagged on the Google Patents page for this patent.) Source: https://ai-lab-cl-prod.azurewebsites.net/case/dct/ded/1:14-cv-00574/alcatel-lucent-usa-inc-v-fortinet-inc

CAFC 2026 dockets: I found no Federal Circuit docket, opinion, or pending appeal in 2026 (or any year) involving US 6,098,172. I ran targeted searches of CAFC 2026 decision round-ups (IPWatchdog, JD Supra, A&O Shearman, CourtListener) and no entry matched this patent number. Because the patent expired 2017-09-12, further appellate activity concerning it is unlikely.

Unverified / caveats:

• Google Patents displays a "First worldwide family litigation filed" link to a Darts-IP record keyed to family ID 25456779. I could not open that record to confirm its contents, so I treat it as unverified and cannot confirm whether it corresponds to the Delaware case above or a different matter.
• Google Patents' litigation panel is auto-populated and may be incomplete or inaccurate; absence of CAFC activity in my searches is not proof that none exists.

U.S. Patent Office (non-litigation) note: US 6,098,172 appears as cited prior art in unrelated ex parte reexamination materials (e.g., Reexam Control No. 90/012,342 concerning US 6,779,118). I found no reexamination, IPR, PGR, or other post-grant proceeding against US 6,098,172 itself.

Points of Uncertainty / Data Discrepancies Noted (not auto-corrected)

1. Priority/filing date: The authoritative patent record (and the full text supplied) gives 1997-09-12. The Unified Patents portal lists a priority date of 1997-09-11, which most likely reflects a time-zone or data-normalization artifact. I have not "corrected" it, but flag it as inconsistent.
2. Current assignee: Google Patents lists Nokia of America Corp; the original assignee of record is Lucent Technologies Inc., with intervening security interests (Chase Manhattan Bank 2001, released 2006; Credit Suisse 2013, released 2014) and assignment to Alcatel-Lucent USA Inc. in 2014. Records are dated and may not reflect the true current owner.
3. Classification: Current US class is shown as 726/11 (uspto.report) versus 713/201 (everypatent) — a classification-scheme migration, not a substantive conflict.
4. Citation garbling: One retrieved USPTO reexamination document contains the text "U.S. Patent No. 6154775, 6098172, 6154775 to Coss et al." and elsewhere "Coss (U.S. Patent No. 6170012)" in a passage about a "Coss … firewall with cache query processing." Those strings appear internally inconsistent and I cannot treat them as reliable statements about US 6,098,172.

Bottom line

US 6,098,172 is an expired (since 2017-09-12) Lucent/Nokia-of-America patent from the late-1990s firewall era, whose claim set is directed to the "proxy reflection" idea: a firewall detecting that a session needs a service it cannot conveniently perform itself, and redirecting/reflecting that session's packets to a remote server or remote proxy — optionally using session key data, a dynamic rule, and source-address spoofing back to the original source so the proxy is invisible to both endpoints. Its notable public footprint is a single, now-closed 2014 Delaware infringement suit (Alcatel-Lucent v. Fortinet) and heavy citation as prior art by later firewall patents. I found no CAFC 2026 docket for this patent.

I'll research litigation involving US patent 6098172. Let me start with several targeted searches.

Let me investigate the litigation reference found on the patent page and dig deeper.

The Amazon/Nokia cases involve different patents. Let me focus on the specific Delaware case referenced on the patent page and search patent litigation databases.

Litigation Involving US Patent 6,098,172

I need to be upfront: my tool access was cut off before I could fully verify case-level details (parties, outcomes) from PACER, Unified Patents, or Docket Navigator. Here is what I can confirm from the authoritative patent record, plus what I could not verify.

Confirmed from the patent's own litigation data

The Google Patents record for US 6,098,172 (the authoritative source in my dataset) contains a "Family has litigation" section identifying one US court case:

The same record also flags "First worldwide family litigation filed" (family ID 25456779), pointing to Darts-ip — this is a family-level flag, and the only family member with a litigation entry in the record is this same Delaware case.

Plaintiff(s): Not stated in the source text I retrieved. Not verified.
Defendant(s): Not stated. Not verified.
Outcome/current status: Not stated. Not verified.

I could not confirm the parties or disposition, and I will not guess them. The patent's current listed assignee is Nokia of America Corp (originally Lucent Technologies Inc.), so a Nokia/Alcatel-Lucent entity is a plausible family owner of record in 2014 — but I have no verified confirmation that Nokia was the plaintiff in 1:14-cv-00574, so treat that as unconfirmed.

Cases I checked and determined are NOT this patent

To avoid a common confusion: the high-profile Nokia/Alcatel-Lucent v. Amazon campaign (U.S. district court in Delaware, ITC, Germany, UK, UPC), widely reported 2023–2025, involves Nokia's video/streaming codec patents — e.g., EP 2,130,150, EP 2,271,048, and certain ITU-T H.264/H.265 SEPs — not US 6,098,172. Those matters are unrelated to the firewall "proxy reflection" patent and should not be attributed to it.

Bottom line

• One litigation is known from the patent record: D. Del. 1:14-cv-00574 (filed 2014).
• No other litigation involving US 6,098,172 appeared in the sources I was able to reach.
• I was unable to verify the plaintiff, defendant, or outcome for 1:14-cv-00574 before my search budget was exhausted.

Recommended next steps to close the gaps

1. Query PACER directly for D. Del. 1:14-cv-00574 (docket report will give parties, filing date, and disposition).
2. Check the Unified Patents litigation page for the case (URL above) and the patent page https://portal.unifiedpatents.com/patents/patent/US-6098172-A.
3. Cross-check Docket Navigator / Darts-ip family ID 25456779.
4. Check the CAFC docket only if the 2014 case was appealed.

Caveat on my own confidence: I am confident about the case number and jurisdiction because they come verbatim from the patent record. I am not confident about the parties or outcome, and I have stated that explicitly rather than fabricating it.

I'll verify the ODP "no proceedings" signal against public sources before writing anything up.

The ODP block says no proceedings; let me confirm with targeted searches and identify what the litigation record actually involves, since a district-court case exists in the family history.

Verification note

The structured "PTAB proceedings on file" block reports no AIA trial proceedings for US 6098172 as of the most recent ODP ingest. I ran targeted web searches to see whether the ODP had missed anything (querying "US6098172 IPR/PTAB," "6,098,172 inter partes review," and assignee/inventor terms). No IPR, PGR, or CBM petition naming US 6098172 as the challenged patent surfaces in public sources. Per the instructions, the default "no PTAB activity on file" therefore stands — and I am flagging the two near-misses below so you don't misread a search hit as a proceeding.

Proceedings overview

Total AIA trial proceedings on US 6098172: 0 — zero active, zero with claims invalidated, zero with claims sustained, zero settled, zero institution denials. All 38 claims (independents 1, 5, 9, 13, 17, 21, 27, 33, 35, 36, 38, and their dependents) are untested at the PTAB, and the patent's legal status is "Expired – Lifetime," with an anticipated expiration of 2017-09-12 (source: the Google Patents record for US6098172A). The bottom line for a defendant is unusual and better than a hardened-patent scenario: the patent is expired, so it cannot be infringed prospectively — there is no PTAB record to fight because there was never any need to buy a PTAB defense against a live claim.

Per-proceeding detail

None to enumerate. There is no proceeding number, petitioner, panel, institution decision, FWD, settlement, or CAFC appeal to report for this patent, and I will not manufacture one. In lieu of the standard per-proceeding blocks, here are the two items that look like PTAB activity on 6098172 in search results but are not, followed by the one enforceable piece of litigation history.

⚠️ Not a proceeding — IPR2022-01151 / IPR2022-01199 (Cisco Systems, Inc. v. Centripetal Networks, Inc.)

• What it is: Inter partes reviews challenging Centripetal Networks patents (e.g., US 9,917,856 and related), not US 6098172. Docket: IPR2022-01151 on the PTAB docket feed, filed 2022-06-24, FWD appealed, panel including APJs Aaron Moore, Michelle Wormmeester, Nabeel Khan, Brian McNamara, and Steven Amundson.
• Why it shows up in a 6098172 search: "Coss – US6098172" appears there as Patent Owner Exhibit 2018 — i.e., the '172 patent was used as prior art evidence against Centripetal, cited as "Coss." Centripetal likewise used it in IPR2022-01199 (Exhibit 2018).
• Defensive value: zero estoppel effect for or against you. Exhibit status creates no § 315(e) estoppel and no invalidity holding as to any claim of the '172 patent.

⚠️ Not a proceeding — the expiration / post-grant toolkit

• PGR: unavailable. Post-grant review must be filed within 9 months of issuance (2000-08-01); that window closed in 2001.
• CBM: unavailable and independently barred. The CBM transitional program sunset on 2020-09-16, and this is a firewall/network-security patent, not a financial-services covered business method.
• IPR: technically still filable even on an expired patent (the Board has instituted on expired claims, where the patent owner simply cannot amend), but it would be a solution in search of a problem given the points below.

📍 District court litigation on file (not a PTAB proceeding)

• Case: Delaware District Court, 1:14-cv-00574, surfaced in the family litigation data linked from the Google Patents record (Unified Patents litigation entry).
• Parties: I could not verify the plaintiff or defendant for this docket number from available sources — searches for the case number returned a different matter (Chinook Licensing DE LLC v. Hulu, 1:14-cv-00074), which I am deliberately not conflating with it. Treat the identity of the parties as unconfirmed.
• Significance: it is a district court assertion, not an AIA trial, and it generated no PTAB follow-on on this patent. If you need the parties, pull the PACER docket directly.

Strategic summary

Claim status. There is no IPR-driven narrowing to report. Nothing has been canceled; nothing has been sustained after challenge; nothing has been construed by the Board. Every claim — independents 1, 5, 9, 13, 17, 21, 27, 33, 35, 36, and 38, plus all dependents (38 claims total) — is untested and formally intact. That sounds bad for a defendant, but the practical picture is dominated by a different fact: the patent's term ran out on 2017-09-12 and its status is "Expired – Lifetime." Under 35 U.S.C. § 286 there is a six-year damages lookback from the date of filing, and the last day on which infringement was even theoretically possible was 2017-09-12 — so a complaint filed after 2023-09-12 can reach essentially no recoverable past damages, and no prospective injunction or ongoing royalty is available. Before relying on that, confirm from the USPTO Patent Center/Assignment records that (a) the expiration date is as Google Patents records it, with no intervening lapse-and-revival or term adjustment, and (b) no reissue or reexamination is on file that could alter the picture.

Estoppel landscape. Because no IPR or PGR was ever instituted against this patent, § 315(e)(2) estoppel attaches to no one here. No petitioner is barred from raising any ground, and equally, no prior petitioner's loss creates a "second-bite" risk for you. Any invalidity ground — § 102, § 103, or § 112 — remains fully available if you are nonetheless forced to litigate (for example, if an accusation targets pre-2017 conduct). The art cited on the face of the patent is a rich starting set: EP 0743777 (Sun Microsystems), WO 97/000471 and US 5,835,726 (Check Point), US 5,623,601 (Milkyway), US 5,781,550 (Digital Equipment), EP 0856974 (AT&T, session cache/rule caching), US 5,848,233 and US 5,845,068 (Sun), US 5,898,830, US 6,003,084 (Secure Computing), plus the Siyan and Chapman firewall texts. Note the irony that the '172 patent's own "proxy reflection" concept is of contested novelty in view of the transparent/secure gateway art (US 5,781,550; US 6,003,084).

Pattern signals. No repeat petitioner, no multi-IPR campaign, no PTAB appeal history, and no defensive aggregator in the chain on this patent — the "Unified Patents" reference in the family history is a litigation-data link, not evidence that Unified filed a challenge. The chain of title runs Lucent Technologies → Alcatel-Lucent USA → Nokia of America Corp (current assignee). The patent's real modern role is as prior art ammunition: it is cited in 188 "cited by" entries and, as shown above, was pulled into the Cisco v. Centripetal IPRs as an exhibit. That is a useful diagnostic — patents that get asserted hard attract IPRs, and this one never did, consistent with a patent whose remaining value was defensive/prior-art rather than offensive.

Recommended next steps

1. Treat this as a "no PTAB activity" file — say it plainly, and check the expiry before anything else. The absence of IPRs on a 1997 firewall patent that was in a 2014 Delaware suit is itself the signal: nobody paid to invalidate it because it aged out. Confirm status at USPTO Patent Center and the assignment record for US 08/928,797, and check for any reissue/reexam. If it is indeed expired as of 2017-09-12, a present-day demand letter asserting it against current products is facially defective.
2. If you receive a demand letter: demand the damages theory in writing. Ask which accused acts, on which dates, and under what patent claim. If the only answer is post-2017 activity, the § 286 lookback and the expired term dispose of it. If the answer is pre-2017 conduct, you are in a damages-only, historic-royalty fight.
3. If you must litigate historic conduct, you have no estoppel problem. You may raise any § 102/§ 103/§ 112 ground, and there is no prior FWD or Federal Circuit opinion binding you. Build the invalidity case around the art already of record (EP 0856974; US 5,781,550; US 6,003,084; US 5,835,726; Siyan/Chapman) — but be aware that an expired claim still must be invalidated by clear and convincing evidence if you want it gone; validity is not free just because the term lapsed.
4. Do not cite IPR2022-01151 or IPR2022-01199 as proceedings on this patent. They are Cisco v. Centripetal matters where '172 appears only as an exhibit. Citing them as "IPRs on 6098172" in a brief or a client memo would be an easy credibility own-goal.
5. Correction opportunity for the record: the "Coss – US6098172" exhibit designations in the Centripetal IPRs are a good lead if you need an already-vetted invalidity narrative — the exhibit set and Cisco's expert declarations applying the '172 patent as prior art will show you exactly how a sophisticated petitioner framed it. Pull those papers from the PTAB E2E / PTAB Decisions portal under IPR2022-01151 and IPR2022-01199.

Caveat: I could not locate a public PTAB docket entry, FWD, or institution decision for US 6098172, and I have not fabricated one. If ODP later indexes a proceeding that predates my search coverage, the "0 proceedings" count would need to be revised.

I'll research the assignment record and litigation history for US 6098172 before drafting.

Let me dig into the assignment records and the Nokia/Alcatel-Lucent chain.

Assignment & Ownership Analysis — US 6,098,172

Patent: US 6,098,172 B1 — "Methods and apparatus for a computer network firewall with proxy reflection"
App. No.: 08/928,797 · Filed: 1997-09-12 · Granted: 2000-08-01 · Status: Expired – Lifetime (anticipated expiration 2017-09-12)
Verification entry point: USPTO Assignment Center (search by patent number) · Google Patents record

Data-quality caveat up front. I was not able to query the Assignment Center database directly in this session. The events below are taken from the Google Patents legal-events panel (which is populated from USPTO assignment data), corporate registry records, and court/PTAB filings. Where a reel/frame is shown, it is corroborated from a secondary source and flagged as such; where I could not verify a reel/frame, I say so rather than invent one. Confirm all reel/frame citations in the Assignment Center before relying on them.

Inventors

All three inventors assigned their rights to Lucent Technologies Inc., recorded 1998-03-11 (Google Patents legal events). Lucent was the AT&T spin-off whose research arm was Bell Labs; this trio is part of the Bell Labs firewall development team that produced Lucent's firewall product line. There is no evidence of inventor departure or re-assignment to a third party, and no inventor-side assignments appear anywhere in the chain. The "all inventors leave within 12 months" pre-fire-sale pattern is not present.

Family note: the same 1997-09-12 priority date is shared with sibling US 7,143,438 B1 ("Methods and apparatus for a computer network firewall with multiple domain support"), also originally Lucent — i.e., this is one member of a coherent multi-patent firewall portfolio filed by a single operating R&D organization, not a purchased shell asset.

Original assignee

Lucent Technologies Inc. (Delaware corporation), the entity named on the issued patent.

• Primary business: telecommunications and networking equipment/systems (spun out of AT&T in 1996).
• Product embodiment: Lucent commercialized firewall technology out of Bell Labs — the product lineage marketed as the Lucent VPN Firewall Brick. The "proxy reflection" and remote-proxy offload subject matter of this patent reads directly on that product line. (Confidence: moderate-to-high on the product lineage; I did not locate a dated Lucent datasheet in this session confirming the specific firmware version practicing claim 1.)
• Current status: Operating, but only through a long corporate chain of name changes and mergers — Lucent Technologies Inc. → Alcatel-Lucent USA Inc. (name change effective 2008; Sunbiz Name History, doc. F96000000109) → Nokia of America Corporation (name change filed 2018-02-15 per Florida Sunbiz / 2018-02-21 per RI Business Portal). Lucent "merged with Alcatel" in 2006 to form Alcatel-Lucent; Nokia acquired Alcatel-Lucent in 2016. The original Lucent legal entity still exists as Nokia of America Corporation (Florida/RI registries list it as Active), so this is a name-change chain, not a dissolution or fire-sale.

Assignment timeline

Every recorded post-issuance event from the Google Patents legal-events panel, in order. Google Patents does not expose reel/frame in its public panel, so reel/frame is marked not verified except where corroborated.

1997-09-12 (executed) / recorded 1998-03-11 — Reel/frame not verified

• Conveyance: Assignment
• Assignor: Michael John Coss; David L. Majette; Ronald L. Sharp
• Assignee: Lucent Technologies Inc.
• Correspondent: not shown in the public legal-events panel (Lucent/Bell Labs in-house patent operation of that era)
• Context: Original inventor-to-employer assignment at filing.

2001-04-05 (recorded) — Reel/frame not verified

• Conveyance: Security Agreement ("Conditional Assignment of and Security Interest in Patent Rights")
• Assignor: Lucent Technologies Inc. (DE corporation)
• Assignee: The Chase Manhattan Bank, as Collateral Agent
• Correspondent: not shown in the public panel
• Context: Securitization — collateral pledge under a Lucent corporate credit facility; Lucent retained beneficial ownership of the patent.

2006-12-06 (recorded) — Reel/frame not verified

• Conveyance: Release ("Termination and Release of Security Interest in Patent Rights")
• Assignor: JPMorgan Chase Bank, N.A. (formerly The Chase Manhattan Bank), as Administrative Agent
• Assignee: Lucent Technologies Inc.
• Correspondent: not shown in the public panel
• Context: Securitization release — the 2001 pledge was discharged; no change in beneficial ownership.

2008 (effective) — corporate name change (registry record, not necessarily a separate USPTO assignment record for this patent)

• Conveyance: Change of Name
• Assignor: Lucent Technologies Inc.
• Assignee: Alcatel-Lucent USA Inc.
• Correspondent: n/a
• Context: Internal reorg / change of name only.

2013-03-07 (recorded) — Reel/frame not verified

• Conveyance: Security Agreement ("Security Interest")
• Assignor: Alcatel-Lucent USA Inc.
• Assignee: Credit Suisse AG
• Correspondent: not shown in the public panel
• Context: Securitization — collateral pledge tied to Alcatel-Lucent's 2013 financing; no change in beneficial ownership.

2014-10-09 (received & recorded) — Reel 033949/0531 (corroborated from a USPTO PTAB petition exhibit; applicability to this specific patent is a strong date match — same 2014-10-09 date — but not individually confirmed)

• Conveyance: Release ("Release by Secured Party")
• Assignor: Credit Suisse AG
• Assignee: Alcatel-Lucent USA Inc. (600 Mountain Avenue, Murray Hill, NJ)
• Correspondent: "ATTN: HAYLEY SMITH SR." (as printed on the PTAB exhibit — likely an in-house Nokia/ALU IP-docketing contact, not an outside firm)
• Context: Securitization release.

2019-01-11 (received & recorded) — Reels 047965/0184 and 048066/0035 (corroborated from the same PTAB petition exhibit; confirm against this patent number before citing)

• Conveyance: Assignment of Assignors Interest (047965/0184) and Change of Name (048066/0035)
• Assignor: Alcatel-Lucent USA Inc. / Nokia of America Corporation (formerly Alcatel-Lucent USA Inc.)
• Assignee: Nokia of America Corporation, 600–700 Mountain Avenue, Murray Hill, NJ 07974
• Correspondent: Botos Churchill IP Law, 430 Mountain Avenue, Suite 401, New Providence, NJ 07974
• Context: Internal reorg + change of name — housekeeping recordings to true up the USPTO record after the Nokia acquisition/rename. Signal note: Botos Churchill is a recurring outside IP firm for the Nokia of America portfolio; its recurrence here reflects a large operating company's routine docketing practice, not the single-repeat-NPE-attorney tell.

Net ownership effect: nothing in the chain ever moved this patent out of the AT&T → Lucent → Alcatel-Lucent → Nokia of America corporate bloodline. Every post-2000 record is either a security interest / release (securitization) or a change-of-name / re-record. There has been no sale of this patent to any third party, and no assignment in either direction involving a non-operating acquirer.

Timeline diagram

timeline
    title Ownership of US 6098172
    1997 : Filed by Lucent inventors
    1998 : Assigned to Lucent Technologies
    2001 : Security interest to Chase Manhattan
    2006 : Lucent merges into Alcatel
         : Security interest released by JPMorgan
    2008 : Name changed to Alcatel-Lucent USA
    2013 : Security interest to Credit Suisse
    2014 : Release by Credit Suisse
         : ALU sues Fortinet in Delaware
    2018 : Renamed Nokia of America

NPE / troll-pattern signals

1. Shell-entity transfer — NOT PRESENT. No assignment to an IP/Licensing/Holdings/Ventures LLC exists anywhere in the chain. Every assignee is either the operating parent (Lucent Technologies Inc., Alcatel-Lucent USA Inc., Nokia of America Corporation) or a lender taking collateral (Chase Manhattan 2001-04-05; Credit Suisse AG 2013-03-07). No single-member Delaware/Texas LLC, no registered-agent address, no licensor entity appears.

2. Known asserter in the chain — NOT PRESENT. The only plaintiff/asserter on record is Alcatel-Lucent USA Inc., an operating telecom/network-equipment maker, in Alcatel-Lucent USA Inc. v. Fortinet Inc., No. 1:14-cv-00574 (D. Del., filed 2014-05-01, Judge Leonard P. Stark). None of the listed NPE families (Acacia, Marathon, Intellectual Ventures, Wi-LAN/Conversant, Vringo, Pendrell, Innovatio, MPHJ, Round Rock, Spangenberg entities, etc.) appears as assignor or assignee. The chain terminates at an operating Nokia entity, not an assertion vehicle.

3. Repeat correspondent across the chain — UNCLEAR (weak, non-weight-bearing). Two names recur in the corroborated 2014 and 2019 recordings: an in-house docketing contact ("Hayley Smith Sr.", reel 033949/0531, 2014) and outside firm Botos Churchill IP Law, New Providence NJ (reels 047965/0184 and 048066/0035, 2019). These are recurrences, but they are recurrences characteristic of a large operating company's routine assignment docketing, not a single attorney shepherding a family of anonymous shell LLCs. Critically, no correspondent attorney in this chain appears on any NPE assertion list and no assignment in the chain runs to a shell entity. Signal rated weak-to-negative.

4. Cascading transfers — NOT PRESENT. Five recorded events spread over ~18 years (2001, 2006, 2013, 2014, 2019), and none of them is an ownership transfer between unrelated parties. There is no chain of successive LLC-to-LLC assignments, no shared-principal cluster, no sub-24-month cascade.

5. Pre-litigation transfer — NOT PRESENT. The nearest assignments to the 2014-05-01 suit are the 2013-03-07 Credit Suisse pledge and the 2014-10-09 release, both lender security events on the operating company's own balance sheet — not transfers of title arranged to manufacture standing or venue. The plaintiff (ALU / Nokia of America) was the corporate owner of record throughout. Title never had to be "cleaned up" before assertion because it was never transferred out.

6. Bankruptcy fire-sale — NOT PRESENT. Lucent Technologies never filed Chapter 7/11; it merged with Alcatel in 2006. Alcatel-Lucent was restructured but the ALU-USA entity survived as Nokia of America Corporation (Active in FL and RI registries). No trustee sale, no §363 asset sale, no assignment from a bankruptcy estate appears.

7. Privateering — NOT PRESENT. There is no operating-company-to-NPE transfer followed by assertion "on behalf of" the operating company. ALU asserted in its own name as an operating company against Fortinet, a competitor in network security infrastructure. No SEC 8-K, Patent Progress, or EFF coverage surfaced tying this family to a privateering arrangement.

8. Defensive aggregator — NOT PRESENT. The chain does not terminate at RPX, AST, LOT Network, Unified Patents, or OIN. It terminates at Nokia of America Corporation, an operating entity. (Note: Unified Patents has indexed this patent in its prior-art portal and lists it under a family with litigation, but indexing is not ownership — Unified is not an assignee here.)

Verdict

Operating-company assertion.

The chain runs AT&T spin-off → Lucent Technologies Inc. (assignment recorded 1998-03-11) → securitization pledge to Chase Manhattan (2001-04-05) → release (2006-12-06) → name change to Alcatel-Lucent USA Inc. (2008) → pledge to Credit Suisse AG (2013-03-07) → release (corroborated reel 033949/0531, 2014-10-09) → name change to Nokia of America Corporation (2018; re-recorded reels 047965/0184 and 048066/0035, 2019-01-11). Not one of those events transferred title outside the operating corporate bloodline, and the only assertion of record — Alcatel-Lucent USA Inc. v. Fortinet Inc., No. 1:14-cv-00574 (D. Del., filed 2014-05-01) — was brought by the operating owner itself against a competitor. Zero NPE signals are present; the only mildly notable data point (a recurring outside IP firm, Botos Churchill, on the 2019 recordings) is ordinary operating-company docketing.

Verify at: Assignment Center — search patent 6098172 and https://assignment.uspto.gov/patent/index.html. I was unable to reach those databases directly in this session, so the reel/frame numbers for the 2001, 2006, and 2013 events remain unverified — confirm them there before publishing any figure.

I'll verify the patent record and each cited reference against live sources before doing the § 102 analysis.

Prior‑Art Analysis — US 6098172

Analyst's note on identifiers (no auto‑correction applied): Every patent number, application number and date below is reproduced literally from the sources retrieved. Where a third‑party source displays a value that conflicts with the patent's own record, I flag the conflict rather than silently correcting it.

1. Confirmation of the target patent

Discrepancy flagged: the Unified Patents portal entry for US‑6098172‑A displays "Priority Date: 1997‑09‑11," whereas the patent's own record (Google Patents, uspto.report, FPO) shows filing/priority 1997‑09‑12. I do not correct this; I simply note the aggregator variance. It does not change the analysis and does not change the 1996‑09‑12 statutory‑bar date.

Legal framework applied

This is a pre‑AIA patent (filed 1997), so the pre‑AIA versions of 35 U.S.C. § 102 apply:

• § 102(a) – reference "patented or described in a printed publication … before the invention thereof by the applicant" (invention date presumptively 1997‑09‑12).
• § 102(b) – reference patented or published more than one year before 1997‑09‑12, i.e., before 1996‑09‑12 (statutory bar).
• § 102(e) – US patent granted on an application filed before applicant's invention date (also certain PCT publications designating the US).
• § 102(g) – prior invention by another.

Three critical structural points before the reference‑by‑reference review:

1. The independent claims (1, 5, 9, 13, 17, 21, 27, 33, 35, 36, 38) all require redirection/reflection of a session to a remote server or remote proxy — i.e., a machine separate from the firewall, with the session then passed back through the firewall. Every cited patent that discloses proxying places the proxy on the firewall/gateway itself. That distinction is the likely point of novelty and is why straight § 102 anticipation of the independent claims is improbable; these are predominantly § 103 references.
2. Anticipation requires every element of a claim in a single reference, arranged as in the claim. Several references below disclose individual limitations (session‑key lookup, address rewriting, dynamic rules, transparency), but not the full combination.
3. All of these references were before the examiner and the claims nevertheless issued. Nothing below should be read as a finding that a claim is invalid; these are candidate relevance mappings only.

The fetched record labels this list "Citations (16)" (the heading "Patent Citations (17)" appears to include a repeated US5835726A entry at the truncation point), and separately lists "Family Cites Families (3)." A third source (uspto.report's transcription of the front page) lists US5884025 and omits US5606668. I analyse the union and note the variance.

2. Cited references — citation, dates, description, potential § 102 claim mapping

2.1 US patents

2.2 Foreign patent documents

2.3 Cited non‑patent literature

3. Most relevant prior art (ranked)

Tier 1 — closest to the proxy‑reflection concept

1. US 5781550 A (Templin et al., Digital Equipment Corp.), filed 1996‑02‑02, granted 1998‑07‑14. The single closest reference. It discloses the exact pipeline that claims 1/5/9/13 recite in part: rule‑base evaluation → diversion of the session to a proxy server → proxy consumes the packet and originates a new one → return path is rewritten so the far end and/or the initiator sees a direct connection. Its session‑control‑block local/remote address fields (its claims 5–7) map onto the "session key data / table look‑up" dependent claims here. Declared gap: the proxy is a component of the gateway, not a "remote server/proxy" — which is precisely the limitation the independent claims add.
2. US 5898830 A (Wesinger & Coley), filed 1996‑10‑17. "Envoys" plus multi‑homed virtual hosts create a firewall that transparently acts for the requester, with DNS/DDNS mapping — squarely the claim‑1 architecture with the transparency of claim 17. Same gap (virtual hosts are on the firewall).
3. US 6003084 A (Green & Kruse, Secure Computing), filed 1996‑09‑13. Proxy that transparently establishes independent sessions on both sides after ACL screening. Directly on point for claims 9–16/33–38, again with the local‑proxy gap.

Tier 2 — closest on specific limitations

1. US 5884025 A (Baehr et al., Sun), filed 1997‑02‑04 — a separate proxy network whose hosts perform the functions of the intended destination host. This is the only cited reference that places the impersonating service on different hardware, making it the most useful prior art to argue against the "remote" limitation. (Presence on the front page is disputed between sources; flagged above.)
2. US 5848233 A (Radia et al., Sun), filed 1996‑12‑09 — dynamic packet‑filter assignment; the natural § 102/§ 103 reference for claim 17 and its dependents 23/29.
3. EP 0 856 974 A2 / WO 97/49038 A1 (+ US 5842040) — session/rule caching, mapping onto the cache‑key and table‑lookup dependent claims. Only the US filings carry a viable § 102(e) date.

Tier 3 — background / secondary

1. US 5623601 A; US 5793763 A; US 5828833 A; US 5835726 A / US 5606668 A; US 5673322 A; EP 0 743 777 A2; WO 97/00471 A2; and the three NPL items.

4. Bottom line

• No single cited reference appears to anticipate any independent claim (1, 5, 9, 13, 17, 21, 27, 33, 35, 36, 38) under § 102. Each reference that discloses session redirection to a proxy discloses a proxy local to the firewall/gateway; none discloses the "remote" server/proxy that processes the session and passes it back through the firewall to the original destination — and none combines that with the dynamic‑rule‑based restoration of the original header values (step 1012–1013).
• The strongest § 102(e) dates among the cited art belong to US 5835726 A / US 5606668 A (1993‑12), US 5781550 A (1996‑02‑02), and US 6003084 A (1996‑09‑13) — all US filings preceding the 1997‑09‑12 date.
• The only cited art with § 102(b) statutory‑bar status is the Chapman/Zwicky text (Nov. 1995) and the Siyan/Hare text (Jan. 1995) — both more than one year before the filing date.
• EP 0 856 974 A2 and WO 97/49038 A1 cannot themselves be § 102(a)/(b) art because they published after 1997‑09‑12; only their US counterparts can be § 102(e) art.
• The most likely real‑world challenge posture for US 6098172 is § 103 over US 5781550 A or US 5898830 A in view of US 5848233 A (dynamic rules) and/or US 5884025 A (service relocated to separate proxy hardware).

Caveats I am obliged to state: (i) The § 102 mappings above are preliminary analyst relevance assessments, not legal conclusions; anticipation and invalidity are legal determinations reserved to the courts and the USPTO. (ii) I have described the references from their titles, abstracts and claim sets as retrieved; for rows 1–3, 5, 6, 8, 9, 12, 14 and 17 I have not read the full specifications, so element‑by‑element coverage cannot be confirmed. (iii) For the two Japanese family citations (JP 3371549 B2, JP 3502876 B2) I could not verify the publication dates of their examinable JP publications, so I make no § 102 assertion. (iv) Sources disagreed on the exact citation set (US 5884025 present in one, US 5606668 in another) and on the priority date (1997‑09‑11 vs 1997‑09‑12); both variances are noted above rather than resolved.

I'll analyze the obviousness of US 6098172 using the prior-art references cited on the patent page. Let me first verify details of the key references.

I have strong grounding on several references. Let me verify two more key references — the EDS RPC-through-firewall patent and the Cisco NAT patent — plus check for offloading/dispatch art.

Obviousness Analysis — U.S. Patent 6,098,172 Under 35 U.S.C. § 103

Reference: US6098172A, "Methods and apparatus for a computer network firewall with proxy reflection," Lucent Technologies Inc., filed/priority 1997‑09‑12, granted 2000‑08‑01, expired 2017‑09‑12. Source: https://patents.google.com/patent/US6098172/en

Scope note. This is a technical analysis, not a legal opinion. Obviousness is a legal conclusion; I apply the Graham v. John Deere framework (scope/content of prior art, differences, level of ordinary skill, secondary considerations) as informed by KCS/KSR (motivation may be supplied by design incentives, known techniques, predictable variation, or market forces). I use only the references listed in the "Citations (16)"/"Patent Citations (17)" and "Family Cites Families (3)" sections of the page, plus USPTO/public full texts retrieved for those references. Where I could not open a reference's full text, I say so and flag lower confidence. Identifiers are reproduced literally from the page.

1. Level of Ordinary Skill in the Art (POSITA)

A POSITA as of the September 1997 priority date would be a network/computing engineer with a bachelor's degree in EE/CS and about 2–4 years' experience designing packet-filtering firewalls, application proxies, or TCP/IP gateways, familiar with:

• IP/TCP/UDP headers and the 5‑tuple (source addr, dest addr, protocol, source port, dest port);
• Proxy/application-gateway vs. packet-filter firewall architectures (Bellovin & Chesick, "Network Firewalls," IEEE Comm. Mag., Sep. 1994 — cited within US6003084 and US5781550);
• Address translation and endpoint spoofing;
• Client/server task distribution (moving processing off a bottleneck device onto a dedicated server).

2. The Claims — Where the Alleged Novelty Lies

The independent claims (1, 5, 9, 13, 17, 21, 27, 33, 35, 36, 38) all recite the same core triad:

1. receiving a request at a firewall for a session from a source to a destination;
2. ascertaining whether granting the request requires a service that can be fulfilled/provided/performed by a remote server / remote proxy; and
3. redirecting / reflecting packets to that remote server/proxy.

Dependents add: session-key data for the ascertaining step (2, 6, 10, 14, 18, 19, 25, 26, 31, 32); "appear to the destination as coming from the source" (4, 8, 12, 16, 20, 24, 30); "setting up a dynamic rule to enable an appearance of a direct connection" (17); "informing the remote server of the destination" coupled with the service packets going from the remote server to the destination (22, 23, 28, 29, 34, 37).

Critically, every independent claim is limited to that triad. The spec's actual mechanism for making reflection work — the encrypted channel back to the firewall, the firewall-issued unique destination port number, and the dynamic rule loaded for the return path (spec §5, steps 1006–1013) — is not recited in claims 1–16 or 21–38. That breadth materially helps a §103 challenge, because the specific inter-process coordination that might arguably be novel is left unclaimed.

3. The Prior Art on the Page — What Each Reference Teaches

4. Claim 1 — Limitation-by-Limitation Mapping to the Combination

The only element not squarely met by any single reference is the word "remote" — i.e., that the server/proxy performing the service sits on a machine separate from the firewall. Everything else (firewall interception, rule/mask-based determination that a service is needed, diversion of the flow to a proxy, restoration/spoofing of endpoint addresses, session-key lookup, dynamic rule installation) is taught.

5. The §103 Combinations and the Motivation to Combine

Combination A (primary) — US5781550 + US6003084 + US5898830 (optionally + US5673322)

Covers independent claims 1, 5, 9, 13, 21, 27, 33, 35, 36, 38 and dependents 2–4, 6–8, 10–12, 14–16, 18–20, 22–26, 28–32, 34, 37.

• US5781550 supplies interception + rule-driven PROXY disposition + diversion to a proxy server + packet regeneration + endpoint spoofing (the "appear … as coming from the source" dependents, esp. claims 4/8/12/16/20/24/30, and "informing the remote server of the destination," claims 22/28/34/37, via the proxy's ability to "discover both the Internet address of the trusted computer A as well as … the untrusted computer C").
• US6003084 supplies the firewall-resident proxy that monitors any address on specific ports, the processor/memory + firewall-module apparatus structure (its claim 22 mirrors '172's claims 21/27/36/38), and address masking between requester and server.
• US5898830 supplies transparent "on-behalf-of" second connections and, in claim 9, expressly teaches distributing the virtual-host/proxy function across multiple physical machines chosen dynamically. That is a direct, in-art teaching to move the proxy function off the firewall box onto a separate one.
• US5673322 supplies the general practice of performing filtering/translation as a service on a separate proxy host.

Motivation / rationale (KSR factors):

• Same field, predictable result: both proxies sit mid-path on TCP sessions and rewrite endpoints; relocating a proxy process from the firewall's application layer to a separate host does not change the protocol mechanics — the firewall still diverts the packet, the proxy still consumes/regenerates it.
• Recognized problem in the art: firewall processors have limited concurrent-process capacity and in-firewall proxying degrades throughput. US5898830 cl. 9 (multiple physical machines for availability), US5673322 (proxy serving many clients), and the art's general move toward scalability provide the "design incentive" for offload.
• Known technique / obvious to try: client-server task distribution and load offload were routine; the art identified offload as one of a finite number of identified, predictable solutions (co-locate the proxy, or run it on a dedicated host).

Combination B — US6003084 + US5828833 + US5781550

Targets claims 9, 13, 33, 36 (proxy flavor) and claims 17–20.
US6003084 provides an ACL/interrogation-driven firewall proxy; US5828833 provides firewall handling of a protocol that requires a second, dynamically-created channel opened through the firewall (RPC callback); US5781550 provides rule-based diversion. The combination teaches determining, from session data, that a service (the callback/auxiliary flow) is required and then installing the mechanism needed to let it complete — directly reading on the "dynamic rule" claims when combined with the references below.

Combination C — Combination A + US5848233 + EP0856974A2/US6173364 (+ US5606668)

Targets claims 2, 3, 6, 7, 10, 11, 14, 15, 18, 19, 25, 26, 31, 32 ("session key data" / "table look-up") and claim 17 ("setting up a dynamic rule").

• EP0856974/US6173364 discloses a "session key" 5‑tuple and a session cache searched by that key before the rule base, with hash-table indexing — squarely the "session key data in a table look-up" limitations.
• US5848233 discloses rules created dynamically from network events, selected from a database or template — the "dynamic rule" of claim 17.
• US5606668 (if verified) discloses dynamically permitting a return flow after inspecting the first packet.
• Motivation: EP0856974 and US5781550 both key their decisions on the same 5‑tuple/session record; using that same key to decide "proxy needed?" and to install a temporary rule authorizing the reflected flow is the straightforward application of a rule cache to a known proxy-diversion flow, with predictable benefit (avoids re-parsing every packet; authorizes precisely the return path).

Combination D — For the "appears to come from the source" dependents (4, 8, 12, 16, 20, 24, 30)

US5781550's "spoof the trusted computer" / "expose the Internet address of the trusted host" + US5793763's NAT source-address rewriting + US6003084's address masking together teach selectively rewriting the source address of an outgoing proxied flow so the destination sees the original user. Claim 4 et seq. do not require the unique-port mechanism from the spec, only the appearance — which is the classic NAT/transparency result.

6. Dependent-Claim Vulnerabilities (Summary)

7. Caveats, Rebuttal Considerations, and Things I Would Verify

Points favoring the patentee (non-obviousness arguments):

1. No listed reference expressly locates the proxy outside the firewall and returns the flow through it. US5781550's proxy executes in the gateway's application layer; US5898830's envoys run on the firewall (albeit possibly on different physical machines). A stringent examiner or the PTAB could find that "remote" is the point of novelty and that US5898830 cl. 9's "multiple physical computers" is about redundancy, not offload — requiring the petitioner to supply a clearer offload teaching.
2. The back-channel coordination (firewall telling the remote proxy the original session key/destination, and the firewall re-writing the address on the return path) is arguably more than the mere relocation of a proxy. However, because that coordination is only in the specification and not in claims 1–16 or 21–38, this argument is available mainly for claim 17 (and weakly), so it does little to save the broad independent claims.
3. Secondary considerations (long-felt need, commercial success, copying) could rebut, but I have no evidence of nexus or commercial data on the page, and the patent is expired (2017‑09‑12), so the practical stakes are historical.

Points favoring the challenger: The independent claims are broad, functional, and result-oriented ("ascertaining whether … requires a service … redirecting to said remote server"); all sub-steps are individually disclosed; the only super-added element ("remote") is a predictable architectural placement supported by in-art teachings on distributed proxy/virtual-host execution.

Verification flags (do not treat as established):

• I could not retrieve full texts for US5793763, US5828833, US5673322, US5606668, US5623601, US5689566, US5845068, WO1997049038A1, WO1997002734A2, EP0743777A2, US5835726A, or the JP references during this run. My characterization of those rests on the titles/assignees on the page plus general knowledge; US5606668's dynamic-rule content in particular should be confirmed before being used in a claim chart, since it is the strongest candidate for the claim-17 "dynamic rule" element.
• US6154775A appears in the page's "Cited By" list (priority 1997‑09‑11, "Methods and Apparatus for a Computer Network Firewall with Dynamic Rule Processing"). Because its priority date is one day before '172's filing and the title matches the Lucent sibling filing (cf. EP0910197A2 on the same date), it is probably a family member and not prior art. Confirm inventorship/assignee before citing it either way.
• The page lists this family as having litigation in the District of Delaware (1:14‑cv‑00574); §103 invalidity would have been a principal defense, so a real challenge would be run against the specific claim charts and priority/derivation record — not just the reference titles.

Bottom Line

Save for the word "remote," every element of the independent claims of US 6,098,172 is disclosed across the page's cited art: US5781550 (firewall interception → rule-driven "PROXY" disposition → diversion to a proxy server → endpoint spoofing), US6003084 (firewall-resident proxy monitoring connections on any address/port, plus a processor/memory firewall-module apparatus), US5898830 (transparent "on-behalf-of" connections, and expressly distributing virtual hosts across multiple physical machines), and US5673322 (filtering/translation performed by a separate proxy host). A POSITA would have been motivated to relocate the application proxy from the firewall to a separate server by the well-known capacity/throughput limits of firewall processors and the routine client-server offload/distribution practice evidenced in US5898830 and US5673322. The dependent claims are met by EP0856974A2/US6173364 (5‑tuple session-key cache and table lookup), US5848233 (+ US5606668, to be verified) (dynamic rule installation), and US5781550 + US5793763 (source-address restoration). On this record, the broad independent claims — and most dependents — are vulnerable to a §103 challenge, with the strongest residual non-obviousness argument being the absence of an express in-art teaching to place the reflection proxy outside the firewall while routing the flow back through it.